kit.tech

운영 신호를 한곳에서 확인할 수 있게 만든 관측 체계

관측·2026-08-31 기준
항목기록
문제서버 상태, 서비스 상태, 로그, 도메인 만료 정보가 여러 도구와 개인 지식에 흩어져 있어 장애·운영 이슈에서 무엇부터 확인할지 빠르게 판단하기 어려웠다.
기존 방식과 비용서버 접속, 로그 탐색, 서비스 상태, 도메인 상태를 각각 확인해야 했다. 구축 전 장애 타임라인이 없어 평균 대응시간 개선율은 산정하지 않는다.
제안/판단메트릭·로그·probe·알림을 분리 수집하되, 운영자가 Grafana에서 상호 확인할 수 있는 조회 흐름으로 묶었다.
기술 선택Grafana, Prometheus, Loki, Alloy. 서버·서비스·도메인·로그는 각 신호의 성격에 맞게 수집하고 대시보드와 알림 규칙으로 연결했다.
구현 범위서버와 NAS 신호, 서비스 가용성 probe, 도메인 만료, 애플리케이션·시스템 로그, 대시보드와 알림 규칙을 구성했다.
내 기여관측 체계 도입을 제안하고 수집 대상 정의, 대시보드·알림·로그 탐색 흐름, 운영 가이드의 설계·구현·문서화를 수행했다.
정량 결과서버 11대, service probe 42개, Prometheus target 79/80 (98.75%), 도메인 22개, 대시보드 9개 · 알림 규칙 9개.
연결 데이터관측 서버 (DATA-SCALE-SERVERS) · Prometheus 규모 (DATA-SCALE-PROMETHEUS) · Prometheus 정상 수집 (DATA-QUALITY-PROMETHEUS) · Grafana 구성 (DATA-SCALE-GRAFANA) · 서비스 probe (DATA-SCALE-PROBES) · 도메인 관측 (DATA-SCALE-DOMAINS)
공개 주의사항대시보드 캡처에서는 도메인, 호스트명, IP, 사용자명, 로그의 업무 식별정보를 가린다. 실제 운영 구성과 자격증명은 공개하지 않는다.
남은 검증현재 운영 규모는 가용성 또는 MTTR 개선율이 아니다. 구축 전 장애 타임라인과 대응 기록을 확보한 뒤 전후 비교를 별도 검증한다.

지연 원인 추적을 위한 Tempo 도입

항목기록
문제기능 출시 후 Slack 지연 알림이 발생했지만, 지연이 애플리케이션·DB·외부 API 중 어느 구간에서 발생했는지 바로 구분할 수 없었다.
기존 방식과 비용구간별 요청 시간을 연결해 볼 수 없어 원인 조사에 시간이 걸렸다.
제안/판단요청이 거치는 구간별 시간을 추적할 수 있도록 Grafana Tempo를 도입하기로 판단했다.
기술 선택Grafana Tempo와 Alloy를 사용해 트레이스 수집 설정을 구성했다. 기존 Ansible IaC를 활용해 관련 Alloy 설정을 빠르게 반영했다.
구현 범위사용자 설명 기준으로, 관련 서버의 Alloy 설정에 Tempo 연동을 적용하고 팀장 시연·검수를 거쳐 배포했다.
내 기여지연 원인 추적의 한계를 발견한 뒤 Tempo 도입을 결정하고, Ansible 기반 설정 반영과 시연·검수·배포 과정을 주도했다.
결과같은 날 팀장에게 시연하고 검수했으며, 다음 날 배포했다. 이는 관측 기능의 도입·배포 결과이며 해당 지연 사건의 원인 해결 또는 지연 감소를 의미하지 않는다.
출처사용자 설명 기준, 운영 증거 별도 확인 필요.
남은 검증Tempo가 적용된 서비스·경로 범위, 실제 트레이스 수집 여부, 지연 사건의 원인과 해결 여부, 조사 시간 또는 MTTR 변화는 운영 증거로 별도 확인해야 한다.

근거

지표는 포트폴리오 정본 data/metrics.yml(2026-08-31 기준)의 DATA-* 항목이다. 원본 응답·행 데이터는 저장하지 않는다.

공개 범위

이 글은 포트폴리오 정본의 공개 요약이다. 원본 업무 데이터와 회사·약국·서버·공급사 식별정보는 뺐다. 대시보드 캡처에서는 도메인, 호스트명, IP, 사용자명, 로그의 업무 식별정보를 가린다. 실제 운영 구성과 자격증명은 공개하지 않는다.