Skip to content
isdnetworks
Go back

처음 감시 체계를 세우며

여러 대의 장비를 감시해야 했다. 각각의 상태를 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 에 자기 기록을 한 줄 남기게 했다.

그 값이 안 늘면 수집기가 죽은 것이다. 감시 체계를 만들면 그것도 감시해야 한다.

정리


Share this post on:

Previous Post
폴더를 옮겼는데 옛 경로가 코드에 남아 있었다
Next Post
지우기 전에 대안이 있는지 봤다