여러 대의 장비를 감시해야 했다. 각각의 상태를 SNMP 로 모아 MySQL 에 쌓고 화면으로 보는 구조를 처음부터 만들었다.
Table of contents
Open Table of contents
무엇을 잴지부터
SNMP 도구를 고르기 전에 무엇을 잴지를 적었다.
장비마다
동작 여부 (살아 있나)
처리량
오류 수
온도
전력
그리고 각각에 대해 왜 재는지도 적었다.
동작 여부 죽으면 알아야 한다
처리량 성능 추세를 본다
오류 수 이상을 감지한다
온도·전력 환경 문제를 찾는다
왜 재는지 못 적는 것은 안 쟀다. 재는 것도 비용이고 쓸 데 없는 지표는 MySQL 자리만 차지하고 화면을 복잡하게 만든다.
비교 — 보내는 쪽과 받는 쪽
장비가 보내게 할지 서버가 물어보게 할지 정해야 했다.
SNMP 트랩처럼 장비가 던지는 방식은 장비가 늘어도 서버 설정을 안 바꾼다. 대신 안 오면 그것이 죽은 것인지 네트워크 문제인지 모른다.
snmpget 으로 물어보는 방식은 서버가 주기적으로 조회하므로 응답이 없으면 명확하다. 대신 장비 목록을 서버가 알아야 한다.
SNMP 는 둘 다 있는데 물어보는 방식으로 갔다. 장비 수가 고정이고 안 온다의 해석이 명확한 것이 중요했다.
주기와 보관 기간을 정했다
너무 자주 재면 부하가 되고 MySQL 에 쌓이는 양이 많아지며 드물게 재면 놓친다. 지표마다 다르게 정했다.
동작 여부 10초
처리량 1분
온도 1분
전력 5분
빨리 알아야 하는 것만 자주 쟀다.
초 단위 자료를 MySQL 에 영원히 쌓을 수는 없어서 기간에 따라 해상도를 낮추기로 했다.
최근 2일 원본
2일~2주 1분 평균
2주~6개월 1시간 평균
6개월 이상 1일 평균
요약할 때 평균만 남기지 않고 최소와 최대를 함께 남겼다. 피크가 사라지면 장애 분석을 못 한다.
알림을 나중에 붙였다
처음엔 알림을 안 넣었는데 평소 값을 모르니 임계를 정할 수 없었다.
2주쯤 MySQL 에 데이터를 모으고 나서 붙였다.
평소 처리량: 100~140
평소 온도: 35~45도
이것을 알고 나서 임계를 정했다. 처음부터 감으로 정했으면 오탐이 많았거나 아예 안 울렸을 것이다.
감시 자체를 감시했다
처음엔 SNMP 로 모은 지표를 다 그려서 화면이 복잡했고 보는 사람이 무엇을 봐야 하는지 몰랐다.
두 화면으로 나눴다. 요약 화면은 장비별 상태 하나씩만 보이고 정상이면 초록 이상이면 빨강이라 한눈에 본다. 상세 화면은 특정 장비를 누르면 그 장비의 모든 지표가 나온다.
평소엔 요약만 보고 이상할 때 상세로 들어간다.
한 번은 수집기가 죽었는데 몰랐다. 화면이 마지막 값으로 멈춰 있었고 값이 멈춘 것과 값이 안 변하는 것이 화면상 같았다.
두 가지를 넣었다. 마지막 수집 시각을 화면에 표시했고 cron 이 한 바퀴 돌 때마다 MySQL 에 자기 기록을 한 줄 남기게 했다.
그 값이 안 늘면 수집기가 죽은 것이다. 감시 체계를 만들면 그것도 감시해야 한다.
정리
- 도구를 고르기 전에 무엇을 왜 재는지 적고 못 적으면 안 잰다
- 쓸 데 없는 지표는 저장 자리만 차지하고 화면을 복잡하게 만든다
- 보내는 방식과 물어보는 방식은 안 온다의 해석이 다르다
- 주기를 지표마다 다르게 정하고 빨리 알아야 하는 것만 자주 잰다
- 보관은 기간에 따라 해상도를 낮춘다
- 요약할 때 최소와 최대를 함께 남겨야 피크가 안 사라진다
- 평소 값을 모르면 임계를 못 정하므로 모으고 나서 알림을 붙인다
- 화면을 요약과 상세로 나누고 평소엔 요약만 본다
- 감시 체계 자신도 감시하고 마지막 수집 시각과 수집기 지표를 둔다