안녕하세요. J4J입니다.
이번 포스팅은 grafana alert rule을 활용하여 slack 알림 설정하는 방법에 대해 적어보는 시간을 가져보려고 합니다.
관련 글
Kubernetes 모니터링을 위한 Prometheus, Grafana 개념 정리
Kubernetes 모니터링을 위한 Prometheus, Grafana 개념 정리
안녕하세요. J4J입니다. 이번 포스팅은 kubernetes 모니터링을 위한 prometheus, grafana 개념에 대해 적어보는 시간을 가져보려고 합니다. Kubernetes 모니터링이 필요한 이유 kubernetes 환경에서 여러 개의 po
jforj.tistory.com
Helm으로 설치하는 Kubernetes 모니터링: Prometheus와 Grafana 실습 (Docker Desktop)
Helm으로 설치하는 Kubernetes 모니터링: Prometheus와 Grafana 실습 (Docker Desktop)
안녕하세요. J4J입니다. 이번 포스팅은 helm으로 kubernetes 모니터링을 위한 prometheus, grafana 설치하는 방법에 대해 적어보는 시간을 가져보려고 합니다. 관련 글 Helm 이란? Helm 입문을 위한 기본 개념
jforj.tistory.com
Kubernetes 모니터링 구축: Helm으로 kube-prometheus-stack 설치하기 (Docker Desktop)
Kubernetes 모니터링 구축: Helm으로 kube-prometheus-stack 설치하기 (Docker Desktop)
안녕하세요. J4J입니다. 이번 포스팅은 kubernetes 모니터링을 위한 helm으로 kube-prometheus-stack을 설치하는 방법에 대해 적어보는 시간을 가져보려고 합니다. 관련 글 Helm 이란? Helm 입문을 위한 기본
jforj.tistory.com
Kubernetes에서 Spring 애플리케이션 Metric 수집하여 모니터링하기: Prometheus & Grafana 연동
Kubernetes에서 Spring 애플리케이션 Metric 수집하여 모니터링하기: Prometheus & Grafana 연동
안녕하세요. J4J입니다. 이번 포스팅은 kubernetes에서 spring 애플리케이션 metric 수집하여 prometheus와 grafana를 이용한 모니터링 방법에 대해 적어보는 시간을 가져보려고 합니다. 관련 글 Kubernetes 모
jforj.tistory.com
Alert Rule 이란 ?
grafana의 alert rule은 grafana에서 확인할 수 있는 metric 정보들을 모니터링하고 있다가 특정 조건에 만족하면 사용자에게 알림을 전달하는 기능을 제공합니다.
많이 예상될 수 있지만 alert rule을 사용하는 경우 다음과 같은 이점들을 가져올 수 있습니다.
- 항상 대시보드를 확인하지 않고, 원하는 조건에 맞는 모니터링을 수행할 수 있음
- 애플리케이션에 문제가 발생하는 경우를 감지하여 문제 해결을 도울 수 있음
- slack, teams 등의 협업 툴로 알림을 제공하여 사용자의 상황 인지를 도움
alert rule을 사용하기 위해서는 다음의 개념들에 대해 숙지하고 있어야 합니다.
[ 조건 정의 ]
조건을 정의한다고 하는 것은 grafana에 연결되어 있는 다양한 data source (ex, prometheus) 들을 이용하여 metric을 조회하여 알림 처리가 발생하는 기준을 정의하는 것입니다.
대표적으로 cpu / memory 사용량이 전체 resource의 80%가 넘는 경우 등과 같은 조건을 정의할 수 있습니다.
결국 알림을 받고자 하는 각 서비스 별 기준치에 따라 서로 다른 정의가 이루어질 것이며, 1개 이상의 metric 정보를 조회하여 기준치에 맞는 조건들을 정의해볼 수 있습니다.
[ alert rule 상태 ]
alert rule의 상태는 총 4가지가 있습니다.
- Normal
- Pending
- Firing
- Resolved
먼저 normal은 어떠한 문제도 발생하지 않은 상태를 의미합니다.
설정한 조건에 부합하지 않기 때문에 normal로 상태가 되어 있다면 문제가 없다는 것을 의미합니다.
pending은 조건 정의한 것에 부합한 상태가 되었지만 firing으로 넘어가기 전 상태를 의미합니다.
firing으로 넘어가기 위해서는 설정한 일정 시간이 지나야 하며, 잠깐 발생한 이슈로 인해 바로 알림이 가지 않고 진짜 문제가 발생한 것인지를 확인하는 단계입니다.
물론, 한 치의 에러도 발생하면 안 되는 서비스에서는 설정을 통해 pending 과정이 없게 설정할 수도 있습니다.
하지만 일반적으로 갑자기 cpu가 튀거나 또는 다른 이슈로 인해 잠깐 문제가 발생한 상태까지 알림을 받지 않아도 된다고 생각하기에 pending이 적극적으로 활용됩니다.
firing은 pending 상태에서도 문제가 지속적으로 발생하여 실제로 문제가 발생했다고 인지하는 상태입니다.
firing 상태가 되면 설정한 알림들도 모두 발송이 되며 이 상태에서는 서비스에 장애가 발생되었을 확률이 높기에 서비스 운영자들은 문제를 파악하고 해결해야 됩니다.
resolved는 firing 상태에서 문제가 해결되었다는 상태를 의미합니다.
firing에서 문제가 해결되면 resolved 상태로 변경될 수 있으며, resolved 상태에서도 일정 시간이 지나면 normal 상태로 변경이 이루어집니다.
[ 평가 주기 / 펜딩 주기 ]
평가 주기는 alert rule에 등록된 알림을 얼마나 자주 반복해서 상태를 확인하는지를 설정하는 곳입니다.
모든 상태가 넘어가는 것의 기준 값은 평가 주기가 되며, 항상 각 상태에 맞는 상황이 발생하더라도 즉시 반영되지는 않고 평가 주기마다 상황을 확인하여 상태 값이 변경됩니다.
평가 주기는 평가 그룹을 통해 함께 설정이 되며 어떤 평가 그룹에 알림이 속해 있는지에 따라 평가 주기가 서로 다를 수 있습니다.
펜딩 주기는 pending 상태가 얼마나 지속되는 것인지를 설정하는 곳입니다.
예를 들어, 펜딩 주기는 5분으로 되어 있고 평가 주기가 1분으로 되어 있는 상황에서 pending 상태가 된 지 3분이 지난 상태에서 평가 주기가 다시 도달하더라도 펜딩 주기가 아직 도달하지 않았기 때문에 firing 상태로 넘어가지 않게 됩니다.
위에서 얘기한 것처럼 일시적인 문제가 발생한 것들을 항상 firing 단계로 넘기지 않고 진짜로 문제가 발생한 것이라고 판단되는 시간 설정이 필요할 때 펜딩 주기가 활용됩니다.
[ contact point ]
contact point는 알림이 전달될 서비스를 설정하는 곳입니다.
firing 상태가 되었을 때 함께 설정되어 있는 contact point로 알림이 전달되며, grafana에서는 contact point로 사용되는 곳을 정말 다양하게 지원합니다.
이번 글에서 활용할 slack을 포함하여 email, aws sns, teams, jira 등 여러 팀원들과 많은 소통이 이루어지는 정말 다양한 협업 툴들이 사용될 수 있습니다.
contact point를 어디로 하는지에 따라 각 contact point 별 설정 방식이 조금씩 달라질 수 있지만, 전체적으로 사용하는 방식은 거의 동일합니다.
그래서 한 contact point만 사용해 보더라도 다른 contact point를 설정하는 것은 크게 어려움이 없을 것이라고 생각합니다.
알림 받을 Slack 설정
contact point로 slack을 설정할 것이기 때문에 알림을 전달받을 slack 채널을 구성해야 합니다.
새로운 워크 스페이스를 생성하는 것부터 시작하는 경우 알림 전달 받을 slack 채널을 다음 순서대로 구성해 볼 수 있습니다.
[ 1. 워크스페이스 생성 ]
가장 먼저 Slack 메인 페이지에 접속합니다.
그러면 우측 상단에 "새 워크스페이스 개설" 버튼이 보이게 되고, 버튼을 클릭하여 다음 단계로 넘어가 줍니다.
1단계로 워크스페이스 이름을 다음과 같이 자유롭게 입력해 줍니다.
2단계로 개인 정보를 다음과 같이 자유롭게 입력해 줍니다.
3단계로 동일한 워크스페이스에 초대되어야 하는 사람의 이메일 정보를 입력해 줍니다.
지금 당장 초대를 원치 않는 경우 건너뛰기를 할 수도 있습니다.
그러면 플랜에 대한 이야기가 나올 것이고, 각자의 플랜에 맞춰 최종적으로 워크스페이스를 생성할 수 있습니다.
[ 2. 알림 받을 채널 생성 ]
이번에는 워크스페이스 내부에서 grafana alert rule을 통해 알림 전송이 되는 경우 수신이 이루어질 채널을 생성해 보겠습니다.
생성한 워크스페이스 왼쪽을 보면 다음과 같이 "채널 추가"라는 버튼이 보이게 되는데 버튼을 클릭한 뒤 "새 채널 생성"까지 눌러줍니다.
다음으로 원하는 형태의 채널 템플릿을 선택해 줍니다.
특별한 목적이 없다면 빈 채널로 해주시면 됩니다.
마지막으로 채널의 이름을 입력해 줍니다.
그리고 채널이 보여야 하는 가시성 설정이 필요한 경우에도 자유롭게 설정을 해주시면 됩니다.
[ 3. webhook 앱 추가 ]
grafana에서 slack에 알림을 전달하는 방법은 slack의 webhook을 사용하는 방식입니다.
그래서 webhook 앱을 추가하는 과정도 필요합니다.
왼쪽을 보면 "앱 추가"라는 버튼이 다음과 같이 보입니다.
버튼을 클릭하여 앱을 추가해 보겠습니다.
검색어에 "incoming webhooks"라고 입력을 해보겠습니다.
그러면 목록에 검색어에 부합한 앱이 조회될 것이고, 설치 버튼을 클릭하면 페이지 하나가 나올 텐데 이곳에서 "Slack에 추가" 버튼을 클릭해 주시면 됩니다.
페이지가 이동되어 채널을 선택하는 페이지가 나오는 것을 확인할 수 있습니다.
이곳에서는 위에서 알림을 받기 위해 생성한 채널을 선택하고 "앱 추가" 버튼을 클릭합니다.
[ 4. webhook url 확인 ]
위에서 버튼을 클릭한 경우 페이지가 이동될 것이고, 이동된 페이지에서는 해당 채널에 대한 webhook url을 확인할 수 있습니다.
webhook url 정보는 grafana alert rule 설정할 때 사용될 예정이기에 다음 작업을 위해서는 원본 url 정보를 그대로 확인할 수 있어야 합니다.
이 외에도 webhook을 통해 메시지를 전송하는 방법과, 채널 재 정의하는 방법, 앱에 의해 알림이 전달될 때 전달하는 사용자의 이름을 무엇으로 할 것인지 등 다양한 설정들을 할 수 있습니다.
각 설정들은 알림을 제공하려는 상황에 따라 자유롭게 설정해 주시면 됩니다.
Grafana Alert Rule 설정
이번에는 grafana에 접속하여 위에 설정한 slack 채널에 알림을 전송할 수 있는 alert rule을 생성해 보겠습니다.
[ 1. contact point 설정 ]
위에서 설명한 대로 contact point는 알림이 전달될 곳을 의미하며, 이 글에서는 slack이 됩니다.
생성한 slack webhook url을 contact point로 등록해 보도록 하겠습니다.
grafana 좌측 메뉴를 살펴보면 "Contact points"라고 존재합니다.
메뉴를 선택한 뒤 우측에 존재하는 "Create contact point" 버튼을 클릭해 줍니다.
다음은 contact point에 대한 정보를 입력합니다.
버튼을 클릭하여 이동된 페이지에서 이름, integration, webhook url을 다음과 같이 순차적으로 입력해 줍니다.
Test 버튼을 클릭하여 연동되어야 하는 채널에 테스트 알림이 올바른 게 오는지도 확인할 수 있습니다.
정보에 문제가 없다면 contact point를 최종적으로 저장합니다.
[ 2. 알림 템플릿 구성 ]
이번에는 알림을 전달받을 템플릿 구조를 잡아보겠습니다.
contact point 메뉴 그대로 위쪽을 보면 Notification Templates라는 탭이 존재합니다.
탭을 클릭하여 알림 템플릿 그룹 추가 버튼을 클릭합니다.
기본적으로 존재하는 템플릿 그룹을 사용할 수도 있지만, 다음과 같이 전달받고자 하는 알림 템플릿을 커스터마이징 하여 원하는 형태로 알림을 받을 수도 있습니다.
저 같은 경우 기본적으로 제공되는 알림 템플릿을 참고하여 다음과 같이 나의 서비스를 위한 템플릿을 만들어 볼 수 있었습니다.
혹시나 템플릿에 담겨 있는 정보가 필요하신 분들이 있을 경우를 대비하여 작성한 내용을 다음과 같이 공유합니다.
{{ define "slack.base-alert.message" }}
{{ range .Alerts }}
{{ if eq .Status "firing" }}🔴 알람 발생 메세지
{{ else if eq .Status "resolved" }}🟢 알람 해제 메세지
{{ end }}
- 현재 상태: {{ .Status }}
- URL : {{ .GeneratorURL }}
- Silence : {{ .SilenceURL }}
{{ end }}
- Folder 명 : {{ .CommonLabels.grafana_folder }}
- Alert 명 : {{ .CommonLabels.alertname }}
- 제목 : {{ .CommonAnnotations.summary }}
- 설명 : {{ .CommonAnnotations.description }}
{{ end }}
우측에 존재하는 Refresh 버튼을 클릭하면 템플릿에 작성한 정보와 아래에 있는 Payload 정보를 조합하여 어떤 형태의 알림이 최종적으로 전달되는지를 확인할 수 있습니다.
기본적으로 제공되는 Payload 정보를 통해 템플릿 결과를 확인하면 비어이는 정보들이 존재할 수 있지만, slack을 통해 실제로 알림을 받을 땐 모두 정보가 채워져 있다는 점은 참고 부탁드립니다.
최종적으로 원하는 템플릿 구조 설정이 완료되었다면 템플릿을 저장해 주시면 됩니다.
[ 3. contact point에 알림 템플릿 연동 ]
작성한 알림 템플릿은 contact point에 연동을 해줘야 올바르게 사용될 수 있습니다.
contact point 목록으로 다시 돌아가서 위에서 생성했던 contact point를 찾아 "Edit" 버튼을 클릭합니다.
그리고 아래에 있는 "Optional Slack settings"를 선택하여 열어줍니다.
아래로 내려서 Text Body 항목을 찾아준 뒤 "Edit Text Body"를 클릭합니다.
그리고 notification template에 위에서 define으로 정의해 둔 이름을 조회하여 설정하면 다음과 같이 text body에 template이 적용된 것을 확인할 수 있습니다.
[ 3. alert rule 설정 ]
설정이 모두 완료되었다면 어떤 상황에서 알림을 받을 지에 대한 rule을 설정해 보겠습니다.
grafana 좌측 메뉴에서 "Alert rules"를 선택해 줍니다.
그리고 우측 상단에 있는 "New alert rule" 버튼을 클릭합니다.
이전 글에서 로그인 요청에 대한 metric 수집 정보를 grafana에서 확인할 수 있도록 설정해 둔 것이 있습니다.
해당 정보를 이용하여 최근 로그인 실패 추이가 높아지는 경우에 대한 알림을 받는 alert rule을 설정해보려고 합니다.
alert rule의 경우 "Advanced options"를 열어주고 "Code" 형태로 작성할 것이며 "login_request_total" metric 정보를 활용합니다.
최종적으로 최근 10분 간 로그인 요청 중 실패 비율이 0.2가 넘는 경우 Firing 상태가 되도록 다음과 같이 설정할 수 있습니다.
다음으로는 알림을 구성할 폴더 정보와 평가 그룹 및 평가 주기, 펜딩 주기, keep firing for 설정을 할 수 있습니다.
폴더 같은 경우는 단순하게 알림이 속했으면 하는 폴더 구조를 설정해 주시면 됩니다.
평가 그룹 같은 경우는 평가 주기 설정과 연관이 있습니다.
1개의 평가 그룹에는 평가 주기 설정이 함께 이루어지며, 동일한 그룹에 속한 알림 들은 동일한 평가 주기 설정이 이루어집니다.
펜딩 주기는 위에서 설명한 것과 동일하게 펜딩이 지속되는 설정을 다룹니다.
마지막으로 keep firing for은 평가 주기에 의해 resolve 상태로 변경될 수 있음에도 firing 상태로 유지될 시간을 설정하는 곳입니다.
각 항목들은 개별적으로 원하는 구조에 맞춰서 값을 넣어주시면 됩니다.
마지막으로 alert rule에 의해 알림이 발송될 contact point에 대한 설정과, 어떠한 내용을 전달할지 입력해 주면 됩니다.
내용의 경우 위에서 설정한 알림 템플릿과 헷갈릴 수 있지만, 이곳에서 입력되는 정보는 알림 템플릿의 변수로 사용되고 있는 summary와 description 정보입니다.
알림이 발생하게 된 상세 값들은 alert rule 내부에서 확인할 수 있기 때문에 각자 상황에 맞는 정보들을 다음과 같이 작성해 줄 수 있습니다.
알림 발송 테스트
alert rule 설정까지 완료되었다면 alert rule 목록 페이지에 다음과 같이 등록한 alert rule의 상태가 어떤지 확인할 수 있습니다.
이 상태에서 설정해 둔 threshold 정보를 넘게 되면 다음 평가 주기가 지나는 경우 다음과 같이 pending 상태로 변경됩니다.
그리고 펜딩 주기 설정에 따라 3분이 지나면 다음과 같이 firing 상태로 변경되는 것을 볼 수 있습니다.
firing 상태로 변경됨과 동시에 slack에 알림이 오는 것도 확인할 수 있습니다.
저 같은 경우 다음과 같이 slack에 알림이 전달되었습니다.
그리고 로그인이 다시 잘 되기 시작하는 경우 평가 주기에 도달했을 때 다음과 같이 다시 normal 상태로 돌아오는 것도 확인할 수 있습니다.
하지만 firing 상태에서 resolved 처리가 되었는데도 slack 채널에 알림이 바로 전달되지 않는 상황을 겪을 수 있습니다.
바로 전달 되지 않는 이유로는 notification policy 설정 때문인데, 저 같은 경우 한 번에 알림을 전송하기 위해 알림을 보내기 전 5분 동안 대기하는 설정이 기본적으로 잡혀 있습니다.
그래서 resolved 처리가 된 이후 5분이 지나면 slack에 다음과 같이 알림 해제에 대한 메시지가 전달된 것을 확인할 수 있습니다.
이상으로 grafana alert rule을 활용하여 slack 알림 설정하는 방법에 대해 간단하게 알아보는 시간이었습니다.
읽어주셔서 감사합니다.
'Infra, Cloud > Kubernetes' 카테고리의 다른 글
| Istio Metric을 Prometheus로 수집하기: ServiceMonitor/PodMonitor 활용 (0) | 2025.10.19 |
|---|---|
| Kubernetes Service Mesh 구축 가이드: Istio에 대한 이해와 Istio Operator 설치 방법 (0) | 2025.10.12 |
| Kubernetes 모니터링 구축: Helm으로 kube-prometheus-stack 설치하기 (Docker Desktop) (0) | 2025.09.02 |
| Helm으로 설치하는 Kubernetes 모니터링: Prometheus와 Grafana 실습 (Docker Desktop) (1) | 2025.08.26 |
| Kubernetes 모니터링을 위한 Prometheus, Grafana 개념 정리 (1) | 2025.08.18 |
댓글