41
47

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

prometheusAdvent Calendar 2017

Day 5

prometheusとgrafanaを入れたみたが、どうグラフとか出すといいのか?

Last updated at Posted at 2017-12-04

はじめに

prometheusでこんなmetricsとって、grafanaでこんなquery指定すると、こう見えるよの紹介。
始めたばかりで環境準備できたはいいが、ぱぱっとそれっぽいグラフとか出したい人向け。
とりまサーバの状態がいろいろ見えるダッシュボードができるまでの説明を詳しめにします。

notes

サーバの状態いろいろ見えるの

「notes」の準備ができてれば、以下はポチポチすればすぐできます。

96529008-7966-4427-a322-348079d2eaea.png

なおダッシュボードの実例として、Grafana LabでprometheusのDashboardを探すのがよいと思います。 スクショもあってイメージしやすく、監視対象のがあるとだいたいそのまま使えます。

またGrafana Pluginsでdata sourceやpanelなども増やせます。

ここではprometheusが動いてるサーバ上で同じくnode_exporterを動かしているので、

  1. LabsのPrometheus systemCopy ID to Clipboard
  2. 自分のgrafanaをブラウザで開く
  3. adminログイン
  4. 左上メニュー-> Dashboards -> Import
  5. Grafana.com DashboardにIDをペースト -> Load
  6. OptionsのData sourceを自分で足したprometheus選択
  7. Importで↑のができます

参考:Importing a dashboard

どう動いているか?

中身の理解のため、Memory Distributionのグラフに注目してみます。
ダッシュボード上グラフタイトルをクリック->Viewでそのグラフだけ拡大でき、さらにEditで以下prometheusのqueryが表示されます。

afabbe6c-f8c6-4e59-8aca-be6e85ec6f41.png

このグラフは4つのqueryで1つのグラフを生成しています。
ここでB行node_memory_MemFree metricに注目すると、prometheus上では、

37d0cdd6-f4c9-447e-b241-d892ca675fd5.png

1つのElement(metric name +label) vs. Value情報が保管されています。
prometheus上の画面ではhostnamejobだとlabelが付与されていますが、これはexporter側でなく、prometheus側で付与されたものとなります。

今回は監視しているnode_exporterが1つですが、もし複数のEC2などを監視する場合、同一metric nameでhostnameなど別labelのmetricが複数できます。
するとGrafana上node_memory_MemFree{$tag="$host"}というqueryになっていることに意味がでてきます。$tag="$host"はGrafana側のtemplatingという機能でサーバが増えてもその分のqueryを自動生成してくれるので、監視対象が増えてもダッシュボードそのものは編集不要となります。

また実際にはnode_exporter側の生のレスポンスはcurlで確認できるので、

$ curl localhost:9100/metrics
...
# HELP node_memory_MemFree Memory information field MemFree. (← metrics説明分)
# TYPE node_memory_MemFree gauge (← metrics type)
node_memory_MemFree 5.35724032e+08 (← metrics名と現在値) 
...

とnode_exporterにrequestされた瞬間のmem freeの値を返してるだけです。

metrics typeとはCounterやGaugeのことで公式解説を読むとわかりやすいです。
要はmem free値など現在の値をそのまま代入されるのがGaugeでhttp requestなど単位時間あたりを取得して先の値に加算して欲しい場合などはCounterを使ったり、とmetricsのとり方による違いがあります。

なお、metricsに複数labelがある場合について、先のcurlの結果のfilesystem freeに注目すると、


# HELP node_filesystem_files_free Filesystem total free file nodes.
# TYPE node_filesystem_files_free gauge
node_filesystem_files_free{device="/dev/xvda1",fstype="ext4",mountpoint="/"} 809613
node_filesystem_files_free{device="lxcfs",fstype="fuse.lxcfs",mountpoint="/var/lib/lxcfs"} 0
node_filesystem_files_free{device="tmpfs",fstype="tmpfs",mountpoint="/run"} 255383
node_filesystem_files_free{device="tmpfs",fstype="tmpfs",mountpoint="/run/lock"} 255852
node_filesystem_files_free{device="tmpfs",fstype="tmpfs",mountpoint="/run/user/1000"} 255851

のように{}で囲まれてdevicemountpointなどlabelが記載されます。
もしGrafana上でnode_filesystem_files_freeというqueryだけ指定した場合は5つのmetricsがhitするので、それらは展開されて5つ線が表示されたグラフが生成されます。

