자체 플릿을 감시하는 모니터링 스택

구축되는 것

프라이빗 터널을 통해 여러분이 소유한 다른 모든 머신을 스크래핑하고, 문제가 발생하려 할 때 메일을 보내는 소형 인스턴스 하나입니다. 노드 메트릭, 사이트 간 블랙박스 프로브, 합리적인 임계값을 갖춘 알림 규칙, 그리고 세벽 3시에 알림 400개를 보내는 대신 그룹화하는 Alertmanager 구성입니다.

이 빌드에는 대시보드가 없습니다. 대시보드는 보기 좋고 모니터링이 아닙니다. 아무도 보지 않는 그래프는 아무도 깨우지 못했습니다. 원한다면 나중에 같은 데이터 위에 추가하세요.

시작하기 전에

• 모니터용 R-4. 15초 간격으로 100개 노드는 분당 수십만 개의 샘플이며, 이 인스턴스는 무리 없이 처리합니다.
• 플리트와 다른 위치에 두세요. 모든 것을 감시하는 건물을 공유하는 모니터는 정확히 도움이 필요할 때 조용히 있습니다. 유럽에 있다면 토론토나 싱가포르가 합리적입니다.
• 각 모니터링 노드에 대한 터널은 WireGuard 가이드에서 제공합니다. 익스포터는 머신에 대한 많은 정보를 노출하므로 공용 인터페이스에 두면 안 됩니다.

1. 모든 모니터링 노드에서

apt update && apt install -y prometheus-node-exporter
mkdir -p /etc/systemd/system/prometheus-node-exporter.service.d
cat > /etc/systemd/system/prometheus-node-exporter.service.d/bind.conf <<EOF
[Service]
Environment=ARGS=--web.listen-address=10.7.0.11:9100 --collector.systemd --collector.processes
EOF
systemctl daemon-reload && systemctl restart prometheus-node-exporter
ss -ltn | grep 9100

각 노드의 자체 터널 주소로 대체하세요. 터널에 바인딩하면 방화벽이 유일한 방어선이 아니라 두 번째 방어선이 됩니다.

2. 모니터에서

apt install -y prometheus prometheus-alertmanager prometheus-blackbox-exporter

/etc/prometheus/prometheus.yml을 작성하세요:

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    fleet: main

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['127.0.0.1:9093']

