Prometheusデータベースの欠落データをトラブルシューティングするにはどうすればよいですか？

実行中のインフラストラクチャに関する詳細なメトリックを収集するために、Prometheusを監視ワークフローに徐々に統合しています。

この間、プロメテウスがデータをプルするはずのエクスポーターが応答しなくなるという奇妙な問題に遭遇することがよくあります。ネットワークの設定ミスが原因である可能性があります-アクセスできなくなっているか、エクスポーターがクラッシュしたためです。

理由が何であれ、Prometheusに表示されると予想されるデータの一部が欠落しており、特定の期間にわたってシリーズに何もないことがわかりました。1つのエクスポーターが失敗（タイミングアウト？）すると、他のエクスポーターが失敗することもあります（最初のタイムアウトがジョブ全体をトップレベルタイムアウトより上に押し上げましたか？ただ推測しています）。

上記の視覚化で示されているように、私が見るのはシリーズのギャップです。これが発生した場合、ログには何もありません。プロメテウスの自己計量もかなり不毛のようです。プロメテウスがやっていることを手作業で再現し、どこで壊れているのかを手作業で再現しようとする必要がありました。これは面倒です。もっと良い方法があるはずです！リアルタイムアラートは必要ありませんが、少なくとも、エクスポーターがデータを配信できなかったことを確認できるようにしたいと考えています。ブール値の「データを確認してください」というフラグでさえも始まりです。

輸出業者からデータを取得できなかったプロメテウスに関する意味のある情報を取得するにはどうすればよいですか？Prometheusデータ収集の手動シミュレーションを実行せずにギャップが存在する理由を理解するにはどうすればよいですか？この点に関して、おそらくプロメテウスを超えてデータ収集全般の監視に拡張された場合でも、賢明な慣行は何ですか？

私はあなたがrate次のようなものでメトリックに関する何らかのアラートを行うことができると思います：

ALERT DropInMetricsFromExporter
  IF rate(<metric_name>[1m]) == 0
  FOR 3m
  ANNOTATIONS {
    summary = "Rate of metrics is 0 {{ $labels.<your_label> }}",
    description = "Rate of metric dropped, actually: {{ $value }}%",
}

主な考え方は、メトリックレートが0の場合は常に3分間警告することです。適切なメトリック名と、エクスポート元から正しい情報を提供する必要があることを示すラベルを付けます。

エクスポーターが監視する適切なメトリックを選択することは複雑である可能性があり、詳細な洞察が得られない場合、真空状態からより良いアドバイスを提供することは困難です。
このブログ投稿は、より一般的な検出のインスピレーションにもなります。

ギャップを引き起こした可能性があるいくつかの理由があります。ほとんどの場合、エクスポーターは到達可能ではありません。その場合、時up系列は0になります。これについては、次のように警告できます（https://prometheus.io/docs/alerting/rules/#templatingから取得）。

# Alert for any instance that is unreachable for >5 minutes.
ALERT InstanceDown
  IF up == 0
  FOR 5m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
  }

ステータスページで、エラーメッセージを含めてダウンしていることも確認できます。残念ながら、過去のエラーを確認する方法はありませんが、これを追跡する問題があります：https : //github.com/prometheus/prometheus/issues/2820

また、Prometheusサーバーが過負荷になり、スクレイピングが停止する可能性があり、これもギャップを説明します。その場合Storage needs throttling. Scrapes and rule evaluations will be skipped.、ログにエラーが表示され、prometheus_target_skipped_scrapes_totalメトリックが増加するはずです。これについても警告する必要があります。例：

ALERT PrometheusSkipsScrapes
  IF rate(prometheus_target_skipped_scrapes_total[2m]) > 0
  FOR 5m

これがあなたが見ているのと同じ問題かどうかはわかりません。しかし、GC設定を特に設定しなかったJavaアプリケーションのこれらのランダムなギャップを見ました。つまり、JVMがFull GCを実行している間にインスタンスのアクティビティが停止したため、データ収集が停止したときにギャップが発生していました。Javaを使用している場合、これが発生する可能性があります。私たちの修正は、GCアクティビティの長さの指定された制限でG1ガベージコレクター（Java 8+）を明示的に使用して、データ収集のこれらの時間ギャップを防ぐことでした。