Stos monitorowania, który obserwuje Twoją własną flotę

Co to buduje

Jedna mała instancja, która skanuje każdą inną maszynę, którą posiadasz, przez prywatny tunel, i wysyła Ci maila, gdy coś ma się zepsuć. Metryki węzłów, sondy blackbox między lokalizacjami, reguły alertów z rozsądnymi progami oraz konfiguracja Alertmanagera, która grupuje powiadomienia zamiast wysyłać czterysta z nich o trzeciej nad ranem.

W tym buildzie nie ma dashboardu. Dashboardy są przyjemne i nie są monitoringiem; wykres, na który nikt nie patrzy, nigdy nikogo nie obudził. Dodaj go później, jeśli chcesz, na bazie tych samych danych.

Zanim zaczniesz

• R-4 jako monitor. Sto węzłów z interwałem piętnastosekundowym to kilkaset tysięcy próbek na minutę, z czym ten model radzi sobie bez wysiłku.
• Umieść go tam, gdzie nie ma Twojej floty. Każdy monitor, który dzieli budynek z tym, co obserwuje, pozostaje podziwu godny cichy dokładnie w dniu, w którym potrzebujesz, by krzyczał. Jeśli Twoje środowisko jest europejskie, Toronto lub Singapore to rozsądne miejsca.
• Tunel do każdego monitorowanego węzła, zgodnie z przewodnikiem WireGuard. Eksportery ujawniają wiele o maszynie i nie powinny być nigdzie w pobliżu publicznego interfejsu.

1. Na każdym monitorowanym węźle

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

Podstaw adres tunelu danego węzła. Wiązanie z tunelem zamiast ze wszystkim oznacza, że firewall jest drugą linią obrony, a nie jedyną.

2. Na monitorze

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

Zapisz /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

Odkrywanie na podstawie plików zamiast statycznej listy jest warte dodatkowego katalogu. Dodanie węzła staje się jednym plikiem, a plik może być zapisany przez to, co provisionuje Twoje maszyny. /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 }

Te etykiety sprawiają, że alerty są później czytelne. Alert mówiący db in AMS-01 jest akcjonowalny; alert mówiący 10.7.0.12 wysyła Cię do arkusza kalkulacyjnego.

3. Reguły, które warto mieć

/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 to reguła, która w tym buildzie zarabia na swoje utrzymanie. Próg wolnego miejsca mówi Ci, że dysk jest pełny; trend z sześciu godzin ekstrapolowany do przodu mówi Ci, że będzie pełny około czwartej po południu, co jest problemem, który możesz jeszcze rozwiązać spokojnie. Alerty dyskowe oparte na stałym procencie są albo zbyt hałaśliwe na małych wolumenach, albo bezużyteczne na dużych.

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>"

Reguła inhibit to różnica między jednym komunikatem a czterdziestoma. Gdy węzeł pada, wszystkie ostrzeżenia o tym węźle są tłumione, bo już wiesz: węzeł jest w dół.

Grupowanie według alertname i site oznacza, że cała lokacja tracąca zasilanie generuje jednego maila z listą wszystkich maszyn, zamiast jednego maila na maszynę. Ten serwer mailowy pochodzi z przewodnika mailowego, a poleganie ścieżki alertingu na infrastrukturze, którą też monitorujesz, to znany kompromis; drugi receiver wskazujący na webhook gdzie indziej to tanie ubezpieczenie.

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

Przechowywanie warto ustawić świadomie. Dziewięćdziesiąt dni dla stu węzłów to kilkadziesiąt gigabajtów:

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

Weryfikacja

Najpierw składnia, bo plik reguł z literówką cicho nie ładuje się i dowiadujesz się o tym podczas incydentu:

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

Potem potwierdź, że każdy cel jest skanowany:

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

Każdy cel powinien raportować up. Taki, który raportuje down, oznacza albo regułę firewalla, albo eksporter związany z niewłaściwym adresem.

Teraz jedyny test, który dowodzi, że cały łańcuch działa, czyli zepsuć coś celowo. Na dowolnym monitorowanym węźle:

systemctl stop prometheus-node-exporter

Trzy minuty później alert powinien być pending, a następnie firing. Obserwuj, jak przechodzi:

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

W ciągu około minuty od odpalenia przychodzi mail. Jeśli alert odpala, ale mail nie przychodzi, problem leży w poświadczeniach smarthost, a journalctl -u prometheus-alertmanager powie to wprost. Uruchom eksporter ponownie i potwierdź, że otrzymasz też powiadomienie o rozwiązaniu, bo system alertujący, który nigdy nie mówi, że jest lepiej, uczy Cię go ignorować.

systemctl start prometheus-node-exporter

Potem

Dodaj sondy blackbox między lokacjami, z każdej do każdej, a otrzymasz macierz opóźnień swojego środowiska, która jest znacznie bardziej przydatna podczas incydentu niż jakakolwiek strona statusowa. Nasza jest na status, a looking glass odpowiada na drugą połowę pytania, gdy trasa wygląda podejrzanie.