변화의 부호를 봤다

장비 성능 지표에 알림을 걸었다. 값이 임계 아래로 떨어지면 알린다.

hashrate < 90% of nominal  →  알림

알림이 너무 많이 왔다. 정상인데도 오고 정작 이상할 때는 안 왔다.

Open Table of contents

절대 임계의 문제

장비마다 정격이 다르고 같은 모델이어도 개체 차가 있으며 온도에 따라서도 hashrate 가 달라진다.

그래서 90% 라는 선이 어떤 장비에는 너무 높고 어떤 장비에는 너무 낮았다. 하나의 기준으로 전부를 재니 늘 걸리는 장비와 문제가 나도 안 걸리는 장비로 갈렸다.

임계를 장비별로 조정하면 되지 않나 싶었는데 그러면 관리할 값이 device 수만큼 늘어난다.

새 장비를 넣을 때마다 그 값을 다시 잡아야 한다. 장비가 스무 대면 스무 개의 기준을 사람이 관리하게 된다.

관점을 바꿔서 절대값이 아니라 자기 자신 대비 변화를 보기로 했다.

`AVG(hashrate)` 직전 1시간 대비 현재 값의 비율

이러면 장비별 nominal 을 몰라도 된다. 어제의 자기 AVG() 보다 20% 떨어졌으면 이상이고 정격이 얼마인지는 상관이 없다.

개체 차이와 환경 차이가 기준에 자동으로 반영되는 셈인데 STDDEV() 가 큰 장비는 기준도 그만큼 넓어진다.

사람이 관리할 값이 device 수만큼이 아니라 하나로 줄었고 그 하나가 몇 퍼센트를 이상으로 볼 것인지다.

여기서 한 걸음 더 갔다. 지표마다 정상적으로 움직이는 방향이 다르다.

마지막이 특히 쓸모 있었는데 누적 처리량이 줄어들면 그것은 성능 문제가 아니다.

카운터가 초기화됐거나 집계가 틀린 것이라 재기동이나 자료 유실 신호로 읽어야 한다.

이것은 90% 같은 임계로는 못 잡는다. 값이 여전히 임계 위일 수 있고 부호를 봐야 잡힌다.

MySQL 에 지표를 추가할 때 세 가지를 함께 적기로 했다.

지표명:        device.hashrate
정상 방향:     완만한 등락, 온도와 역상관
이상 신호:     10분 내 20% 이상 급락 / 장시간 단조 하락
불가능:        음수

여기서 불가능 이라는 줄이 있는 것이 중요했는데 그 값이 나오면 지표 자체가 잘못된 것이다.

대상의 문제가 아니라 SNMP 수집이나 집계의 문제라는 뜻이라 그때는 수집 쪽 알림으로 보내게 했다.

실제로 누적 처리량이 감소한 적이 있었다. 원인은 수집 스크립트가 두 device 의 값을 섞어 쓴 것이었다.

또 하나 겪은 것이 있는데 GROUP BY 로 시간 단위 집계를 할 때 자료가 거의 없는 구간이 있었다.

새 장비를 넣은 첫 몇 시간과 점검으로 꺼 둔 시간대가 그런데 그 구간에서는 표본이 두세 개뿐이다.

여기에 표본이 일정 수 미만이면 이상이라는 검사를 걸었더니 정당하게 적은 구간이 전부 걸렸다. 그래서 AVG() 를 낼 때 그 구간을 빼고 정상 운영 구간에만 적용하게 했다.

모든 구간에 같은 검사를 거는 것이 항상 옳지는 않고 성격이 다른 구간은 다르게 본다.

바꾼 뒤 device.hashrate 알림이 크게 줄었다. 오는 것은 대체로 실제 이상이었다.

여기서 배운 것이 있다. 오탐이 반복되면 사람이 알림을 무시하게 된다.

그러면 MySQL 에 기록은 쌓이는데 감시는 있으나 마나가 된다. 울린 횟수가 아니라 울렸을 때 사람이 보느냐가 값을 정했다.

알림 하나를 추가할 때마다 셋을 물어봤다.

이게 울리면 무엇을 해야 하나 — 할 일이 없으면 알림이 아니라 지표다
정상인데 울릴 상황이 있나 — 있으면 그 조건을 빼거나 예외를 만든다
이상인데 안 울릴 상황이 있나 — 있으면 그게 더 큰 문제다

첫째가 알림과 지표를 가르는데 볼 사람이 아무 행동도 안 할 것이면 화면에만 두면 된다.

셋째가 가장 무겁다. 안 울리는 구멍은 오탐과 달리 아무도 모르는 채로 남는다.