알림 — 유미위키

감시하는 값이 미리 정해둔 조건을 벗어났을 때 사람을 부르는 일입니다. 사람이 화면을 계속 들여다보고 있지 않아도 됩니다. 대신 조건을 어떻게 잡느냐에 따라 헛되이 불려 나오기도 하고, 불려 나와야 할 때 못 불려 나오기도 합니다.

상세

학교 보건실에서 아이 이마가 뜨거우면 선생님은 체온계를 댑니다. 눈금이 정해둔 선을 넘으면 복도에 대고 소리치지 않고, 명부를 펴서 오늘 연락이 닿는 보호자를 찾습니다. 전화는 그 한 사람에게 갑니다.

알림은 감시 대상에서 값을 재고, 그 값을 미리 정해둔 조건과 견주고, 조건을 벗어났을 때 사람 쪽으로 내보내는 일입니다. 세 마디가 전부입니다. 무엇을 재는지, 조건을 어떻게 적는지, 누구에게 어떤 경로로 보내는지는 자리마다 다릅니다.

flowchart TD
    A[감시 대상] -->|측정값| B[조건과 견줌]
    B -->|조건 안| A
    B -->|조건 밖| C[판정]
    C --> D[전달]
    D --> E[사람]

여기서 두 단계를 갈라야 합니다. 조건이 깨졌다는 판정과, 그 판정을 사람에게 전달하는 행위는 다른 일입니다. 판정은 값을 보는 쪽에서 내립니다. 전달은 그 판정을 받아 누구에게 언제 어떤 경로로 보낼지 정합니다. 경보와 갈리는 것이 이 전달입니다. 경보는 곁에 있는 아무나 들으라고 소리를 냅니다. 알림은 지금 대응할 사람을 정해서 그 사람에게 보냅니다. 판정을 영어로 alert, 전달을 notification 이라고 갈라 부릅니다. 한국어에서는 둘 다 알림으로 옮겨져서 자주 뭉개집니다.

한 번의 판정이 곧 한 번의 전달이 되지도 않습니다. 같은 판정이 이어지는 동안 전달을 한 번만 하거나, 여러 판정을 묶어 하나로 보내거나, 잠시 막아 둘 수 있습니다. 그 처리를 어느 쪽이 맡느냐가 감시 체계마다 갈리는 자리입니다.

배경

시스템은 사람이 보지 않는 동안에도 깨집니다. 그렇다고 화면을 계속 들여다보는 사람을 붙여 둘 수는 없습니다. 사람은 잠도 자야 하고 다른 일도 해야 합니다.

그래서 지켜보는 일을 기계에 맡깁니다. 구글 SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) 책은 시스템을 감시하는 이유로 장기 추세 분석, 기간이나 실험군 사이의 비교, 대시보드, 사후 분석과 함께 알림을 듭니다. 그러면서 감시와 알림이 있어야 시스템이 언제 깨졌는지, 또는 무엇이 곧 깨질지를 우리에게 말해 줄 수 있다고 적습니다. 시스템이 스스로 고치지 못할 때 사람이 알림을 조사하고, 진짜 문제가 있는지 판단하고, 문제를 완화하고, 근본 원인을 찾기를 바란다는 것입니다.

부르는 조건은 아무렇게나 잡을 수 없습니다. 같은 책은 아주 좁은 범위의 보안 감사를 하는 경우가 아니라면 뭔가 좀 이상해 보인다는 이유만으로 알림을 띄워서는 안 된다고 적습니다. 사람을 부르는 행위 자체가 값을 치르기 때문입니다. 그렇게 조건을 미리 적어 두고 그 조건이 깨졌을 때 사람을 부르는 일을 알림이라고 부릅니다.

예시

Prometheus 알림 규칙

Prometheus 는 알림 조건을 자기 질의 언어의 식으로 적게 합니다. 실제 규칙 파일 한 벌은 이렇게 생겼습니다.

YAML

groups:
- name: example
  labels:
    team: myteam
  rules:
  - alert: HighRequestLatency
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    keep_firing_for: 5m
    labels:
      severity: page
    annotations:
      summary: High request latency

alert: 가 알림의 이름이고 expr: 가 조건식입니다. 식의 결과로 벡터 원소가 하나 이상 나오는 순간부터 그 라벨 집합에 대해 알림이 활성으로 셉니다.

for: 는 선택 절입니다. 식의 결과가 처음 나온 뒤 정해진 기간 동안 평가마다 계속 활성인지 확인한 다음에야 firing 으로 셉니다. 위 예에서는 10분입니다. 활성이지만 아직 firing 이 아닌 원소는 pending 상태에 있습니다. for: 절이 없는 규칙은 첫 평가에서 바로 활성이 됩니다.

labels: 는 알림에 덧붙일 라벨을 적는 자리입니다. 이미 있는 라벨과 겹치면 덮어씁니다. annotations: 는 알림 설명이나 러너북 링크 같은 긴 정보를 담는 정보성 라벨입니다. 양쪽 값 모두 템플릿을 쓸 수 있습니다.

