이벤트 관리 구성 기본 설정

  • 릴리스 버전: Xanadu
  • 업데이트 날짜 2024년 08월 01일
  • 소요 시간: 10분
  • 속성 및 일반 구성의 기본 설정입니다.

    정보 문제를 쉽게 찾을 수 있도록 알려진 오류 포털커뮤니티를 사용하십시오.

    일반 기본 설정

    자체 상태
    기본적으로 자체 상태 모니터링 기능은 사용되지 않습니다. 활성화하려면 다음으로 이동하십시오. 이벤트 관리 > 설정 > 속성 을 클릭하고 (evt_mgmt.self_health_active) 속성에 Enable Event Management self-health monitoring 대해 예를 선택합니다. 이 기능을 사용하여 많은 이벤트 관리 기능을 모니터링하고 추적합니다.
    주:
    자체 상태 서비스에서 사용되는 CI는 CMDB에서 생성됩니다.
    다음 설정을 사용하여 성능 저하를 방지할 수 있습니다.
    주제 상세 정보
    비즈니스 규칙
    • 이벤트 [em_event] 테이블에 대한 비즈니스 규칙을 작성하지 마십시오. 이벤트 주입에 사용되는 현재 기본 REST URL에서는 실행되지 않습니다.
    • 경보 [em_alert] 테이블에 대해 작성된 비즈니스 규칙은 효율성이 높아야 합니다. 그렇지 않으면 성능이 저하될 수 있습니다. 비즈니스 규칙을 작성하는 대신 작업을 작성하는 것이 더 적절한지 고려해야 합니다. 비효율적인 비즈니스 규칙으로 인해 경보 생성에 실패하고 경보 영향을 계산하지 못할 수 있습니다.
    • 경보 테이블에 대한 비동기 비즈니스 규칙을 작성하지 마십시오.
    • 비즈니스 규칙에서 이벤트 [em_event] 테이블의 범주 필드를 변경하면 안됩니다.
    확장 이벤트 관리로 처음 시작할 때 이벤트 처리량을 늘리기 전에 평균 이벤트 처리 시간을 확인합니다. 이벤트의 초기 플로우 후에 모든 규칙이 적합하면 이 검사를 수행합니다. 처리 시간이 이벤트당 몇 밀리초를 넘는 경우 확장을 계속하기 전에 처리 속도를 늦추는 원인을 확인합니다. 성능 통계 [sa_performance_statistics] 테이블에서 성능 지속 시간을 확인할 수 있습니다.
    대규모 환경에 맞게 구성
    • 다중 노드 이벤트 처리 사용(evt_mgmt.event_processor_enable_multi_node) 속성을 Yes(예)로 설정합니다.

      프로덕션 환경에서 다중 노드를 사용하도록 설정하고 배포 크기와 예상 이벤트 비율에 따라 값을 설정합니다.

    • 예약된 작업 처리 이벤트 수(evt_mgmt.event_processor_job_count) 속성을 4로 설정합니다.
    • 사용자 지정 소스에서 이벤트를 보내는 경우 이벤트에 메시지 키 또는 소스, 노드, 유형자원 데이터가 있는지 확인합니다.
    이벤트 수신에 대한 대기 시간 문제 다음 설정을 확인하십시오.
    • [em_event] 이벤트 테이블의 버킷 필드가 0보다 큰 값(0)으로 설정되어 있는지 확인합니다.
    • 다음으로 이동 시스템 스케줄러 > 예약된 작업 을 검색하십시오 - process events*.

      예약된 작업 처리 이벤트 수(event_processor_job_count) 속성 구성에 따라 모든 - process events* 작업이 존재하는지 확인합니다. 상태Running 또는 Ready인지 확인합니다. 상태가 Queued 또는 Error인 경우 작업 상태를 Ready로 설정합니다.

    이벤트 보관
    • 이벤트의 기본 보존 시간을 변경하지 마십시오.
    • 이벤트를 더 오래 기록하려면 보관 테이블과 새 이벤트를 여기에 복사하는 작업을 생성하십시오. 이렇게 하려면 사용자 지정 테이블에 이벤트 [em_event]를 정기적으로 백업하도록 작업을 예약합니다.
    • 날짜를 늘려서 테이블 교대를 연장하지 마십시오.

    이벤트 통합

    SNMP 트랩
    • SNMP 트랩을 장치에서 직접 보내지 않고 모니터링 도구를 사용하여 보내십시오.
    • 이벤트 규칙을 재작성할 필요가 없도록 이벤트 규칙을 정의하기 전에 MIB를 업로드하십시오.
    웹 서비스 API
    • 통합에 웹 서비스 API를 사용하면 필요한 이벤트 규칙 수를 줄일 수 있습니다. 그러면 이벤트를 변환하지 않아도 됩니다(준비된 데이터를 이벤트를 통해 인스턴스로 보냄).
    • 통합에 전용 자격 증명을 사용하십시오. 필요에 따라 각 이벤트 소스에 고유한 자격 증명을 지정하십시오.
    CloudWatch
    CloudWatch와 ServiceNow 통합에 전용 자격 증명을 사용하십시오.
    이메일
    소스 양이 적고 다른 옵션(예: 스크립트 실행 또는 SNMP 트랩 전달)을 사용할 수 없는 경우에만 이메일을 사용하십시오.
    이벤트 규칙
    이벤트 규칙 생성 시 구성 설정
    • 가능한 많은 이벤트 수에 적용할 이벤트 규칙을 작성하십시오. 필요에 따라 더 구체적인 규칙을 생성할 수 있으며 순서 번호가 낮은 값을 사용해야 합니다.
    • 더 일반적인 규칙이 동일한 결과를 얻을 수 있는 경우 이벤트의 특정 하위 세트에만 적용되는 이벤트 규칙을 작성하지 마십시오.
    • 이벤트 규칙을 이벤트에 적용해도 원래 이벤트가 변경되지는 않습니다. 모든 처리가 메모리에서 발생하므로 처리 메모 필드를 사용하거나 이벤트의 처리 확인 UI 작업 링크를 사용하여 문제를 해결하십시오.
    • 기존 매핑 규칙이 있는 규칙/변환을 변경하는 경우 실제 또는 시뮬레이트된 이벤트를 검토하고 다시 테스트해야 합니다.
    • From(시작) 필드 값이 이벤트의 additional_info 필드에 있는 JSON의 문자열과 정확하게 일치하는지 확인합니다. 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을 지정하지 마십시오. 그러면 기능을 사용할 수 없으며 성능이 저하될 수 있습니다.
    • 양호 상태에서는 경보를 생성하지 마십시오. 일부 모니터링 시스템에서 양호가 문제가 해결되었음을 나타내고, 다른 모니터링 시스템에서 양호는 운영상 중요하지 않은 이벤트를 나타내는 데 사용됩니다. 전자의 경우 매핑 규칙을 사용하여 양호 대신 무결을 사용하십시오. 후자의 경우 이벤트가 특정 값이 아닌 경우 무시 규칙이 있어야 합니다.
    경보 작업 규칙
    • 예약된 작업은 11초마다 새 경보에 경보 작업 규칙을 적용합니다. 경보 규칙이 즉시 시작되지 않으면 10 ~ 15초 후에 문제 해결을 시작하십시오.
    • 2개의 이벤트 규칙에 유사한 조건이 설정되어 있으면 순서 필드를 사용하여 실행할 경보 규칙을 제어합니다.
    • 작업 템플릿과 함께 경보 작업 규칙을 사용하여 인시던트에 정적 값을 채웁니다. 채우기 스크립트를 사용하여 인시던트에 동적 값을 할당합니다. 채우기 스크립트는 인시던트 생성을 중단하기 위해 False 값을 반환할 수 있습니다.
    • 사용자가 호출한 이벤트 관리 또는 비슷한 이름을 생성합니다. 그런 다음 작업 템플릿의 생성자 필드(예: 인시던트)를 설정하여 해당 사용자가 작업의 소스임을 나타낼 수 있습니다.
    • 동적 값 할당을 수행하거나 OOB 동적 값 할당을 무효화하려면 EvtMgmtCustomIncidentPopulator 스크립트 포함을 사용합니다.
    정정
    • 항상 오케스트레이션 워크플로우 속성을 정정 작업 [em_remediation_task] 테이블로 설정하십시오.
    • ECC 큐 사용 및 워크플로우 > 라이브 워크플로우 > 모든 컨텍스트 을 클릭하여 정정 활동에 대한 자세한 정보를 확인합니다.

    비즈니스 규칙

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

    계획 수립

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

    서비스 및 대시보드

    • 서비스 그룹을 사용하여 서비스를 논리 그룹으로 묶어서 서비스 상태 대시보드에 표시되는 서비스 수를 줄이십시오.
    • 수동으로 구성한 서비스 맵을 임포트하십시오.

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

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

    표 1. 메트릭 인텔리전스 수집기 로그 및 파일의 위치
    로그 또는 파일 경로
    PowerShell 메트릭 수집기 로그 파일 Logs/retrieve_metrics{connector instance 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] 테이블에서 확인할 수 있습니다. 성능 수치를 보려면 메트릭 수집기에 대해 성능 통계 목록을 필터링하십시오.