Как мы обнаруживаем изменения без использования журналов аудита

The problem with audit logs

Most network monitoring tools rely on audit logs to detect changes. The controller or device writes a log entry when an admin modifies something, and the monitoring tool picks it up. This works until it does not. Audit logs are incomplete by nature. Bulk imports, API-driven changes, out-of-band modifications, firmware upgrades that reset defaults, scheduled automation that runs outside the audit window — all of these produce real changes that never appear in the audit trail.

SAMURAI takes a fundamentally different approach. Instead of reading what a device says changed, we compare what the device actually looks like between two points in time. Every sync cycle fetches the full state of every collection — routes, ACLs, interfaces, policies, endpoints — and compares the result to what we stored last time.

Volatile field stripping

Raw device data is noisy. Uptime counters tick every second. Session IDs rotate. Timestamps on last-polled fields change even when nothing meaningful happened. If you hash the raw output, every single sync produces a “change” — which is the same as producing no useful signal at all.

SAMURAI maintains a volatileFields map per device type. Before hashing, the sync engine calls stripVolatileRecursive to walk the document tree and remove every field listed in the map. For vCenter, that means stripping guest_state, runtime uptime counters, connection state, and thin-disk drift metrics. For routers, it strips interface counters and last-input timestamps. Each device type has its own curated list, tuned over months of production use to eliminate false positives without hiding real changes.

SHA-256 hash deduplication

After volatile fields are stripped, the remaining document is serialized into a canonical form. Key ordering matters here — if two identical documents serialize with different key orders, the hashes diverge and you get a phantom diff. SAMURAI uses sortByMarshaledKey to pre-compute json.Marshal per element and sort deterministically. This is load-bearing: an earlier approach that sorted by string comparison was 323x slower on large collections and produced ordering drift that flapped hashes on every cycle.

The SHA-256 hash of the canonical form is compared against the stored hash. If they match, no new snapshot is written. The last_verified_at timestamp updates (proving the sync ran), but last_sync_at only updates when the data actually changed. This distinction matters: it lets operators see “data verified 2 minutes ago, last real change was 6 hours ago” at a glance.

Snapshot retention

When a hash does change, the new snapshot is stored alongside the previous one. SAMURAI retains up to SYNC_RETENTION_COUNT snapshots per collection (default: 168, which is one week of hourly syncs). Old snapshots are cleaned up by cleanupOldSnapshots, which scopes deletion to only the collections that were written in the current sync — never touching unrelated data.

The result is a complete change history built from ground truth. You can diff any two snapshots side by side. You can see exactly which fields changed, when, and on which device. And because the comparison is against real device state — not an audit log that may or may not have been written — you catch changes that every audit-log-based system misses entirely.

What this catches that audit logs miss

Configuration pushed via API without audit enabled. Bulk imports that bypass the change log. Firmware upgrades that reset interface descriptions. Neighbor tables that shift because a cable was moved. Route table changes from an upstream provider. DHCP snooping entries that appear when a new device joins the network. None of these write audit logs. All of them change the device state. SAMURAI sees them all.

Ваша сеть заслуживает дисциплины

Посмотрите, как SAMURAI работает с вашей реальной средой. Большинство демо назначаются в течение 24 часов.