Embed Size (px)
Citation preview
Prometheus 監視で変わるもの
qiita:sugitak
qiita:sugitak です
● 元・ネットワーク系○ Cisco○ 無線構築
● 自称デプロイ屋○ bundler, capistrano, …
● 監視も古典系出身○ Nagios + Cacti から開始
○ munin, growthforecast, …○ Zabbix○ mackerel
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 に限らず、監視で大事にしていきたい
