コンソールとダッシュボードのベストプラクティス - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

CONSOLES AND DASHBOARDS

あるシステムがPrometheusのように豊富なメトリクスを持つことができる場合、出来るだけ多くのデータを表示したくなってしまうかもしれない。 こうしたことから、そのシステムの専門家でさえも意味を理解するのが難しいような、情報を多く盛り込み過ぎて見通しの悪いコンソールに至ってしまうかもしれない。

自分の持っているデータを全てを表示しようとするのではなく、一番よくありそうなエラーの状態は何か、そのような状態を区別するためにどのようにコンソールを使うであろうかについて考えること。 サービスの構造を活かすこと。 例えば、もし、オンラインサービスが大きな木構造になっているなら、下位レイヤーのサービスのレイテンシーが典型的な問題となる。 全てのサービスの情報を単一の大きなダッシュボードに表示するのではなく、サービスごとにそれぞれが通信するサービスのレイテンシーとエラーを含むようなダッシュボードを作ること。 そうすることで、上位レイヤーから始めて、問題のサービスにたどり着けるようになる。

以下のガイドラインが非常に有効であることが分かっている。

  • 1個のコンソールにはグラフは5個までにする
  • 各グラフにはプロットは5個まで。stacked/areaグラフであれば、これより多くても許される
  • When using the provided console template examples, avoid more than 20-30 entries in the right-hand-side table.

もし、これらのガイドラインを超えているなら、(おそらくはサブシステムを新しいコンソールに分割するなどして)重要性の低い情報を見えなくするのが合理的である。 例えば、個別のデータではなく、集約されたデータをグラフ化したり、右側の表に写したり、もし稀にしか使わないデータであれば取り除いてしまう。 それは、いつだってexpression browserで見ることができる。

最後に、ある1つのコンソールの集合で複数のユーザーを満足させるのは、難しい。 oncallのときに必要な情報(何が壊れているか)は、機能を開発しているときに必要な情報(あるコーナーケースに遭遇する人は何人か)は、全然違う傾向にある。 そういう場合には、二つの別々のコンソールにすると便利である。

参考リンク

おすすめ書籍

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援