이벤트 관리 구성 기본 설정

알려진 오류 포털과 커뮤니티를 사용하면 정보 문제를 쉽게 찾을 수 있습니다.

일반 기본 설정

기본적으로 자체 상태 모니터링 기능은 사용되지 않습니다. 이 기능을 사용하려면 다음으로 이동하십시오. 이벤트 관리 > 설정 > 속성 및 (evt_mgmt.self_health_active) 속성에 Enable Event Management self-health monitoring 대해 예를 선택합니다. 이 기능을 사용하여 많은 이벤트 관리 기능을 모니터링하고 추적합니다.

주:

자체 상태 서비스에서 사용되는 CI는 CMDB에서 생성됩니다.

다음 설정을 사용하여 성능 저하를 방지할 수 있습니다.


주제	세부사항
비즈니스 규칙	이벤트 주입에 사용되는 현재 기본 REST URL에서는 실행되지 않으므로 이벤트 [em_event] 테이블에 대한 비즈니스 규칙을 작성하지 마십시오. 경보 [em_alert] 테이블에 대해 작성된 비즈니스 규칙은 효율성이 높아야 합니다. 그렇지 않으면 성능이 저하될 수 있습니다. 비즈니스 규칙을 작성하는 대신 작업을 작성하는 것이 더 적절한지 고려해야 합니다. 비효율적인 비즈니스 규칙으로 인해 경보 생성에 실패하고 경보 영향을 계산하지 못할 수 있습니다. 경보 테이블에 대한 비동기 비즈니스 규칙을 작성하지 마십시오. 비즈니스 규칙에서 이벤트 [em_event] 테이블의 범주 필드를 변경하면 안 됩니다.
확대	으로 처음 시작할 때 이벤트 처리량을 확장하기 전에 평균 이벤트 처리 시간을 확인합니다.이벤트 관리 이벤트의 초기 플로우가 진행되고 모든 규칙이 적합하면 이 검사를 수행합니다. 처리 시간이 이벤트당 몇 밀리초를 넘는 경우 확장을 계속하기 전에 처리 속도를 늦추는 원인을 확인합니다. 성능 통계 [sa_performance_statistics] 테이블에서 성능 지속 시간을 확인할 수 있습니다.
대규모 환경에 맞게 구성	다중 노드 이벤트 처리 사용(evt_mgmt.event_processor_enable_multi_node) 속성을 예로 설정합니다. 프로덕션 환경에서 다중 노드를 사용하도록 설정하고 배포 크기와 예상 이벤트 비율에 따라 값을 설정합니다. 예약 된 작업 처리 이벤트 수 (evt_mgmt.event_processor_job_count) 속성을 `4`로 설정합니다. 사용자 지정 소스에서 이벤트를 보내는 경우 이벤트에메시지 키 또는 소스, 노드, 유형 및 자원 데이터가 있는지 확인합니다.
이벤트 수신에 대한 대기 시간 문제	다음 설정을 확인하십시오. 이벤트 [em_event] 테이블의 버킷 필드가 0(0)보다 큰 값으로 설정되어 있는지 확인하십시오. 다음으로 이동 시스템 스케줄러 > 예약된 작업 을 검색하고 을 검색합니다 - process events. 예약된 작업 처리 이벤트 수(event_processor_job_count) 속성 구성에 따라 모든 - process events 작업이 있는지 확인합니다. 상태가 Running 또는 인지 Ready확인합니다. 상태가 또는 Error이면 Queued 작업 상태를 로 Ready설정합니다.
이벤트 보관	이벤트의 기본 보존 시간을 변경하지 마십시오. 이벤트를 더 오래 기록하려면 보관 테이블과 새 이벤트를 여기에 복사하는 작업을 생성하십시오. 이렇게 하려면 사용자 지정 테이블에 이벤트 [em_event]를 정기적으로 백업하도록 작업을 예약합니다. 날짜를 늘려서 테이블 교대를 연장하지 마십시오.

이벤트 통합

SNMP 트랩

SNMP 트랩을 장치에서 직접 보내지 않고 모니터링 도구를 사용하여 보내십시오.
이벤트 규칙을 다시 작성할 필요가 없도록 이벤트 규칙을 정의하기 전에 MIB를 업로드하십시오.

