自社のフリートを監視するスタック

これで作られるもの

プライベートトンネルを経由して、あなたが所有する他のすべてのマシンをスクレイピングし、何かが壊れそうなときにメールを送る小さなインスタンスが1つ。ノードメトリクス、サイト間のblackboxプローブ、適切なしきい値を持つアラートルール、そして通知をグループ化して午前3時に400通も送らないようにするAlertmanager構成。

この構成にはダッシュボードはありません。ダッシュボードは快適ですが、監視ではありません。誰も見ていないグラフが誰かを起こしたことはありません。後で必要になれば、同じデータの上に追加してください。

始める前に

モニター用のR-4。15秒間隔で100ノードあれば、1分間に数十万サンプルになりますが、これは問題なく処理できます。
フリートと同じ場所に置かないでください。監視対象をすべて同じ建物に置くと、正確に叫んでほしい日に見事に静かにしてしまいます。あなたの環境がヨーロッパなら、トロントまたはシンガポールが適切な場所です。
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

静的リストではなくファイルベースのディスカバリにする価値は、追加のディレクトリにあります。ノードの追加はファイル1つで済み、ファイルはマシンをプロビジョニングするものによって書くことができます。/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>"

抑制ルールは、1通のメッセージと40通の違いです。ノードがダウンすると、そのノードに関するすべての警告が抑制されます。ノードがダウンしていることはすでにわかっているからです。

alertnameとsiteでグループ化すると、サイト全体の停電で1通のメールに全マシンがリストされ、マシンごとに1通ではなくなります。そのメールサーバーはメールガイドのもので、アラートパスを自分も監視しているインフラに依存させるのは既知のトレードオフです。別の場所のwebhookを指すセカンドレシーバーは安価な保険です。

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

その後

サイト間のblackboxプローブを各サイトから他のサイトへ追加すると、自分の環境の遅延マトリックスが得られ、インシデント中にステータスページよりもはるかに役立ちます。私たちのものはstatusにあります。また、looking glassは、ルートがおかしいように見えるときの質問の残り半分に答えます。

続きを読む

すべて表示

インフラストラクチャ

都市を選べ。サイズを選べ。コインで支払え。

あなたが誰かに関するフォームも、承認する人間を待つ必要も、確認のための電話もありません。請求が完了すれば、認証情報があなたの受信トレイに届きます。

サーバーを構成エンジニアに相談する