모니터링 도구를 에이전트 하나에 묶어 장애 첫 확인 맡기기

5xx 알림이 울리면 온콜 담당자는 탭부터 엽니다. Datadog 에서 모니터를 보고, Sentry 에서 스택트레이스를 찾고, 같은 시간대 로그는 OpenSearch 에서 다시 검색합니다. 방금 나간 배포가 있었는지는 GitHub 에서 확인합니다.

이 도구들을 에이전트 하나에 연결해 두면 그 확인을 한 문장으로 맡길 수 있습니다. “지난 1시간 동안 무슨 일이 있었어?“라고 물으면 에이전트가 도구를 차례로 조회하고, 근거를 붙여 정리해 줍니다. 연결에 코드는 필요 없습니다. 각 서비스에서 발급한 키를 폼에 붙여넣으면 됩니다.

이런 팀에 맞습니다

• 알림 하나에 대시보드 네다섯 개를 번갈아 여는 팀
• 온콜을 넘겨받을 때마다 “지금 뭐가 울리고 있지?“부터 다시 확인하는 팀
• 서비스마다 쓰는 모니터링 도구가 달라서 한곳에 모아 볼 방법이 마땅치 않은 조직

준비물

• endue 계정과 에이전트 1개
• 연결할 모니터링 도구의 API 키. 조회만 맡길 생각이라면 읽기 권한 키로 시작하세요

1. 모니터링 도구 연결하기

1. 왼쪽 레일에서 Abilities → Connectors 로 가서 탐색 탭을 엽니다. 모니터링 도구는 관측·인시던트 묶음에 모여 있습니다.
2. 연결할 도구를 누르면 그 도구로 에이전트가 무엇을 할 수 있는지 먼저 보여 줍니다. 확인했으면 연동을 누릅니다.
3. 폼에 연동 이름과 키를 넣고 연결을 누르면 끝입니다. 이름은 Datadog · prod 처럼 나중에 구분하기 쉽게 지어 두세요.

도구마다 폼에 넣는 값은 이렇습니다.

• Datadog: site, API key, Application key. site 는 브라우저 주소창의 app.datadoghq.com 을 그대로 붙여도 알아듣습니다
• Elasticsearch · OpenSearch: 클러스터의 https 주소, API key
• Grafana: Grafana 주소, 서비스 계정 토큰(glsa_ 로 시작)
• Sentry: 서버 주소(SaaS 는 https://sentry.io), 조직 slug, Auth token
• New Relic: region(us 또는 eu), 종류가 USER 인 API key(NRAK- 로 시작)
• PagerDuty: API key, 인시던트 조치를 남길 계정 이메일

OpenSearch 는 Elasticsearch 커넥터로 연결합니다. 검색·집계 API 가 같아서 그대로 조회됩니다. 다만 인증은 API 키(Authorization: ApiKey) 방식만 받기 때문에, 사용자 이름과 비밀번호로만 여는 클러스터는 아직 연결할 수 없습니다.

GitHub 와 Slack 은 키 대신 로그인 한 번으로 연결됩니다. 연결은 계정에 한 번 만들어 두면 여러 에이전트에 붙일 수 있습니다.

2. 에이전트에 붙이기

연결을 만들었다고 모든 에이전트가 그 도구를 쓰지는 않습니다. 어떤 에이전트가 어떤 도구를 쓸지는 에이전트마다 따로 정합니다.

1. 에이전트를 열고 상단에서 Studio 로 전환합니다. 캔버스에 에이전트의 구성이 한 장으로 펼쳐집니다.
2. 오른쪽 위 + 커넥터 추가를 누르고 내 커넥터 탭에서 방금 만든 연결을 고릅니다. 아직 연결하지 않은 도구라면 옆의 카탈로그 탭에서 바로 연결해도 됩니다.
3. 붙인 도구는 캔버스 오른쪽 열에 차례로 나타납니다.

커넥터 열을 누르면 이 에이전트에 붙은 연결 목록이 열립니다. 연결마다 지금 상태가 표시되고, 스위치로 잠시 끄거나 해제로 뺄 수 있습니다. 끄고 빼는 건 이 에이전트에만 적용되고, 연결 자체는 계정에 그대로 남습니다.

3. 확인 순서를 프롬프트에 적기

도구만 붙여도 에이전트는 질문에 맞는 도구를 골라 씁니다. 그래도 팀이 실제로 보는 순서를 적어 두면 답이 한결 일정해집니다. 캔버스에서 프롬프트를 열고 이렇게 적었습니다.

알림이나 질문을 받으면 이 순서로 본다.

1. Datadog: 해당 서비스 모니터 상태, 최근 1시간 에러 로그
2. Sentry: 새로 생긴 이슈와 가장 최근 스택트레이스, 어느 릴리스부터인지
3. OpenSearch: app-logs-* 에서 같은 시간대 요청 로그
4. GitHub: 그 시간 전후로 머지된 PR
5. PagerDuty: 열린 인시던트와 지금 온콜인 사람

답은 짧게 쓴다. 원인 후보에는 근거가 된 로그나 이슈를 붙인다. 모니터 뮤트, 인시던트 확인·해결, Slack 게시는 먼저 묻고 한다.

서비스 이름, 인덱스 패턴, 레포 이름처럼 팀에서만 쓰는 값을 적어 두면 에이전트가 되묻는 일이 줄어듭니다.

써 보기

채팅에서 알림 내용을 그대로 붙이거나 짧게 물어보면 됩니다.

checkout-api 5xx 알림이 왔어. 지난 1시간 동안 무슨 일이 있었는지 봐줘

에이전트는 Datadog, Sentry, PagerDuty 를 먼저 한꺼번에 훑습니다. 걸리는 게 보이면 Sentry 스택트레이스와 OpenSearch 로그, GitHub PR 로 좁혀 들어갑니다. 어떤 도구를 어떤 조건으로 불렀는지는 답 위에 그대로 남으니, 결론이 어디서 나왔는지 바로 따라가 볼 수 있습니다.

되돌리기 어려운 작업은 먼저 묻습니다

조회는 묻지 않고 바로 실행합니다. 알림을 끄거나 팀에 보이는 흔적을 남기는 작업은 실행 전에 승인 카드를 띄웁니다. 카드의 기본 선택은 취소라서, Enter 를 한 번 잘못 눌러도 실행되지 않습니다.

모니터링 도구 중 승인을 거치는 작업은 이렇습니다.

• Datadog 모니터 뮤트, Grafana 알림 사일런스
• PagerDuty 인시던트 확인·해결·노트 게시
• Sentry 이슈 해결·무시, New Relic 이슈 확인·종료

Slack 메시지 발송과 GitHub 이슈 생성도 같은 카드를 거칩니다.

운영 팁

• 매일 아침 점검: 채팅에서 “평일 오전 9시마다 이 점검을 해줘”라고 하면 루틴으로 만들어 둘 수 있습니다. 루틴은 지켜보는 사람 없이 돌기 때문에 뮤트처럼 승인이 필요한 작업은 실행하지 않고, 실행하지 않았다는 사실을 결과에 남깁니다.
• 상태 표시 먼저 보기: 키가 만료되거나 권한이 바뀌면 커넥터 목록의 상태 표시가 바뀝니다. 에이전트가 특정 도구에서만 헛도는 것 같다면 여기부터 확인하세요.