はじめに
Grafanaダッシュボードを今まで作ってきて気を付けていることをまとめます。
外部ダッシュボードをインポートしてまねる
初めてGrafanaを触った際は、グラフの種類の多さに面くらいましたし、PromQLの書き方も理解できていませんでした。
そのため、使っている公式Grafanaなど公開されているダッシュボードをインポートして書き方をまねていました。
見栄えの良さだけでなく、知らなかったクエリの書き方も知れて勉強になりました。
有名なミドルウェアは検索してみると、出てくる場合も多いのでかなり参考になりました。
ただ、エクスポーターの設定などでそのまま使えない場合も多いのであくまで参考程度の気持ちでした。
- Elasticsearchの場合
- PostgreSQLの場合
目的別にダッシュボードを作る
Grafanaでの監視をするうえで、１次対応のためなのか詳細な状況を知りたいのかで作るグラフが変わります。
異常が起きているか知りたいだけであれば、詳細なグラフは不要です。グラフが多すぎると見る人に困惑させてしまいます。
また、必要な情報が網羅されていることは必要です。ダッシュボードを分けるとすべて見るために余計な手間が発生します。
ダッシュボードを作り終えたら、関係者に見方を説明する必要もあると思います。グラフの意味や見てほしいポイントを伝える必要があります。
Prometheus、システムへの負荷を考える
GrafanaはPrometheus、エクスポーターを通してメトリクスを収集しています。
収集間隔が短すぎたり一度に実行するクエリが多いと、Prometheusがダウンする可能性があります。
また、エクスポーターは監視対象にアクセスしてメトリクスを収集します。そのため監視対象であるシステム本体の負荷が上がりすぎないように気を付ける必要があります。
クエリの意味を理解する
Grafanaで使用しているクエリが何を意味しているか理解する必要があります。
gaugeなのかcounterなのか、平均値なのか、平均値であれば間隔はどの程度かなどです。
Prometheusはエクスポーターが定義したメトリクスを集めているだけなので、エクスポーターの開発ページなどを見てどういった意味なのか理解しておく必要があります。
アラートを挙げる閾値を明確にする
グラフがどういった状態であれば異常なのか明確にしておく必要があります。
GrafanaにメールやSlackに通知する機能もあるので併せて利用するとよいと思います。
定期的にメンテナンスする
システムの変更によりグラフがうまく表示されないことがあります。
定期的に見直して、必要なメトリクスが網羅されているか、不要なメトリクスがないか見る必要があると思います。
変数はわかりづらいのでなるべく使わない
Grafanaにはダッシュボードごとに変数を設定できるようになっています。例えば、変数を使うことで、複数のノードで動いているミドルウェアで表示するノードを切り替えることなどができます。
しかし、いざ使ってみると変数が今どの値なのか誤解し間違った理解をしてしまうことがありました。複数人で使っているとなおさら気づきづらいです。
ただ、変数を使うことで複数のグラフで共有できるというメリットもあります。そのため、変数を使うにしても初期値を固定し変えないなど使い方を決めるとよいと思います。
その他
Grafanaの公式ページにもベストプラクティスが載っています。