웹 서비스 API

통합에 웹 서비스 API를 사용하면 필요한 이벤트 규칙 수를 줄일 수 있습니다. 그러면 이벤트를 변환하지 않아도 됩니다(준비된 데이터가 이벤트를 통해 인스턴스로 전송됨).
통합에 전용 자격 증명을 사용하십시오. 선택적으로 각 이벤트 소스에 고유한 자격 증명을 지정합니다.

CloudWatch

CloudWatch ServiceNow를 통합하기 위한 전용 자격 증명을 사용하십시오.

이메일

소스 양이 적고 스크립트 실행 또는 SNMP 트랩 전달과 같은 다른 옵션을 사용할 수 없는 경우에만 이메일을 사용하십시오.

이벤트 규칙

이벤트 규칙 생성 시 구성 설정:

가능한 많은 이벤트 수에 적용할 이벤트 규칙을 작성하십시오. 필요에 따라 더 구체적인 규칙을 생성할 수 있으며 순서 번호가 낮은 값을 사용해야 합니다.
더 일반적인 규칙이 동일한 결과를 얻을 수 있는 경우 이벤트의 특정 하위 세트에만 적용되는 이벤트 규칙을 작성하지 마십시오.
이벤트 규칙을 이벤트에 적용해도 원래 이벤트는 변경되지 않습니다. 모든 처리는 메모리에서 발생하므로 처리 메모 필드를 사용하거나 이벤트 처리 확인 UI 작업 링크를 사용하여 문제를 해결하십시오.
기존 매핑 규칙이 있는 규칙/변환을 변경하는 경우 실제 또는 시뮬레이트된 이벤트를 검토하고 다시 테스트해야 합니다.
시작 필드 값이 이벤트 필드의 JSON additional_info 에 있는 문자열과 정확히 일치하는지 확인합니다. 이 일치는 MIB 파일의 정보를 기반으로 규칙이 구성된 경우에 발생합니다. MIB 파일이 업로드되지 않은 경우 SNMP 트랩에 대한 JSON은 MIB의 변환된 이름 대신 점으로 구분된 이름의 varbinds(변수 바인딩)를 보여줍니다. 그러면 이벤트 필드 매핑 규칙이 적용되지 않습니다.
일관된 명명 규칙을 설정합니다. 일반적인 규칙은 다음과 같습니다. <customer acronym>.<Event Source>.<Description> 예: ACME.OEM.Normalize
2개의 이벤트 규칙에 유사한 조건이 설정되어 있으면 순서 필드를 사용하여 실행할 이벤트 규칙을 제어합니다.
이벤트 규칙을 사용하여 CI와 경보를 연결합니다.

이벤트 규칙 구성에 대한 추가 설정:


원하는 결과	필요한 활동
효과적인 중복 제거 및 효율적인 병렬 이벤트 처리 사용	소스, 노드, 유형, 자원, 메트릭 이름 필드를 채웁니다.
CI 바인딩	호스트에 바인딩 - 노드 필드와 CI 식별자를 입력합니다. 애플리케이션 및/또는 장치에 바인딩 – CI 식별 자 필드와 추가 정보 필드를 채웁니다.
경보 집계를 사용한 경보 상관관계	자원 및 메트릭 이름 필드를 채웁니다. 주: CI도 바인딩되어 있으면 경보 상관관계가 향상됩니다.

사용자 지정 이벤트 필드: 이벤트의 추가 정보 필드에만 추가 필드를 포함하십시오.; 이벤트 [em_event] 테이블에 사용자 지정 필드를 추가하여 이벤트에 필드를 더 추가하지 마십시오.; 이벤트 [em_event] 테이블에 열을 추가하지 마십시오.

이벤트에 추가 필드를 포함하는 방법에 대한 자세한 내용은 다음 문서를 참조하십시오 사용자 지정 경보 필드.

중복 제거: 중복 제거를 위한 구성 설정입니다.

