어두운 곳에서 디버깅을 멈추세요: ‘Day Zero’ Observability 체크리스트

Source: Dev.to

Introduction

최근 Picnic Engineering이 발표한 “Bringing Observability to the Workstation.” 라는 글을 읽었습니다. 이 글은 “깨끗한 코드”만으로는 생산 환경에 대한 가시성이 전혀 없을 때 충분하지 않다는 점을 상기시켜 줍니다.

우리 산업은 빠르게 움직이기 때문에 종종 기능을 배포하는 데에 집중하고, “나중에” 모니터링을 추가하겠다고 스스로에게 말합니다. 첫 번째 프로덕션 사고가 발생했을 때 우리는 눈이 멀어 버립니다. 버그가 발생하기를 기다렸다가 관측성을 구축하는 것은 위험도가 높은 도박이며, 처음부터 “최소한의” 레이어를 마련하는 것이 언제나 더 좋습니다.

“그것이 개발자들이 관측성에 — 혹은 관측성에 — 많은 시간을 투자해야 하는 주요 이유이다: 미스터리를 없애고 문제 해결을 위한 명확한 방향을 제공하기 위해.” – Eric Smith

특히 엣지 하드웨어와 상호 작용하는 분산 시스템을 구축하고 있다면, 이것이 당신의 절대 타협할 수 없는 체크리스트입니다.

The “Day Zero” Observability Checklist

Health Checks

• 표준 200 OK 응답은 프로세스가 실행 중임을 알려줄 뿐, 애플리케이션이 실제로 정상 동작하는지는 알려주지 않습니다.
• /health 엔드포인트를 만들어 애플리케이션 자체의 상태 와 의존성들의 상태를 모두 확인하도록 합니다.

Centralized Logging

• SSH를 통해 로그를 실시간으로 확인하는 것은 개발자에게 악몽과 같습니다.
• Datadog 혹은 Amazon CloudWatch와 같은 중앙 집중형 로거를 사용하세요. SSH는 “긴급 차단” 상황(예: 네트워크 파티션)에서만 사용하도록 제한합니다.
• 로그와 메트릭을 지속적으로 모니터링 서버로 전송하도록 로그 전송기(예: Fluentd 또는 Datadog Agent)를 배포합니다.

System Resource Metrics

• 시스템은 종종 높은 CPU 사용량, 메모리 누수, 디스크 I/O 포화 등으로 멈춰 버립니다. 메트릭이 없으면 이러한 실패는 “무작위” 논리 버그처럼 보입니다.
• CPU, 메모리, 디스크 I/O를 추적하여 메모리 누수와 같은 문제를 애플리케이션이 충돌하기 며칠 전부터 감지할 수 있습니다.

Alerts and Dashboards

• 대시보드는 과거 데이터를 분석하기 위한 것이고, 알림은 즉각적인 조치를 위한 것입니다.
• 다음 항목에 대한 알림을 설정하세요:
  • 지속적인 고 CPU 사용량
  • 높은 메모리 사용량
  • 애플리케이션 수준 예외
  • 서비스와 관련된 기타 중요한 임계값

Node “Pulse” Monitoring

• 분산 시스템에서 가장 흔한 장애 유형은 정적 상태, 즉 노드가 인터넷 연결을 잃어 “실패” 로그를 전송하지 못하고 사라지는 경우입니다.
• 해결책: 각 노드가 중앙 모니터에 주기적인 “펄스”를 전송하도록 합니다. 펄스가 멈추면 노드 자체가 문제를 보고하지 못하더라도 네트워크 파티션이나 전원 장애가 즉시 감지됩니다.

Conclusion

이 최소한의 스택을 구현함으로써 “추측”에서 “알아냄”으로 전환할 수 있습니다.

다른 어떤 메트릭을 리스트에 추가해야 할까요? 댓글로 의견을 공유해 주세요.