판정과 전달이 갈리는 자리도 여기서 보입니다. Prometheus 공식 문서는 알림 규칙이 지금 무엇이 깨졌는지 알아내는 데는 맞지만 그 자체로 완결된 통지 수단은 아니라고 적습니다. 요약, 통지 빈도 제한, 침묵, 알림 사이의 의존 관계를 얹을 층이 하나 더 필요하고, Prometheus 생태계에서는 Alertmanager 가 그 역할을 맡습니다. Prometheus 는 알림 상태를 주기적으로 Alertmanager 로 보내고, Alertmanager 가 침묵과 억제와 집계를 거쳐 이메일, 온콜 통지 시스템, 채팅 플랫폼 같은 경로로 통지를 내보냅니다.

Amazon CloudWatch 알람

관리형 클라우드 쪽은 같은 것을 알람이라는 이름으로 내놓습니다. CloudWatch 알람은 세 상태를 가집니다. 대시보드에 알람을 얹으면 INSUFFICIENT_DATA 상태일 때 회색, ALARM 상태일 때 빨간색으로 보입니다. OK 상태일 때는 색이 붙지 않습니다. 데이터가 모자란 것을 정상도 이상도 아닌 셋째 상태로 따로 둔 것이 눈에 띄는 자리입니다.

기다리는 기간은 평가 기간으로 적습니다. 평가 기간은 알람의 주기에 쓰인 평가 기간 수를 곱해서 나옵니다. 주기가 최소 한 시간, 그러니까 3600초 이상인 알람은 평가 기간이 최대 7일입니다. 주기가 그보다 짧은 알람은 최대 하루입니다.

대가

알림을 붙이는 것은 사람을 부를 권한을 기계에 넘기는 일입니다. 그 권한에는 값이 붙습니다.

구글 SRE 책은 사람을 페이지로 부르는 것이 직원의 시간을 상당히 비싸게 쓰는 일이라고 적습니다. 페이지는 사람을 즉시 불러내는 알림입니다. 근무 중이면 하던 일의 흐름이 끊기고, 집에 있으면 개인 시간이, 때로는 잠까지 끊깁니다. 페이지가 너무 자주 오면 사람은 들어오는 알림을 다시 의심하거나 대충 훑거나 아예 무시하게 됩니다. 잡음에 가려진 진짜 페이지까지 무시하는 일이 생깁니다. 그러면 다른 잡음이 신속한 진단과 수정을 방해해서 장애가 길어지기도 합니다.

조건을 어디에 두느냐는 한쪽으로만 움직이지 않습니다. 구글 SRE 워크북은 알림 전략을 잴 때 네 가지를 보라고 적습니다. 정밀도는 탐지한 사건 가운데 유의미했던 것의 비율입니다. 알림 하나하나가 모두 유의미한 사건에 대응하면 100퍼센트입니다. 재현율은 유의미한 사건 가운데 탐지된 것의 비율입니다. 유의미한 사건마다 알림이 나가면 100퍼센트입니다. 탐지 시간은 여러 조건에서 통지가 나가기까지 걸리는 시간이고, 이것이 길면 오류 예산에 부정적인 영향을 줄 수 있습니다. 리셋 시간은 문제가 해결된 뒤에도 알림이 계속 나가는 시간이고, 이것이 길면 혼란을 낳거나 문제가 무시되게 만들 수 있습니다.

조건을 조이는 쪽과 푸는 쪽이 이 네 잣대를 서로 반대로 움직입니다. 조건이 참이 된 뒤 얼마를 기다렸다가 부를지 정하는 값을 길게 잡으면 잠깐 튄 값에 덜 흔들리는 대신 탐지 시간이 늘어납니다. 짧게 잡으면 반대가 됩니다. Prometheus 공식 문서가 작은 요동을 견디도록 알림에 여유를 두라고 적는 것도 이 자리입니다.

그래서 알림 수 자체가 관리 대상이 됩니다. Prometheus 공식 문서는 알림을 되도록 적게 두라고 적습니다. 사용자가 겪는 아픔으로 이어지는 증상에 알림을 걸고, 그 아픔을 낳을 수 있는 모든 경로를 하나씩 잡으려 들지 말라는 것입니다. 원인이 아니라 증상에 알림을 걸 수 있으면 잡음을 줄이는 데 도움이 된다고 적습니다. 할 일이 없는 페이지를 두지 말라는 말도 같이 붙습니다. 구글 SRE 책은 감시 체계가 무엇이 깨졌는가와 왜 깨졌는가 두 질문에 답해야 한다고 적습니다. 앞이 증상이고 뒤가 원인입니다.

감시 체계 자신을 감시하는 부담도 따라옵니다. 감시가 죽으면 알림도 같이 죽습니다. Prometheus 공식 문서는 그래서 Prometheus 서버, Alertmanager, PushGateway 같은 감시 인프라가 살아서 제대로 도는지 확인하는 알림을 따로 두라고 적습니다. 알림이 PushGateway 에서 Prometheus 를 거쳐 Alertmanager 를 지나 메일까지 실제로 도착하는지 확인하는 블랙박스 시험 하나가, 각 구간마다 알림을 하나씩 두는 것보다 낫다고 적습니다.

알림

상세

배경

예시

Prometheus 알림 규칙

Amazon CloudWatch 알람

대가

관련 항목

알림이 속하는 상위 실천

알림이 값을 읽어오는 감시 데이터

감시가 알림과 나란히 맡는 다른 목적

알림 조건을 적는 요소

알림 전략을 정하는 기준

Prometheus 알림 규칙을 이루는 요소

알림을 실제로 구현·중계하는 도구

전달 전에 알림 잡음을 줄이는 처리

알림 뒤에 사람이 하는 대응과 겪는 부담