rule_files:
  - /etc/prometheus/rules/*.yml

scrape_configs:
  - job_name: nodes
    file_sd_configs:
      - files: ['/etc/prometheus/targets/*.yml']

  - job_name: probe_https
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://app.example.com/health
          - https://cloud.example.com/status.php
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

정적 목록보다 파일 기반 디스커버리가 가치가 있습니다. 노드 추가는 파일 하나가 되고, 파일은 머신을 프로비저닝하는 무엇이든 작성할 수 있습니다. /etc/prometheus/targets/ams.yml:

- targets: ['10.7.0.11:9100']
  labels: { site: AMS-01, role: web }
- targets: ['10.7.0.12:9100']
  labels: { site: AMS-01, role: db }

이 라벨들은 나중에 알림을 읽을 수 있게 만듭니다. db in AMS-01라는 알림은 조치 가능하지만 10.7.0.12는 스프레드시트를 보게 만듭니다.

3. 가치 있는 규칙

/etc/prometheus/rules/fleet.yml:

groups:
  - name: fleet
    rules:
      - alert: NodeDown
        expr: up{job="nodes"} == 0
        for: 3m
        labels: { severity: page }
        annotations:
          summary: "{{ $labels.instance }} in {{ $labels.site }} stopped answering"

      - alert: DiskFillingUp
        expr: predict_linear(node_filesystem_avail_bytes{fstype=~"ext4|xfs|zfs|btrfs"}[6h], 4*3600) < 0
        for: 30m
        labels: { severity: page }
        annotations:
          summary: "{{ $labels.instance }} fills {{ $labels.mountpoint }} within four hours"

      - alert: MemoryPressure
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.10
        for: 15m
        labels: { severity: warn }

      - alert: IOWaitHigh
        expr: avg by (instance) (rate(node_cpu_seconds_total{mode="iowait"}[5m])) > 0.25
        for: 20m
        labels: { severity: warn }

      - alert: CertificateExpiring
        expr: probe_ssl_earliest_cert_expiry - time() < 10*86400
        labels: { severity: warn }

      - alert: ProbeFailing
        expr: probe_success == 0
        for: 5m
        labels: { severity: page }

predict_linear은 이 빌드의 가치를 만드는 규칙입니다. 여유 공간에 대한 임계값은 디스크가 가득 찼음을 알려주지만, 6시간 추세를 외삽하면 오늘 오후 4시쯤 가득 찰 것이라고 알려주며, 침착하게 해결할 수 있는 문제입니다. 고정 비율 기반 디스크 알림은 작은 볼륨에서는 시끄럽거나 큰 볼륨에서는 쓸모없습니다.

4. Alertmanager

route:
  receiver: mail
  group_by: [alertname, site]
  group_wait: 45s
  group_interval: 5m
  repeat_interval: 12h
  routes:
    - matchers: [severity="warn"]
      repeat_interval: 72h

inhibit_rules:
  - source_matchers: [alertname="NodeDown"]
    target_matchers: [severity="warn"]
    equal: [instance]

receivers:
  - name: mail
    email_configs:
      - to: [email protected]
        from: [email protected]
        smarthost: mail.example.com:587
        auth_username: [email protected]
        auth_password: "<the mailbox password>"

억제 규칙은 메시지 하나와 40개의 차이입니다. 노드가 다운되면 해당 노드에 대한 모든 경고가 억제됩니다. 이미 알고 있기 때문입니다: 노드가 다운되었습니다.

alertname 및 site별 그룹화는 전체 사이트가 정전되면 머신당 메일 하나가 아닌 모든 머신을 나열하는 메일 하나가 생성됨을 의미합니다. 그 메일 서버는 메일 가이드의 서버이며, 알림 경로가 모니터링하는 인프라에 의존하는 것은 알려진 절충안이고, 다른 곳의 웹훅을 가리키는 두 번째 수신자는 저렴한 보험입니다.

systemctl enable --now prometheus prometheus-alertmanager prometheus-blackbox-exporter

보존 기간은 의도적으로 설정할 가치가 있습니다. 100개 노드의 90일은 수십 기가바이트입니다:

echo 'ARGS="--storage.tsdb.retention.time=90d --storage.tsdb.retention.size=40GB"' > /etc/default/prometheus
systemctl restart prometheus

검증

구문부터, 오타가 있는 규칙 파일은 로드 시 조용히 실패하고 인시던트 중에 알게 됩니다:

promtool check config /etc/prometheus/prometheus.yml
promtool check rules /etc/prometheus/rules/fleet.yml

그런 다음 모든 타겟이 스크래핑되는지 확인하세요:

curl -s http://127.0.0.1:9090/api/v1/targets | grep -o "\"health\":\"[a-z]*\"" | sort | uniq -c

모든 타겟은 up을 보고해야 합니다. down을 보고하면 방화벽 규칙이거나 잘못된 주소에 바인딩된 익스포터입니다.

이제 전체 체인이 작동함을 증명하는 유일한 테스트인, 의도적으로 무언가를 고장내는 것입니다. 모니터링되는 노드에서:

systemctl stop prometheus-node-exporter

3분 후 알림은 보류 상태가 되고, 그다음 발화 상태가 됩니다. 이동을 지켜보세요:

curl -s http://127.0.0.1:9090/api/v1/alerts | head -c 400
amtool --alertmanager.url=http://127.0.0.1:9093 alert query

발화 후 약 1분 내에 메일이 도착합니다. 알림이 발화하지만 메일이 오지 않으면 문제는 스마트호스트 자격 증명이며, journalctl -u prometheus-alertmanager이 분명히 말할 것입니다. 익스포터를 다시 시작하고 해결 알림도 받는지 확인하세요. 문제가 나아졌다는 것을 알려주지 않는 알림 시스템은 무시하도록 훈련시키기 때문입니다.

systemctl start prometheus-node-exporter

이후

사이트 간 블랙박스 프로브를 추가하면 각 사이트에서 다른 사이트로, 자체 에스테이트의 지연 매트릭스를 얻을 수 있으며 인시던트 중에 어떤 상태 페이지보다 훨씬 유용합니다. 우리 것은 status에 있으며, looking glass는 경로가 잘못 보일 때 질문의 나머지 절반에 답합니다.