Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Event Log (Audit Log)

Event Log Introduction

As users work in the Apstra environment their actions are logged. These event logs are useful when investigating general usage, network outages, and possible suspicious activity. See below for the information that's collected.

Types of Events that are Logged

Events for the following event types are logged:

Table 1: Event Types

Event

Description

Login

A user logged in (success and failure).

Logout

A user logged out.

BlueprintCommit

Changes were applied from the staged blueprint to the active blueprint.

BlueprintRevert

Changes in the staged blueprint were discarded.

BlueprintRollback

The staged blueprint was rolled back to a previous version.

BlueprintDelete

The entire blueprint was deleted.

DeviceConfigChange

The configuration of a device was changed. This includes any configuration change that Apstra pushes to any managed device (including Time Voyager). The event is attributed to the logged-in user making the change.
MigrationCheckpoint When you upgrade the Apstra server on a new VM (VM-VM) to versions 5.0.0 and higher, a MigrationCheckpoint event is logged. This event includes upgrade details, such as the Apstra version of the old Apstra server (source), the Apstra version of the new Apstra server (target), and a timestamp from during the upgrade process. The upgrade is followed up by a Metricdb data migration and upon a successful migration on the new VM, the Metricdb data before the timestamp is from the old VM and data after the timestamp is from the new VM.

OperationModeChangeToMaintenance

The blueprint operation mode was changed to Maintenance by a user.

OperatonModeChangeToNormal

The blueprint operation mode was changed to Normal by a user, or by the system when disk usage and memory are under the utilization threshold (the operation is in read/write mode).

OperationModeChangeTo ReadOnly

 The blueprint operation mode was changed to Read Only by the user, or by the system when the utilization threshold is surpassed (the operation is in read only mode).

RatelimitExceptionAdd

A ratelimit exception was added.

RatelimitExceptionDelete

A ratelimit exception was deleted.

RatelimitClear

A ratelimit was cleared.

SyslogCreate

Syslog was created.

SyslogUpdate

Syslog was updated.

SyslogDelete

Syslog was deleted.

UserCreate

A user profile was created (by creating or cloning).

UserUpdate

A user profile was updated.

UserDelete

A user profile was deleted.

AuthAclEnable

Access control rules were enabled.

AuthAClDisable

Access control rules were disabled.

AuthAclRuleAdd

An access control rule was added.

AuthAclRuleUpdate

An access control rule was updated.

AuthAclRuleDelete

An access control rule was deleted.

Types of Event Details that are Collected

The following details are logged for each event (as applicable):

Table 2: Event Details

Property

Description

Time Range

The timeframe of when the event occurred (hover over time field to see date and time).

User

The user who performed the activity, the system or a username such as admin.

User IP Address

The IP address associated with the user who made the change.

Type (of Event)

The type of event (listed in table above).

Blueprint Name (Blueprint ID)

The ID of the blueprint where the change was made.

Blueprint Commit Message

The description of the changes that were committed to the blueprint, if provided.

Device Key (Device ID)

Typically, the serial number of the managed device where the change was made.

Device Configuration

 The configuration that's pushed and applied to the device.

Result

The outcome of the activity. Success means operation is accepted by the system. In the case of an error, the error string is included (unauthorized, for example).

Search Event Logs

  1. From the left navigation menu, navigate to Platform > Event Log to go to the table of logged events.
  2. The table displays the 25 most recent events, by default. To change the number of events that are displayed, click the Table settings button (three dots below the Query button) and select a number from the drop-down list.
  3. Click the Query Builder, enter/select your query from the available search fields. You can enter multiple values in some fields; events that match criteria for all fields are returned. Click Apply for results.
    Note:

    The event log is based on the number of events. Up to 10,000 events are retained. They're written to log-rotated files as a second repository. You can configure logrotate parameters in the Apstra server configuration file (/etc/aos/aos.conf).
  4. Click Confirm for results.
In addition to using the Apstra GUI to search for events as described above, you can also use API (/api/audit/events).

