Uma stack de monitoramento que observa sua própria frota

O que este guia constrói

Uma instância pequena que monitora todas as outras máquinas que você possui, através de um túnel privado, e envia e-mail quando algo está prestes a quebrar. Métricas de nós, sondas blackbox entre sites, regras de alerta com limites sensatos e uma configuração do Alertmanager que agrupa notificações em vez de enviar quatrocentas delas às três da manhã.

Não há dashboard nesta configuração. Dashboards são agradáveis, mas não são monitoramento; um gráfico que ninguém está olhando nunca acordou ninguém. Adicione um depois, se quiser, em cima dos mesmos dados.

Antes de começar

• Um R-4 para o monitor. Cem nós em intervalos de quinze segundos são algumas centenas de milhares de amostras por minuto, o que esta máquina lida sem perceber.
• Coloque-o em um local onde sua frota não está. Qualquer monitor que compartilha um prédio com tudo o que observa permanece admiravelmente quieto exatamente no dia em que você precisa que ele grite. Se sua operação for europeia, Toronto ou Cingapura são os lugares sensatos para ele.
• Um túnel para cada nó monitorado, a partir do guia WireGuard. Os exporters expõem muita coisa sobre uma máquina e não devem ficar perto de uma interface pública.

1. Em cada nó monitorado

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. No monitor

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

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

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

3. Regras que valem a pena ter

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

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

Agrupando por alertname e site significa que um site inteiro sem energia produz um único e-mail listando todas as máquinas, em vez de um e-mail por máquina. Esse servidor de e-mail é o do guia de e-mail, e depender de infraestrutura que você também monitora para seu caminho de alertas é uma troca conhecida; um segundo receptor apontando para um webhook em outro lugar é um seguro barato.

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

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

Verificação

Primeiro a sintaxe, porque um arquivo de regras com um erro de digitação falha silenciosamente na carga e você descobre durante o incidente:

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

Depois confirme que cada alvo está sendo coletado:

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

Cada alvo deve reportar up. Um reportando down é ou uma regra de firewall ou um exporter vinculado ao endereço errado.

Agora o único teste que prova que toda a cadeia funciona, que é quebrar algo de propósito. Em qualquer nó monitorado:

systemctl stop prometheus-node-exporter

Três minutos depois o alerta deve estar pendente e depois disparado. Observe-o mover:

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

Dentro de cerca de um minuto após disparar, o e-mail chega. Se o alerta disparar mas nenhum e-mail aparecer, o problema são as credenciais do smarthost, e journalctl -u prometheus-alertmanager dirá isso claramente. Inicie o exporter novamente e confirme que você também recebe a notificação de resolvido, pois um sistema de alerta que nunca informa que as coisas melhoraram treina você a ignorá-lo.

systemctl start prometheus-node-exporter

Depois

Adicione sondas blackbox entre sites, de cada site para cada outro site, e você terá uma matriz de latência da sua própria operação que é muito mais útil durante um incidente do que qualquer página de status. A nossa está em status, e o looking glass responde à outra metade da pergunta quando uma rota parece errada.