#Monitoring

마이크로서비스 환경에서 요청이 어디서 느려지는지 어떻게 찾을까? OpenTelemetry로 로그·메트릭·트레이스를 하나로 묶어 병목을 정확히 짚어내는 법을 실전 코드와 함께 알아보자.

서비스가 죽었는데 12시간 동안 몰랐다. 1인 개발자가 최소한의 비용으로 서비스 상태를 감시하는 모니터링 스택을 구성한 경험.

유저가 카카오톡으로 '안 돼요'라고 보내기 전에 에러를 먼저 감지하고 싶었다. Next.js 프로젝트에 Sentry를 연동하면서 배운 실전 설정과 알림 구성.

배포 후 '잘 되는데요?' 했는데 사용자만 에러를 겪고 있었다. Sentry 도입 후 에러를 실시간으로 잡게 된 이야기.

서비스가 느리다는 항의를 받았는데, 로그파일만 뒤적거리다가 원인을 못 찾았던 경험이 있나요? Prometheus와 Grafana를 도입하여 '눈을 감고 운전하던' 상태에서 벗어난 경험과, 구글이 정의한 모니터링 4대 골든 시그널(Golden Signals)을 공유합니다.

서버가 100대로 늘어나면 로그 파일도 100개로 쪼개집니다. 에러가 났을 때 이 파일들을 하나하나 열어볼 수는 없죠. 흩어진 로그를 수집(L), 저장/검색(E), 시각화(K)하는 ELK Stack의 구조와, 최신 트렌드인 ELKB(Beats) 및 EFK(Fluentd) 스택으로의 진화 과정을 다뤄봤습니다.