Grafana, Zabbix의 아주 간단한 비교 및 기타 의식의 흐름대로 내뱉는 얘기들
오늘(10월 15일) 새벽 ElasticSearch (정확하게 말하면 Kibana를 통한 WebGUI 상) 에 더 이상 로그가 업데이트 되지않는다는 연락을 받았다. 원인은 Storage Full로 인한 로그 저장 불가.
데이빗한테 히스토리를 여쭤보니 원래 30일 주기로 Storage 정리를 하는데 이번에는 트래픽이 많아진건지, 개발자분들이 보려고 하는 로그가 많아서 그런건지 30일이 되기도 전에 Storage가 찼다고 한다.
일단 급하게 Storage는 증설했고, 어제와 같이 장애 상황을 예방하기 위해 모니터링을 걸어둘 필요성을 느꼈다. (‘빈틈없이 모니터링 하기’란 정말 쉬운 일이 아니라는 걸 또 한번 깨닫는다.)
_
모니터링 도구는 기존에 사용하던 Grafana를 사용하기로 했다. Grafana를 살펴보다보니 또 다른 모니터링 도구인 Zabbix와는 어떤 점이 다른건지 궁금했다.
‘Grafana vs Zabbix’라고 구글링해보니 두 제품의 차이점을 궁금해하는건 나뿐만이 아닌듯했다. 여러 포스팅을 읽고 내 나름대로 정리해보면…
Grafana는 ElasticSearch, Influx DB 등과 같은 데이터베이스에서 데이터를 가져와 ‘시각화’ 해주는 도구로서의 의미가 강했고, Zabbix의 경우 시각화보다는 ‘모니터링’ 도구라는 점에 좀 더 힘이 실려있었다.
Zabbix도 WebGUI 상으로 데이터 확인이 가능하다보니 ‘시각화’라는게 비단 Grafana만 제공하는게 아니지않나.. 싶었다. 근데 조금 더 생각해보면 타겟에 Agent를 심거나 SNMP 등을 통해 직접적으로 데이터를 가져와서 모니터링하는 Zabbix와 여러 Data lake에서 이미 수집된 데이터를 가져와 이를 시각화 해주는 Grafana는 엄연히 다른 개념이라는걸 알 수 있다.
그리고 한 가지 더! 나는 두 제품을 양자택일의 문제라고 생각했으나 두 제품은 공생?관계라고 할 수 있다. 즉, Zabbix만으로 모니터링을 하거나 Grafana로만 모니터링을 하는 것이 아닌 두 제품을 모두 사용해서 좀 더 탄탄한 모니터링 환경을 제공할 수 있다.
_
ElasticSearch의 Storage를 모니터링하고 알람을 받기 위해서 아래와 같은 순서로 진행했다.
- AWS CloudWatch에 ElasticSearch node(s)의 Free storage space를 metric으로 저장
- Grafana에서 해당 데이터를 가져옴
내 경우는 이미 Grafana가 생성이 되어있고, 데이터를 가져올 수 있는 Data source에 AWS CloudWatch가 추가되어있어서 위와 같은 작업만으로 내가 원하고자 하는 것을 확인할 수 있었다.
하지만 Grafana가 처음이라면 Data Source(데이터를 가져올 Origin. e.g. ElasticSearch, CloudWatch, InfluxDB 등)를 추가하는 과정이 필요할 것이다.
_
실제 서비스에 운영되는 Grafana라 스크린캡쳐는 못 가져오고.. 😿 빠른 시일 내에 내가 직접 Grafana를 구성하면서 다시 한번 자세히 포스팅하는걸로
🍰
