コンソールとダッシュボード

ダッシュボードにできるだけ多くのデータを表示したくなるのは無理もありません。特にPrometheusのようなシステムでは、アプリケーションを豊富に計測できる機能が提供されているためです。しかし、情報が多すぎると、システムの専門家でさえ意味を読み取ることが難しい、理解不能なコンソールになってしまう可能性があります。

運用コンソールの場合、すべてのデータを表現しようとするのではなく、最も可能性の高い障害モードと、それらを区別するためにコンソールをどのように使用するかを考えてください。サービスの構造を活用しましょう。たとえば、オンラインサービスシステムでサービスの大きなツリーがある場合、下位サービスのレイテンシーは典型的な問題です。単一の大きなダッシュボードにすべてのサービス情報を表示するのではなく、各サービスが通信する各サービスのレイテンシーとエラーを含む個別のダッシュボードを作成します。そうすれば、上位から問題のあるサービスへと順に調べることができます。

以下のガイドラインは非常に効果的であることがわかっています。

• 1つのコンソールに表示するグラフは5つまで。
• 各グラフに表示するプロット（線）は5つまで。積み上げ/面グラフの場合はこれ以上でも問題ありません。
• 提供されているコンソールテンプレートの例を使用する場合、右側のテーブルのエントリは20～30件を超えないようにしてください。

これらの数を超える場合は、重要度の低い情報の可視性を下げたり、一部のサブシステムを新しいコンソールに分割したりすることを検討してください。たとえば、内訳データではなく集計データをグラフ化したり、右側のテーブルに移動したり、めったに役に立たない場合は完全にデータを削除したりすることもできます。いつでもエクスプレッションブラウザで確認できます。

最後に、複数のマスターにサービスを提供するコンソールのセットは困難です。オンコール時に知りたいこと（何が壊れているか？）は、機能開発時に知りたいこと（どれだけの人がXという特殊なケースに遭遇したか？）とは大きく異なります。このような場合、2つの個別のコンソールのセットが役立つことがあります。