Prometheus 監視で 変わるもの qiita:sugitak

qiita:sugitak です ● 元・ネットワーク系 ○ Cisco ○ 無線構築 ● 自称デプロイ屋 ○ bundler, capistrano, … ● 監視も古典系出身 ○ Nagios + Cacti から開始 ○ munin, growthforecast, … ○ Zabbix ○ mackerel

No content

Prometheus とは？ ● 次世代監視ソフトウェア ● 自前で建てる監視サーバのOSS ● Google の Borgmon をベースにしている ● 現在も活発に実装中

Prometheus 監視は素晴らしい

Prometheus 監視は素晴らしい …本当に？

銀の弾丸などない

prometheus の発展途上なところ ● 若さ ○ コミュニティ資産足りない ○ ドキュメント足りない ● 作り込みのたいへんさ ○ グラフのためのクエリいじり。楽しいけど結構大変 ○ あんまりたくさんグラフ作ると苦労する ● 点の数に応じてクエリが遅くなる ○ 多ホスト・長期間のグラフをたくさん並べた状態で見るのは厳しい ○ 次元の呪い… ● コンポーネントが分かれているゆえの苦労も ○ コンポーネント間で設定がうまくいっているかの確認がが ● ダウンサンプリングしてくれない ○ これは将来マジで入れて欲しい

使っていくうちに、考えが変わった むしろ、 prometheus に合わせて 考え方を変えていく必要があった

変化ポイント1 どういう情報を収集するか

従来のデータの取り方 ● 見ないデータは取らない ○ 本当に必須のものは限られている ■ メモリ使用量 ■ CPU使用率 ■ ディスク容量 ■ ネットワークI/O ○ RRD けっこう容量食うし ○ snmp 経由だと無駄に CPU も食うし

https://www.datadoghq.com/blog/monitoring-101-collecting-data/

データは取れるだけ取っておく 可視化は必要になってから https://www.datadoghq.com/blog/monitoring-101-collecting-data/

prometheus の 情報収集 ● 初期状態で600メトリクス 以上取得してる ● sar, snmpwalk や dstat を 15 秒おきにとっている ようなもの ● 「次にエラーが起きたとき のために dstat 仕込んで おく」とかしなくてよくなっ た

変化ポイント2 監視ツールの利用方法

監視ツールの使い方は大きく分けて二つ ● いっつも見る (proactive) ○ 何か起きてないか確認するため ○ 全体的な傾向を確認するため ● ときどき見る (reactive) ○ アラートの原因調査のため ○ キャパシティプランニングのため

いつも見たいもの・そうでないもの ● 普段から見たいもの ○ 全体的な傾向 ■ 平均・最小メモリ使用量 ■ ディスク残量最小のホスト ■ CPU 使用状況 ■ 合計通信量 ■ アクセス増減傾向 ● 緊急時だけで十分なもの ○ 個別ホストごとの情報 ■ メモリ ■ CPU 使用率 ■ インターフェースごとの通信 ● pps, bps, エラーレート ○ 普段あまり問題にならない値 ■ I/O 命令数 ■ fork 数 ■ ソケットの使用状況 Prometheus で アドホックに クエリして確認 Grafana で 自サービス向けの ボードを作り込む 配布されてる 汎用テンプレートを使う

変化ポイント3 グラフの描き方

グラフでは、必ずインサイト（知見）が得られるようにする ● 知りたい目的があって、それが一目でわかるのがいいグラフ ○ 「見たいもの」が不鮮明なグラフはいらない ● 把握できる範囲のものだけ描く ○ グラフ数が多いことは、それだけで割れ窓 ○ たくさん線があっても何がなんだかわからない。線は 5本以内に減らす

例(1) 細かいデータいろいろ 他の人はこの値を 見ているらしい とりあえず監視して みよ

例(1) 細かいデータいろいろ 何のインサイトも 得られませんでしたァ 他の人はこの値を 見ているらしい とりあえず監視して みよ

例(2) メモリ使用量 メモリ使用量を全部出してみたよ メモリ使用量の最高と最低ホストだけ描い てみたよ マウスカーソルをかざすとどのホストかわ かるよ

例(2) メモリ使用量 メモリ使用量を全部出してみたよ メモリ使用量の最高と最低ホストだけ描い てみたよ マウスカーソルをかざすとどのホストかわ かるよ どっちもわかりやすいとは言えないけど 知りたい情報は右に全部入っている

グラフでは、必ずインサイト（知見）が得られるようにする ● 知りたい目的があって、それが一目でわかるのがいいグラフ ○ 「見たいもの」が不鮮明なグラフはいらない ● 把握できる範囲のものだけ描く ○ グラフ数が多いことは、それだけで割れ窓 ○ たくさん線があっても何がなんだかわからない。線は 5本以内に減らす

まとめ ● データはひたすら全部とる ● 普段使いのスクリーンだけ愛情込めてメンテする ○ 何の情報かわからないグラフは割れ窓。消す ○ 95% のデータは見られることもない。必要になってからアドホック確認で十分 ● グラフはインサイト（知見）を得られるものだけ作る ○ 「どういう状態を目で確認するためか」を考えてグラフを作る ○ 破天荒なグラフでも、わかればオッケー => Prometheus に限らず、監視で大事にしていきたい