티스토리 뷰
개요
Pagerduty는 APM에서 수집한 지표를 활용하여 알람을 받아 이 알람을 가지고 다양하게 알람을 받을 수 있는 알람 서비스 오케스레이션입니다. 해당 글은 Pagerduty에서 알람이 받기 위해 하는 초기 설정과 설정의 개념을 담고 있는 내용 입니다.
본론
Service Directory
Service Directory는 Pagerduty에서 APM을 연동 하고, 연동하여 어떤 식으로 알람을 받아 온콜 담당자에게 연락을 취할 지를 가장 먼저 생성 해야 할 첫번째 단계 입니다.
Service Directory 생성하기 위해 이름 작성
다음은 Escalation Policy로 Pagerduty에서 온콜 담당자가 알람을 받지 못 하였을 때 그 다음 설정 or 생성한 온콜 담당자를 지정하여 알람이 가게 해주는 설정입니다. 지금 같은 경우에는 새로운 Escalation Policy를 생성 하겠습니다.
해당 설정은 Alert Grouping과 Transient Alerts이 있습니다.
Alert Grouping은 동일한 알람이 반복적으로 올 경우 온콜 담당자에 부하를 고려해 grouping하여 알람이 하나로 만들어 주는 설정입니다.
Transient Alerts는 일시적인 경고에 대해서 알람이 울리지 않게 해주는 기능으로 system 자체 auto healing이 될 경우 알람이 울리지 않는 기능으로 불필요한 알람을 줄여 줍니다.
해당 단계에서는 사용 중인 APM에서 보내주는 지표를 받는 것을 연동 하는 단계입니다. Pagerduty에서 말하기로는 750가지에 연동 방법을 제시 하고 있습니다. 이 글에서는 prometheus를 가지고 테스트를 해보겠습니다.
TEST 요약
시나리오
- container, non-container orchestration인 nomad로 서비스를 배포 하여 prometheus에서 각각 서비스에 지표를 받아 pagerduty를 통해 알람 및 장애 발생 시 미리 설정 된 초동 조치 및 해결 script를 실행
- 장애를 임의로 발생 시키기 위해 menu, login service down
- menu, login service가 down이 되면 prometheus에서 설정 된 alert-manager에서 pagerduty와 연동 되어 있기 때문에 알람을 온콜 담당자에게 SMS, 전화, app 알람, 메일으로 통지
- 콜을 받은 담당자는 사전에 미리 설정 한 workflow로 slack channel 생성 및 담당자 초대 와 알람 발생, google meet 생성 및 담당자 초대
- 미팅을 통한 결과 반영으로 automation action을 통해 문제 해결
2. Service running
현재 서비스 running 상태 확인
- Pagerduty에서는 APM 지표를 활용 하여 연동 할 수 있습니다.
- 위 예시는 api를 통해 연동이 되는지 테스트가 가능합니다.
- Prometheus에서 integration key를 alert-manager 설정을 하여 연동을 합니다.
3.Service down
- Pagerduty에서 장애 상황을 확인 하기 위해 단순 서비스 shut down
- Prometheus에서 해당 서비스에 상태가 down 된 것을 확인
Pagerduty 설정
- Pagerduty 내에서 연동 된 서비스에 대해 장애 발생 시 알람 발생 화면
- 해당 알람이 최근 30일 이내에 얼마나 발생되었는지 알 수 있습니다.
2. Acknowledged는 알람에 대해 인지가 되어 해당 알람에 대해 더 이상 오지 않음
3. Escalste는 on-call 첫 담당자가 알람을 받지 못 하였을 경우 다음 사람에게 알람을 보내줌
(해당 테스트는 본인을 escalstion을 하였음)
4.Reassign은 현재 on-call 대상 팀, 사용자 재 할당과 할당 되었을 때 어떤 단계에 on-call 담당자로 지정 할지에 대한 설정
5. Add Responders는 현재 참여하지 않은 다른 사용자에 대해 초대 할 수 있음
6. Run workflow는 알람 발생 시 사전에 미리 설정 해놓은 초동 조치를 설정하여 빠르게 slack channel 생성 및 담당자 초대, google meet 생성 및 초대등을 가능하게 해줌 테스트 incident workflow는 위 사진과 같이 정의 되어 있음
- Demo-workflow에 내용은 수동으로 workflow를 실행 시
- slack channel 생성 -> google meet 생성 -> on-call 담당자 추가 -> slack channel로 메세지 전달 -> 다른 team or user 초대 -> 알람 상태 업데이트
7. Run Actions는 장애 발생 시 초기 수집해야 되는 로그나 단순 서버 재기동과 같은 작업을 스크립트로 하여 사전에 설정 하여 클릭만 하여 스크립트를 실행 시킬 수 있습니다.(단 이 기능을 사용 하려면 runbook이라는 oss or rundeck이라는 사용 둘중 하나를 서비스가 배포 되어 있는 서버에 agent식으로 있어야함)
8. Send Status Update는 알람에 대한 모든 조치가 끝나고 나서 보고서 용으로 메일과 문자로 작업 완료 보고서를 보낼 수 를 수 있음
9. 해당 알람에 대한 우선 순위를 지정 할 수 있음
10. 해당 알람에 대한 상태가 발생이 되었는지, 인지 상태인지, 해결 상태인지 확인 할 수 있음
11. 해당 알람에 대한 조치 완료 시간을 알려줌
12. 해당 알람과 연관 된 다른 알람 서비스을 학습을 통해 Pagerduty에서 제안을 해줌
13. 해당 알람에 대해 세부 정보 내용을 보여줌
14. Past Incidents는 과거에 언제 일어났고 일어난 빈도수과 이력을 보여줌으로서 과거에 어떻게 해결 한지 알 수 있음
15. 연관 된 알람을 보여줌
Pagerduty에서 모바일 앱이 있는데 위와 같은 정보를 보거나 automation을 사전에 설정 해 놓은 것을 스크립트 실행 하는 것이 가능함
마무리
Pagerduty를 통해 서비스 배포 이후에 알람을 받아 이 알람을 가지고 어떤식으로 조치를 하고 조치 하는 시간에 대해 줄여 가기 위한 생각을 하게 됨
=> 다음에는 Pagerduty에서 각각의 Pagerduty Incidents에 대해 분기를 태울 수 있는 Event Orchestration를 볼 예정
끝
'IT > Pagerduty' 카테고리의 다른 글
| Pagerduty 2일차 (1) | 2024.06.02 |
|---|