알림 및 규칙
원본 보기알림 및 규칙
Kibana 알림은 Kibana에 내장된 알림 시스템입니다. 일정에 따라 데이터를 확인하는 규칙을 정의하고, 조건이 충족되면 알림을 생성하며, 커넥터(이메일, Slack, 웹훅 등)를 통해 작업을 트리거할 수 있습니다. 모든 배포에서 사용할 수 있습니다.
ES|QL을 기반으로 구축된 실험적 알림 시스템에 관해 알아보려면 실험적 알림 시스템 개요를 참조하세요.
일반 제공되는 Kibana 알림 시스템에서 알림이라는 용어는 규칙 조건이 발생하여 추적되는 항목을 뜻합니다. 실험적 알림 시스템에서는 이에 해당하는 개념을 알림 에피소드라고 합니다. 두 용어는 서로 다른 시스템의 유사한 개념을 설명하며 서로 바꿔 쓸 수 없습니다.
일반적으로 규칙은 세 부분으로 구성됩니다.
- 조건: 무엇을 감지해야 합니까?
- 일정: 감지 검사를 언제, 얼마나 자주 실행해야 합니까?
- 작업: 조건이 감지되면 어떻게 됩니까?
예를 들어 서버 집합을 모니터링할 때 규칙은 다음과 같이 작동할 수 있습니다.
- 지난 2분 동안 각 서버의 평균 CPU 사용량이 > 0.9인지 확인합니다(조건).
- 매분 확인합니다(일정).
- 제목이
CPU on {{server}} is high인 경고 이메일 메시지를 SMTP를 통해 보냅니다(작업).
각 프로젝트 유형은 특정 규칙 유형 집합을 지원합니다. 각 규칙 유형은 감지할 조건을 정의하는 고유한 방법을 제공하지만, 일련의 절로 구성된 표현식이 일반적인 패턴입니다. 예를 들어 Elasticsearch 쿼리 규칙에서는 메트릭 집계 작업(count, average, max, min 또는 sum)을 사용하는 인덱스, 쿼리 및 임계값을 지정합니다.
모든 규칙에는 규칙 조건을 얼마나 자주 평가할지 정의하는 확인 간격이 있어야 합니다. 검사는 대기열에 추가되며, 용량이 허용하는 한 정의된 값에 최대한 가깝게 실행됩니다.
Kibana의 규칙 확인 간격은 대략적인 값입니다. 작업을 가져오는 빈도와 시스템의 작업 부하 같은 요인이 실행 시점에 영향을 줍니다. 알림 프로덕션 고려 사항을 참조하세요.
조건이 충족될 때 알림을 생성하도록 규칙에 하나 이상의 작업을 추가할 수 있습니다. 마찬가지로 규칙 조건이 더 이상 충족되지 않으면 복구 작업이 실행됩니다.
규칙에서 작업을 정의할 때 다음을 지정합니다.
- 커넥터
- 작업 빈도
- 규칙 값을 해당 작업 유형에 공개된 속성으로 매핑하는 방식
각 작업은 알림을 보낼 위치에 따라 Kibana 서비스 또는 타사 통합의 연결 정보를 제공하는 커넥터를 사용합니다. 규칙에서 사용할 수 있는 구체적인 커넥터 목록은 프로젝트 유형에 따라 다릅니다. 커넥터를 참조하세요.
커넥터를 선택한 후 작업 빈도를 설정합니다. 알림의 적시성에 영향을 주지 않으면서 수신하는 알림 수를 줄이려면 일부 규칙 유형에서 지원하는 알림 요약을 사용할 수 있습니다. 예를 들어 Elasticsearch 쿼리 규칙을 생성하는 경우 사용자 지정 간격으로 신규, 진행 중 및 복구된 알림의 요약을 수신하도록 작업 빈도를 설정할 수 있습니다.
또는 각 알림에 대해 작업이 실행되도록 작업 빈도를 설정할 수 있습니다. 규칙 유형이 알림 요약을 지원하지 않는다면 이 옵션만 사용할 수 있습니다. 작업이 실행되는 시점(예: 각 확인 간격, 알림 상태가 변경될 때만 또는 사용자 지정 작업 간격)을 선택해야 합니다. 또한 작업 실행 여부에 영향을 주는 작업 그룹도 선택해야 합니다. 각 규칙 유형에는 유효한 특정 작업 그룹 집합이 있습니다. 예를 들어 Elasticsearch 쿼리 규칙의 실행 시점을 Query matched 또는 Recovered로 설정할 수 있습니다.
각 커넥터는 작업 그룹별로 특정 작업 집합을 지원하며 서로 다른 작업 속성을 활성화합니다. 예를 들어 규칙 조건이 충족되면 Opsgenie 알림을 생성하는 작업과 Opsgenie 알림을 닫는 복구 작업을 구성할 수 있습니다.
일부 규칙 유형에서는 작업이 실행되는 조건을 더 세부적으로 조정할 수 있습니다. 예를 들어 특정 시간 범위 내에 알림이 발생하거나 KQL 쿼리와 일치할 때만 작업이 실행되도록 지정할 수 있습니다.
알림 요약을 사용하지 않으면 작업이 알림별로 트리거되어 규칙 하나가 많은 작업을 생성할 수 있습니다. 규칙이 매분 세 서버의 CPU 사용량이 > 0.9인지 모니터링하고 작업 빈도가 On check intervals로 설정된 다음 예를 살펴보겠습니다.
- 1분: 서버 X123 > 0.9. 서버 X123에 대해 이메일 한 통이 전송됩니다.
- 2분: X123 및 Y456 > 0.9. X123과 Y456에 각각 한 통씩 이메일 두 통이 전송됩니다.
- 3분: X123, Y456, Z789 > 0.9. X123, Y456, Z789에 각각 한 통씩 이메일 세 통이 전송됩니다.
이 예에서는 동일한 규칙으로 3분 동안 서버 X123에 이메일 세 통이 전송됩니다. 이러한 반복 알림은 억제하는 것이 바람직할 때가 많습니다. 작업 빈도를 5분 간격의 On custom action intervals로 설정하면 임계값을 계속 초과하는 서버에 대해 5분마다 한 번만 이메일을 받으므로 불필요한 알림을 줄일 수 있습니다.
- 1분: 서버 X123 > 0.9. 서버 X123에 대해 이메일 한 통이 전송됩니다.
- 2분: X123 및 Y456 > 0.9. Y456에 대해 이메일 한 통이 전송됩니다.
- 3분: X123, Y456, Z789 > 0.9. Z789에 대해 이메일 한 통이 전송됩니다.
서버가 임계값을 초과할 때 한 번만 알림을 받으려면 작업 빈도를 On status changes로 설정할 수 있습니다. 또는 규칙 유형이 알림 요약을 지원하는 경우 알림 수를 줄이기 위해 사용을 고려하세요.
조건이 감지될 때 규칙 값을 작업에 전달할 수 있습니다. 규칙에 사용할 수 있는 변수 목록을 보려면 "규칙 변수 추가" 버튼을 클릭하세요.
공통 작업 변수에 대한 자세한 내용은 규칙 작업 변수를 참조하세요.
조건을 확인할 때 규칙이 조건의 여러 발생 항목을 식별할 수 있습니다. Kibana는 이러한 알림을 각각 별도로 추적합니다. 작업 빈도에 따라 알림별로 또는 지정된 알림 요약 간격마다 작업이 발생합니다.
서버 모니터링 예에서 평균 CPU가 > 0.9인 각 서버는 하나의 알림으로 추적됩니다. 즉, 알림 상태가 변경될 때마다 임계값을 초과하는 각 서버에 별도의 이메일이 전송됩니다.
규칙은 조건, 작업 및 일정으로 구성됩니다. 조건이 충족되면 작업을 렌더링하고 호출하는 알림이 생성됩니다. 작업을 더 쉽게 설정하고 업데이트할 수 있도록 작업은 Kibana 서비스 및 타사 통합에 연결하는 데 사용되는 정보를 중앙에서 관리하는 커넥터를 사용합니다. 다음 예는 이러한 개념을 한데 보여 줍니다.
- 규칙의 조건이 충족될 때마다 알림이 생성됩니다. 이 예에서는 평균 CPU가 > 0.9인 서버를 확인합니다. 서버 세 대가 조건을 충족하므로 알림 세 개가 생성됩니다.
- 다시 알림이 울리지 않도록 설정되거나, 음소거되거나, 제한되지 않는 한 알림은 작업 빈도에 따라 작업을 생성합니다. 작업이 생성되면 해당 속성이 실제 값으로 채워집니다. 이 예에서는 임계값이 충족될 때 작업 세 개가 생성되고 템플릿 문자열
{{server}}가 각 알림에 맞는 서버 이름으로 바뀝니다. - Kibana는 작업을 실행하여 이메일 서비스 같은 타사 통합을 통해 알림 메시지를 보냅니다.
- 타사 통합에 연결 매개변수나 자격 증명이 있는 경우 Kibana는 적절한 커넥터에서 이를 가져옵니다.