message_key 필드는 중복 제거에 사용됩니다. 신뢰할 수 있는 메시지 키 값이 소스 이벤트와 함께 제공되지 않는 경우 이러한 식별자 생성을 위한 계획을 잘 정의하는 것이 중요합니다.
메시지 키가 정의되어 있지 않은 경우 기본 메시지 키는 <Source + Node + Type + Resource + Metric Name> 입니다.
가이드라인은 이벤트 소스가 바로 사용 가능한 필드를 <Source + Node + Type + Resource + Metric Name> 채우고 메시지 키를 채우도록 하는 것입니다. 이 작업을 통해 인스턴스 작업자와 노드 간에 이벤트 처리를 더 효과적으로 분배할 수 있습니다.
소스 이벤트에 이러한 필드의 값이 없으면 변환 규칙을 사용하여 입력해야 합니다. 이 작업은 이벤트 처리에 영향을 주지 않지만 중복 제거에 사용됩니다. 이러한 필드를 인스턴스로 보내기 전에 가능한 한 많이 입력하십시오. 그러면 프로세서 작업자에게 이벤트를 더 효과적으로 분배할 수 있으므로 처리량과 규모가 향상됩니다.

CI 바인딩

가능한 경우 항상 CI에 경보 바인딩을 시도하십시오.
주:
이벤트에 이벤트 규칙이 정의되어 있더라도 CI는 이러한 이벤트에서 생성되는 경보에 바인딩되고 이벤트에 바인딩되지 않습니다.
호스트, 컴퓨터 또는 장치를 IP와 바인딩하려면 이벤트 노드 필드를 고유한 호스트 이름, FQDN, IP 또는 MAC 주소로 채우십시오. 호스트를 식별하는 데 다른 식별자가 필요한 경우 ci_identifiers 필드를 JSON 형식으로 채웁니다. JSON 형식에는 일치를 수행하기 위한 CMDB 필드 이름과 값이 포함되어야 합니다.
주:
이벤트 노드 필드는 이벤트 규칙에서 작성하거나 이벤트 삽입 전에 소스의 고유한 호스트 이름으로 채워야 합니다.
기본 바인딩 전략은 노드 필드를 사용하는 것입니다. 노드 필드가 이벤트에 미리 채워지지 않은 경우 이벤트 규칙을 사용하여 채울 수 있습니다.

경보 설정

경보 수명주기: 일반 경보 기능:

이벤트가 무시되지 않거나, 임계치가 이벤트 규칙에 의해 초과되거나, 중복 제거 시 이벤트가 기존 경보에 속하는 것으로 식별되지 않을 때마다 경보가 열립니다.
같은 메시지 키에서 종결 이벤트를 보내거나 경보가 수동으로 종결되면 경보가 종결됩니다.
속성에 정의된 시간 범위(기본값은 1시간) 내에 동일한 메시지 키를 가진 오픈 경보가 전송되면 경보가 다시 열립니다.
속성에 정의된 빠른 속도로 경보를 열고 닫을 경우 경보가 플래핑됩니다. 이 열기 및 닫기 속도가 멈추면 경보가 플래핑 상태에서 벗어납니다.
경보에서 인시던트가 열리는 경우 인시던트가 열려 있는 동안 해당 경보도 열려 있습니다. 기본적으로 인시던트나 경보 중 하나가 종결되면 다른 하나도 종결됩니다. 속성을 사용하여 이 동작을 구성할 수 있습니다.
해당 인시던트를 생성할 때 경보를 닫지 마십시오.
열려 있는 경보는 삭제하지 마십시오. 먼저 경보를 닫고 삭제하십시오.
확인 을 사용하여 경보가 알려져 있으며 일시적으로 무시할 수 있음을 나타냅니다.
경보를 주의가 필요한 것으로 표시하는 데 확인 을 사용하지 마십시오.
다음 상태 중 하나로 경보를 생성하지 마십시오.
- 종결
- 확인
- 오픈
evt_mgmt.alert_auto_close_interval 속성은 지정된 기간 이후에 경보를 자동으로 종결합니다. 0을 지정하지 마십시오. 그러면 기능을 사용할 수 없으며 성능이 저하될 수 있습니다.
정상 상태에서는 경보를 생성하지 마십시오. 일부 모니터링 시스템에서 OK 는 문제가 해결되었음을 나타내고, 다른 모니터링 시스템에서 OK는 운영상 중요하지 않은 이벤트를 나타내는 데 사용됩니다. 전자의 경우 매핑 규칙을 사용하여 확인 대신 지우기를 사용하십시오. 후자의 경우 이벤트가 특정 값이 아닌 경우 무시 규칙이 있어야 합니다.

