4 key components:
- alert rules
Alert rules are how we define when an alert is triggered. - contact points
Contact points define where the message is sent when an alert rule is triggered. - notification policies
Notification policies allow you to specify where and how frequently you want alert notifications to be sent. - silences
Silences are a way to configure periods of time to suppress notifications.
https://www.cloudbees.com/blog/grafana-alerts-everything-you-need-to-know
만약 사용하게 된다면 알아놓으면 좋을 흐름
이런 식으로 슬랙에 webhook url 을 copy해서
grafana에 contact point 지정
condition에 trigger condition넣음, 빨간 선이 임계선
이점 etc.
api가 잘 정리되어있음, example request 등 document가 더 친절함
https://grafana.com/docs/grafana/next/developers/http_api/alerting/
- 대신 grafana alerting을 지원하는 버전인지 체크를 해야하긴 함
grafana dashboard를 control 할 수 있는 라이브러리 존재.
https://grafana.github.io/grafonnet-lib/api-docs/
의문점
지금 ui가 만들어져있는 grafana를 좀 더 편리하게 만드는 것일까?
-> 지금 heimdall에서 알림 서비스 조건을 설정할 수 있도록 해놓았기 때문에 여기다가 연동시키면 현재 입맛에 맞게 만들어놓은 웹콘솔에 편의성을 더할 수 있는 의도인듯
그런 의도도 있고, grafana는 prometheus 뿐만 아니라 지원하고 있는 datasource가 많음. log의 elastalert는 커뮤니티 지원도 약하고 지속적인 업데이트 부족도 있고, 심지어 오탐도 간헐적으로 일어나고 있다고 함. 지금은 metric만을 위해 grafana를 사용할 것이지만, 추후에 log도 grafana alerting으로 바꾸는 이점도 있음.
현재 사용하고 있는 ui가 따로 있는거라 지금 grafana ui 기능들을 그대로 거기랑 연결해야하는건가?
-> 맞고 아님. 현재 사용하고 있는건 heimdall console, 지금 grafana의 alert 기능을 거기다가 넣어주는 건 맞고 그대로는 아님. 사용성, 가독성을 고려해서 어떤 기능들을 넣어야할지 기획하고 고민해야 함
지금은 매트릭 모니터링을 grafana ui로 하나//? 그럼 바로 여기서 보는게 더 편한거 아닌가//?
-> 알림설정은 heimdall에서 관리하기때문에 metric 따로 log 따로 alert rule 생성하기에는 비효율적
