문서 갱신
이 문서는 꾸준히 갱신할 계획입니다. 의견주시면 적극 반영하겠습니다.
모니터링 체계를 구축하고 가시성을 확보하기는 상대적으로 쉽다. 좋은 솔루션과 약간의 경험을 가미하면 순식간에 그럴듯한 수준까지 밀어올린다. 물론 운영의 자동화 수준과 조직 구성원의 의지를 전제로 하는 말이다. 그러나 모든 체계는 녹이 슬기 마련이다. 시간이 흐르면 일부 지표가 수집 안 되기도 하고, 애플리케이션의 행동 양태가 바뀐다. 그렇게 녹이 슬고 부식이 심화되면 문제가 심각해진다. 어느 순간 장애가 난다. 분명히 전에 알람을 걸어놨는데 왜 사고가 나기 전에 알람이 안 울렸을까?
이에 대응하는 가장 좋은 방법은 이해관계자가 한달에 몇번 한자리에 모여 대시보드를 훑어보며 문제가 없는지 눈으로 확인하는 것이다. DataDog, NewRelic, Elastic 등을 번갈아 확인하면 시간이 잘 간다. 처음에는 시간이 꽤 걸리고 할 일이 많다. 하지만 몇 달 지나면 별다른 이슈가 없고 할 일이 줄어든다. 그때가 오면 한달에 한번으로 회의를 줄인다던가 상황에 맞춰 유연하게 대처하면 된다. 주기적으로 눈으로 확인하고 검증하되 이해관계자가 다 같이 모인다는 점이 중요하다. 그래야 문제의식을 공유하고 해법을 조직에 내재화할 수 있다.
다음과 같은 사항을 감안해서 회의를 진행하면 된다. 이 글에서는 회의에서 다뤄야 할 주제를 간략히 설명하고 다음 글에서는 구체적으로 어떤 메트릭과 이벤트를 살펴보면 되는지 살펴보자.
- DataDog Monitor를 훑어보며 알람이 울린 것을 살펴본다. 알람이 울렸는데 대응하지 않는 이유는 무엇인가? 유효하지 않기 때문인가? 아니면 적절한 사람에게 알람이 가지 않았기 때문인가? 아니면 알람이 너무 잦아서 담당자가 알람을 무시하는가?
- 알람 조건이 유효한지 확인한다. 어떤 이벤트는 이벤트 소스가 바뀐다.1예를 들면 Amazon EC2에서 Amazon Health로
- 대시보드를 훑어보며 지표가 제대로 나오는지 확인한다.
- 대시보드를 훑어보며 어떤 용도인지 개선할 점은 없는지 논의한다.
- 특정 메트릭과 이벤트의 수집이 멈추는 경우가 종종 있다. 때로는 수집 방법이 달라져서 다른 메트릭이나 이벤트로 대체해야 한다. 알람을 훑어보며 수집 안 되는 정보가 있는지 확인한다.
- 로그량이 많은 애플리케이션을 확인한다. 대체로 한두 개의 로그가 전체 로그의 70% 정도를 차지한다. 해당 로그가 진짜 문제를 보여준다면 문제를 해결한다. 그러고 나서 ElastAlert 등을 이용해 알람을 건다.
- 문제가 없고 쓸데없는 로그가 과하다면 애플리케이션을 수정하거나 로그를 수집하는 과정에서 필터링한다. DataDog Agent 나 Fluentd 같은 Log forwarder 에서 필터링하거나 DataDog Log Pipeline처럼 전체 파이프라인의 뒤쪽에서 처리해도 된다. 앞에서 필터링하면 전체 파이프라인의 비용2스토리지와 네트워크 등을 줄이는 장점이 있다. 뒤에서 필터링하면 어쩌면 다른 곳에선 유효할지 모르는 데이터를 보존하는 의미가 있다.
- DataDog Event를 훑어보며 로그와 마찬가지로 문제가 없는지 확인한다. 필요하면 조치를 취하고 알람을 건다.
- DataDog Network Monitoring 의 흐름을 살펴보며 이상징후가 없는지, 비용을 낭비하는 곳은 없는지 확인한다.
- 신기능을 훑어보고 도움될만한 사용 시나리오가 있는지 검토한다.
Author Details
Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.