Export Event Log to CSV File

  1. From the left navigation menu, navigate to Platform > Event Log and click Export to CSV (top-right).
  2. To filter the data to export, enter your query.
  3. Click Save as CSV File to download the CSV file.

Send Event Log to External Syslog Server

For details about sending the event log to an external system with the Syslog protocol, see Syslog Configuration.

Parse Apstra Logs

Apstra uses Common Event Format (CEF), a standard for the interoperability of event or log-generating devices and applications. The standard defines a syntax for log records. It comprises a standard prefix and a variable extension formatted as key-value pairs.

Apstra Log Format

Where:

  • version is always “0”

  • device_vendor is always “Apstra”

  • device_product is always “Apstra”

  • device_version is the current Apstra version

  • device_event_class_id is “100” for audit logs and “101” for anomaly logs

  • name is always “Audit even” for audit logs and “Alert” for anomaly logs

  • severity is always “medium” for audit logs and “Very-High” for anomaly logs

And where:

  • {extension} is either:

    • For anomaly logs: msg=<json payload>

    • For audit logs: cat=<activity> src=<src_IP> suser=<username> act=<activity result> cs1Label=<field1_type> cs1=<field1_value>cs2Label=<field2_type> cs2=<field2_value> cs3Label=<field2_type> cs2=<field2_value>

Audit Log Fields

Table 3: Audit Log Fields
Field Description Applies to
cat Activity performed. Valid values: “Login”, “Logout”, “BlueprintCommit”, “DeviceConfigChange”, “BlueprintDelete”. All messages
src Source IP of the client making HTTP requests All messages
suser Who performed the activity All messages
act Outcome of the activity - free-form string. “Success” means operation is accepted by system. In case of error, include error string. Ex: Unauthorized All messages
cs1Label The string “Blueprint Name” Cat = “BlueprintCommit” or “BlueprintDelete”
cs1 Name of the blueprint on which action was taken. Cat = “BlueprintCommit” or “BlueprintDelete”
cs2Label The string “Blueprint ID” Cat = “BlueprintCommit” or “BlueprintDelete”
cs2 Id of the blueprint on which action was taken. Cat = “BlueprintCommit” or “BlueprintDelete”
cs3Label The string “Commit Message”. Only exists if user has added a commit message (optional) Cat = “BlueprintCommit” or “BlueprintDelete”
cs3 Commit Message. Only exists if user has added a commit message (optional) Cat = “BlueprintCommit”
deviceExternalId Id (typically serial number) of the managed device on which action was taken. Cat = “DeviceConfigChange”
deviceConfig Config that is pushed and applied on the device where “#012” is used to indicate a line break to log collectors and parsers. Cat = “DeviceConfigChange”

Anomalies JSON Fields

Table 4: Anomalies JSON Fields Table
Field Description Applies to
u'blueprint_label' String. Name of the blueprint the anomaly was raised in. All messages
u'timestamp' String. Name of the blueprint the anomaly was raised in. All messages
u'origin_name' String. Name of the blueprint the anomaly was raised in. All messages
u'alert' The value is a JSON Payload with the actual anomaly (see next table)
u'origin_hostname' String. Hostname of the device the anomaly affects. All messages
u'device_hostname' String. Hostname of the device the anomaly affects. All messages
u'origin_role String. Hostname of the device the anomaly affects. All messages
Table 5: Main Msg Format
Field Description Applies to
u'first_seen' String. Unix timestamp when the Anomaly was raised for the first time. All messages
u'raised' Always True All messages
u'severity The severity level of the anomaly. In Apstra today, all anomalies are raised with severity level 3. All messages

Anomaly Log Examples

IBA Anomaly “MLAG Anomaly”

The device_event_class_id = 101 for all anomalies

IBA Anomaly “Unexpected Hostname”

User Logout and Logging

The device_event_class_id = 100 for all events

Blueprint Delete

Blueprint Commit

Device Config Change

Revert a full day-0 BP deployment

Device Config

Note that “#012” is used to indicate a line break