ダッシュボードにできるだけ多くのデータを表示したくなるかもしれません。特に Prometheus のようなシステムでは、アプリケーションの豊富な計測が可能です。これは、情報が多すぎて、システムのエキスパートでさえ意味を理解するのが難しい、理解不能なコンソールにつながる可能性があります。
運用コンソールでは、持っているすべてのデータを表現しようとするのではなく、最も可能性の高い障害モードと、コンソールを使用してそれらを区別する方法を考えてください。サービスの構造を活用してください。たとえば、オンラインサービスシステムに大規模なサービスツリーがある場合、下位のサービスでのレイテンシーが一般的な問題です。1つの大きなダッシュボードにすべてのサービスの情報を示すのではなく、各サービスが通信する各サービスのレイテンシーとエラーを含む、各サービス用の個別のダッシュボードを構築します。その後、一番上から始めて、問題のあるサービスまで順番に調べていくことができます。
私たちは、次のガイドラインが非常に効果的であると発見しました。
これらを超えることに気付いた場合は、重要度の低い情報の可視性を下げたり、一部のサブシステムを新しいコンソールに分割したりすることが理にかなっている可能性があります。たとえば、分解されたデータではなく集計されたデータをグラフ化したり、右側の表に移動したり、めったに役に立たない場合は完全にデータを削除したりすることもできます。 式ブラウザでいつでも確認できます。
最後に、コンソールのセットが複数のマスターにサービスを提供することは困難です。オンコール時（何が壊れているか？）に知りたいことは、機能開発時（どのくらいの人がコーナーケース X に遭遇しているか？）に知りたいこととは大きく異なる傾向があります。このような場合は、2つの別個のコンソールセットが役立つ可能性があります。
このドキュメントはオープンソースです。問題の提起やプルリクエストを提出して、改善にご協力ください。