Syslog 구성(플랫폼)
Syslog 개요
시스템 로그(syslog)는 시스템에서 발생하는 모든 문제의 실행 목록입니다. 이러한 로그를 사용하여 이벤트를 감사하거나 이상 징후를 검토할 수 있습니다. syslog를 구성하여 특정 유형의 시스템(시설)에 대한 메시지를 외부 syslog 서버로 보낼 수 있습니다. ( 이벤트 로그를 CSV 파일로 내보낼 수도 있습니다.)
Syslog 구성에는 다음 세부 정보가 포함됩니다.
이름 | 설명 |
---|---|
IP 주소 |
원격 syslog 서버 IP 주소 또는 호스트 이름 |
포트 |
원격 syslog 서버 포트 |
프로토콜 |
UDP 또는 TCP |
시설 |
메시지를 로깅하는 시스템 유형 기능은 다음과 같이 Apstra syslog에 매핑됩니다.
|
시간대 | syslog 메시지 표준 시간대입니다. 적절한 시간대 변환이 있는 경우 시스템 시간대(또는 Docker 표준 시간대)를 외부 syslog 서버와 동기화할 필요가 없습니다. 메시지 시간이 줄루/UTC-0에 있다고 가정하는 대신, 표준 시간대 변환은 올바른 시간대 정보를 타임스탬프에 추가해야 합니다. 그런 다음 외부 메시지 시스템에서 Apstra 이벤트를 더 잘 상관분석할 수 있습니다. |
Syslog 메시지는 아래와 같이 CEF(Common Event Format) 규칙을 따릅니다.
{host}는 Apstra 서버 호스트 이름입니다. 호스트 이름을 변경하려면 Apstra Server 호스트 이름 변경 페이지의 절차를 사용해야 합니다. 다른 방법으로 호스트 이름을 변경하는 경우 새 호스트 이름이 syslog 항목에 포함되지 않습니다.
AOS Log Format: '{timestamp} {host}' 'CEF:{version}|{device_vendor}|{device_product}|{device_version}|' '{device_event_class_id}|{name}|{severity}|{extension} Where: {version} : CEF version, currently always "0" {device_vendor} : always "Apstra" {device_product} : always "AOS" {device_version} : current AOS version {device_event_class_id} : "100" for audit logs, "101" for anomaly logs {name} : "Audit event" for audit logs, "Alert" for anomaly logs {severity} : "5" for audit logs, "10" 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=<field3_type> cs3=<field3_value> Anomaly Log JSON Format blueprint_label : Name of the blueprint the anomaly was raised in. timestamp : Unix timestamp when the Anomaly was raised. origin_name : Serial Number of the device the anomaly affects. alert : The value is a JSON Payload with the actual anomaly (see Alert JSON Payload below) origin_hostname : Hostname of the device the anomaly affects. It can be AOSHOST, an empty string if the hostname could not be determined or a valid value. device_hostname : Hostname of the device the anomaly affects or <device hostname unknown> if a hostname could not be determined origin_role : Role of the device the anomaly affects. Alert JSON Payload: <ALERT TYPE>_alert: Contains a JSON payload with key-value pair of information pertaining to the alert. Here <ALERT TYPE>_alert can be valid anomaly/alert names such as hostname_alert, probe_alert, liveness_alert etc. id : UUID of the anomaly. first_seen : Unix timestamp when the Anomaly was raised for the first time. raised : True when anomaly is present, False when it is cleared. severity : The severity level of the anomaly. Set to 3 for critical, 2 for high, 1 for medium and 0 for low. Audit Log Format: cat : Activity performed. Valid values: "Login", "Logout","BlueprintCommit","BlueprintRevert","BlueprintRollback", "BlueprintDelete","DeviceConfigChange", "OperationModeChangeToMaintenance","OperationModeChangeToNormal","OperationModeChangeToReadOnly","RatelimitExceptionAdd","RatelimitExceptionDelete", "RatelimitClear","SystemChangeApiOperationModeToMaintenance","SystemChangeApiOperationModeToNormal","UserCrete","UserUpdate","UserDelete", "SyslogCreate","SyslogUpdate","SyslogDelete","AuthAclEnable","AuthAclDisable","AuthAclRuleAdd","AuthAclRuleUpdate" and "AuthAclRuleDelete". src : Source IP of the client making HTTP requests to perform the activity. suser : Who performed the activity. act : Outcome of the activity - free-form string. In the case when the activity was performed successfully, the value stored is “Success“. In case of error, include error string. Ex: Unauthorized cs1Label : The string “Blueprint Name”. Only exists if activity is associated with a blueprint (optional) cs1 : Name of the blueprint on which action was taken. Only exists if activity is associated with a blueprint (optional) cs2Label : The string “Blueprint ID”. Only exists if activity is associated with a blueprint (optional) cs2 : Id of the blueprint on which action was taken. Only exists if activity is associated with a blueprint (optional) cs3Label : The string “Commit Message”. Only exists if user has added a commit message (optional) cs3 : Commit Message. Only exists if user has added a commit message (optional) deviceExternalId : Id (typically serial number) of the managed device on which action was taken. Only exists if activity is associated with a device such as for “DeviceConfigChange” (optional) deviceConfig : Config that is pushed and applied on the device where “#012” is used to indicate a line break to log collectors and parsers. Only exists if activity is associated with a device such as for “DeviceConfigChange” (optional)
감사 Syslog 메시지의 예:
Jan 31 03:11:01 aos-server - 2023-01-31T03:11:01.699190+0000 aos-server CEF:0|Apstra|AOS|4.1.2-269|100|Audit event|5|cat=Logout src=172.24.212.62 suser=admin act=Success Jan 31 03:11:01 aos-server - 2023-01-31T03:11:01.699190+0000 aos-server CEF:0|Apstra|AOS|4.1.2-269|100|Audit event|5|cat=BlueprintCommit src=172.24.212.62 suser=admin act=Success cs1Label=Blueprint Name cs1=rack-based-blueprint-33ded50f cs2Label=Blueprint ID cs2=rack-based-blueprint-33ded50f
이상 징후 Syslog 메시지의 예:
Jan 31 03:11:01 aos-server - 2023-01-31T03:11:01.699190+0000 aos-server CEF:0|Apstra|AOS|4.1.2-269|101|Alert|10|msg={u'blueprint_label': u'rack-based-blueprint-33ded50f', u'timestamp': 1679002758562407, u'origin_name': u'time_series', u'alert': {u'probe_alert': {u'expected_int_max': 99, u'stage_name': u'leaf_match_perc_range', u'probe_label': u'leaf_to_spine_interface_statuses', u'actual_int': 83, u'probe_id': u'60b03bb0-0e22-4a6d-b32d-e15085149b7b', u'key_value_pairs': [], u'item_id': u'1', u'expected_int': -9223372036854775808}, u'first_seen': 1679002758562121, u'raised': False, u'severity': 3, u'id': u'02a17b60-cc3e-4afb-baba-733a8c654df6'}, u'origin_hostname': u'AOSHOST', 'device_hostname': '<device hostname unknown>', u'origin_role': u''} Jan 31 03:11:01 aos-server - 2023-01-31T03:11:01.699190+0000 aos-server CEF:0|Apstra|AOS|4.1.2-269|101|Alert|10|msg={u'blueprint_label': u'rack-based-blueprint-33ded50f', u'timestamp': 1679002754682990, u'origin_name': u'50540015FA9D', u'alert': {u'first_seen': 1679002749600167, u'raised': False, u'severity': 3, u'hostname_alert': {u'expected_hostname': u'leaf-3', u'actual_hostname': u''}, u'id': u'0457a759-7d3a-4bf8-97e8-e13e518cf267'}, u'origin_hostname': u'', 'device_hostname': '<device hostname unknown>', u'origin_role': u'leaf'}
왼쪽 탐색 메뉴에서 플랫폼 > 외부 서비스 > Syslog 구성 으로 이동하여 구성을 확인합니다. syslog 구성을 생성, 복제, 편집 및 삭제할 수 있습니다.
Syslog Config 생성
- 왼쪽 탐색 메뉴에서 플랫폼 > 외부 서비스 > Syslog 구성으로 이동하고 Syslog Config 만들기(오른쪽 상단)를 클릭합니다.
- Syslog 서버를 구성합니다. 자세한 내용은 위의 개요를 참조하십시오.)
- 생성을 클릭하여 구성을 저장하고 테이블 보기로 돌아갑니다.
- 다른 Syslog 서버를 구성하려면 위의 단계를 반복합니다.
- 구성된 서버로 메시지를 전송할 수 있도록 하려면 필요에 따라 감사 및/또는 이상 전달에 사용하기로 전환합니다.
Syslog Config 편집
- 왼쪽 탐색 메뉴에서 플랫폼 > 외부 서비스 > Syslog 구성으로 이동하고 편집할 Syslog 구성의 편집 단추를 클릭합니다.
- 변경사항을 확인하십시오.
- 업데이트를 클릭하여 Syslog 구성을 업데이트하고 테이블 보기로 돌아갑니다.
Syslog 구성 삭제
- 왼쪽 탐색 메뉴에서 플랫폼 > 외부 서비스 > Syslog 구성으로 이동하고 삭제할 Syslog 구성의 삭제 단추를 클릭합니다.
- Syslog 구성 삭제를 클릭하여 Syslog 구성을 삭제하고 테이블 보기로 돌아갑니다.