file system freeのグラフを追加してみる

空いているダッシュボード末尾右下にFilesystem Freeパネルを足してみる。

b1f7a4fe-a20a-4923-a6f0-ff386e71f6b7.png

  1. graphパネルを追加
    1. grafana画面で、左側面にマウスを持っていく
    2. add panel
    3. graph
  2. パネル設定
    1. パネルのeditで編集画面へ
    2. Generalタブ 25a607da-d3ec-4213-a06a-499ce9ccd06c.png
    3. Metricsタブ 5a6f62d6-e13e-426e-aa3e-22ae24639844.png
    4. Axesタブ 6b728013-4beb-4d48-9399-3443091b8471.png
    5. Legendタブ 0ee8a2fc-e597-4ca7-a80e-47ec3ef56c44.png
    6. 終わったら右上のBack to dashboard
    7. で最後にCtrl-sでダッシュボードの保存を忘れずに

サーバが増えたら自動でダッシュボードも増やすには?

前述の通りダッシュボード側はtemplating機能ですでに準備できているため、

  1. 増えたサーバにnode_exporterが導入済み
  2. 増えたサーバのIP:portをprometheusがtargetとして取得

という工程がさらに必要です。

1つ目はchefなりprovisioning段階でいい感じに自動で入れてもらうとして、2つ目はPrometheusのec2 service discoveryを試す - 技術的なメモというか、忘却録+特定のtagをaws上でつけておくと、サーバができれば自動でこの監視ダッシュボードができるようになります(左上のHostで選択)。(prometheus.ymlのtargesにIP:port listを手書きでも増えはする)

おわりに

prometheusは割りと「で、どう使うといいの?」な資料がまだまだないと周りからよく聞くのでとりま紹介系記事を書いてみました。というか本記事はgrafanaでどうグラフを作るかにだいぶ寄ってはいますね...

後述の自作exporterの話もありますが、どういうqueryをgrafanaから叩けばいいか?は慣れるまで結構難しいです。それには実例をあれこれ眺めてquery functionの使い方など理解を進めると良いので、前述のGrafana Labsのダッシュボードサンプル入れてみてその中身を確認していくのがオススメです。

おまけポエム : prometheusでの監視設計

筆がのったのでついでに書きますが、流れとして、

  1. どう通知が欲しいか? or ダッシュボードで状況確認したいか?
  2. prometheus上どういうmetricsが保管されてるべきか?
  3. どう対象をexporterから監視できるか?
  4. 実装からprometheus alert rule or grafanaからのqueryをどうするか?

と組み立てていきますが、custom exporterを作る場合の制約としてよく気にするのは、

  • metrics設計
    • 時系列DBとして時間vs.数値に落とし込めるか?
    • 連続しているか?
    • 監視対象の可変箇所をlabelでうまく表現できるか?
    • (sd観点でアラート/グラフ設定を自動で対象増えたら増えるor簡単に変更できるか?)
  • 監視先の叩き方
    • exporterからアクセスする口はあるか?(NWやapi仕様など)
    • どのくらいこまめに監視先を叩いて大丈夫か?

あたりかと思います。
まずは公式writing exportersを読めという話もあります。

prometheusは特にquery functionが豊富なのでmetricsで取るべき値は可能な限り素朴なものにしておき、あとで加工するようにした方がよいかと思います。

また、ミドルウェア監視用途では既存のexporterをいかに使うか?(自分でexporter作らない)という文脈が強く、あまりcustom exporterを作ろうとはならないと思います。

ただ、exporterを自作することに熟れてくると、あるあるシステム構成だけでなく、自社なり独自サービスの監視まで幅を広げられます。
実際ちょっとしたスクレイピングをするbatchを書く程度の手間で作れるので一度作れば結構使いまわしができます。
例えばpythonならclient_pythonのようにある程度の言語でlibraryは準備されてるので。

もっともサービスの謎管理画面など作る際に監視からも叩けるapiなど準備する必要がありますが。そこはサービスとしてマイクロサービス的な組み方であれば、prometheus/alertmaanger/各exporter/grafanaそれぞれと組み合わせるのに相性がよいと思います。

ま、なにはともあれ「おわりに」でも言及した「grafana labでdashbordのサンプルからqueryどうするといいかを漁るとよい」という話と同様、既存exporterコードを写経したりするのが理解を深めるには良さそうです。

以上。

41
47
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
41
47

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?