[모니터링] 모니터링 파이프라인 설계 해보기

개인적인 사정으로 애플리케이션 모니터링을 위한 파이프라인을 설계해야했다.

 

🙋🏻 애플리케이션 모니터링

"애플리케이션 모니터링"은 소프트웨어 애플리케이션 내의 성능, 가용성 및 오류에 초점을 맞춥니다. 이러한 유형의 모니터링은 애플리케이션이 원활한 사용자 경험을 제공하는 데 필수적입니다.

성능:
애플리케이션 성능 모니터링에는 응답 시간, 트랜잭션 속도 및 처리량 추적이 포함됩니다. 이는 사용자 경험에 영향을 줄 수 있는 병목 현상과 성능 문제를 식별하는 데 도움이 됩니다. New Relic 및 AppDynamics와 같은 도구는 애플리케이션 성능에 대한 자세한 통찰력을 제공합니다.

가용성:
애플리케이션을 사용자가 사용할 수 있고 액세스할 수 있도록 하는 것이 가장 중요한 관심사입니다. 애플리케이션 모니터링 도구는 가동 시간과 가동 중지 시간을 추적하여 팀에 중단을 경고하고 서비스를 복구하기 위해 신속하게 대응할 수 있도록 돕습니다.

오류:
애플리케이션 오류 모니터링에는 오류 로그, 예외 및 충돌을 캡처하고 분석하는 것이 포함됩니다. 이는 버그를 진단하고 수정하고 애플리케이션 안정성과 신뢰성을 개선하는 데 도움이 됩니다. Sentry와 Rollbar는 오류 모니터링을 위한 인기 있는 도구입니다.

출처: https://www.atmosly.com/blog/open-source-monitoring-tools

 

나는 모니터링을 위해선 로그 데이터 + 매트릭 데이터(시계열 데이터)가 함께 제공되어야

매트릭 데이터를 통해 문제가 발생했을 때 즉각적으로 알아차릴 수 있고,

문제 발생 시 로그 데이터를 통해 문제의 원인을 자세히 파악할 수 있다고 이해했다.

 

애플리케이션 모니터링 파이프라인

첫 설계에서 로그 데이터와 매트릭 데이터에 모두 특화된 오픈소스를 찾고자 많은 시간을 썼다.

 

하지만, 두 데이터를 최적화하는 방법과 적절한 시각화 방법이 모두 다르기 때문에

오픈소스들이 둘 중 어느 하나에만 특화된 경우가 대부분이었다.

 

예를 들어,

 

데이터 수집

• 로그 데이터: Filebeat, Fluentd
• 매트릭 데이터: Telegraf, Prometheus Node Exporter

데이터 저장

• 로그 데이터: Elasticsearch
• 매트릭 데이터: InfluxDB, Prometheus

데이터 시각화

• 로그 데이터: Kibana
• 매트릭 데이터: Grafana

 

등 각 파트 별로 나누어졌고,

심지어 데이터 저장소 별로 특화된 데이터 전송 툴도 달라서 열이 뻗쳤다.

 

아무래도 로그 데이터, 매트릭 데이터를 각각 수집하는 방안을 찾아봐야 될 것 같다는 생각이 들어 수정 중이다.

 

다음 글에선, 설계한 파이프라인 소개와 각 오픈소스 선택 이유에 대해 정리해보겠다.