경보 작업 규칙

예약된 작업은 11초마다 새 경보에 경보 작업 규칙을 적용합니다. 경보 규칙이 즉시 시작되지 않으면 문제 해결을 시작하기 전에 10-15초를 기다립니다.
순서 필드를 사용하여 두 개의 경보 규칙에 유사한 조건이 설정되어 있으면 실행할 경보 규칙을 제어합니다.
작업 템플릿과 함께 경보 작업 규칙을 사용하여 인시던트에 정적 값을 채웁니다. 채우기 스크립트를 사용하여 인시던트에 동적 값을 할당합니다. 채우기 스크립트는 False 값을 반환하여 인시던트 생성을 중단할 수 있습니다.
호출된 이벤트 관리 사용자(또는 비슷한 이름)를 생성합니다. 그런 다음 작업 템플릿(예: 인시던트)의 작성자 필드를 설정하여 해당 사용자가 작업의 소스임을 나타낼 수 있습니다.
동적 값 할당을 수행하거나 OOB 동적 값 할당을 재정의하려면 EvtMgmtCustomIncidentPopulator 스크립트 포함을 사용합니다.

정정

항상 오케스트레이션 워크플로우 속성을 정정 작업 [em_remediation_task] 테이블로 설정하십시오.
ECC 큐 및 워크플로우 > 라이브 워크플로우 > 모든 컨텍스트 정정 활동에 대한 자세한 정보를 찾으려면 다음을 수행합니다.

비즈니스 규칙

경보 테이블에 생성된 비즈니스 규칙은 몇 밀리초 이상 걸릴 수 없습니다. 비즈니스 규칙을 사용하는 대신 작업을 사용하여 동일한 기능을 구현할 수 있는지를 고려하십시오.
비즈니스 규칙을 사용하여 CI와 경보를 연결하지 마십시오. 비즈니스 규칙 대신 이벤트 규칙을 사용하여 바인딩을 수행하십시오.

계획 수립

필터, 모듈 등의 이벤트 소스 구성을 직렬이 아닌 여러 병렬 작업으로 조직하십시오.
처리된 이벤트 형식을 확인하여 구문 분석되는 데이터가 원하는 결과에 맞는지 확인합니다.
비프로덕션 환경에서 프로덕션 이벤트를 테스트합니다. 비프로덕션 요소 관리자 및 ServiceNow 인스턴스와 통합합니다. 비프로덕션 요소 관리자를 사용할 수 없는 경우 요소 관리자에서 프로덕션 환경과 비프로덕션 환경 모두로 이벤트를 보냅니다.

서비스 및 대시보드

서비스 그룹을 사용하여 서비스를 논리 그룹으로 그룹화하면 서비스 상태 대시보드에 표시되는 서비스 수를 줄일 수 있습니다.
수동으로 구축된 서비스 맵을 임포트합니다.

메트릭 인텔리전스 수집기 로그 및 파일

메트릭 인텔리전스 수집기 로그와 파일은 경로 $(MID_SERVER_DIR)/agent 아래에 있습니다. 문제 해결과 모니터링에 로그와 파일을 사용하십시오.

표 1. 수집기 로그 및 파일의 위치 메트릭 인텔리전스
로그 또는 파일	경로
PowerShell 메트릭 수집기 로그 파일	로그/retrieve_metrics{커넥터 인스턴스 ID}.log
PowerShell 출력 파일	work/metrics/metrics_output_{connector instance ID}.txt
PowerShell 입력 파일	work/metrics/parameters_{connector instance ID}.txt

메트릭 인텔리전스매개변수가 mid.log.level MID 서버 디버그 모드에 있을 때 로그 파일에서 MID 서버 성능을 확인할 수 있습니다.

메트릭 인텔리전스 성능 수치는 성능 통계[sa_performance_statistics] 테이블에서 확인할 수 있습니다. 성능 수치를 보려면 메트릭 수집기에서 성능 통계 목록을 필터링하십시오.