6/14 に開催された「Prometheus Casual Talks #1」に参加してきた．既に Prometheus を1年以上運用してる話などもあって，ハイレベルな話を聞くことができた．勉強会の後に実際に Prometheus を動かしてみたり，サンプルで Exporters を実装してみたりしてからブログを書こうと思っていたら，業務的にバタバタして，気付いたらブログも書かずに1週間たってた…！今さらだけど参加レポートは書いておこうと思う．
Hadoop, Fluentd cluster monitoring with Prometheus and Grafana / @wyukawa
- 元々 Google で SRE を担当してたエンジニアが SoundCloud 社に JOIN して実装している
- プル型
- Zabbix Agent や Mackerel Agent などのモニタリングサービスは基本プッシュ型
- モニタリングと監視がセットになっている
- Grafana - The open platform for analytics and monitoring
と合わせて使うのが一般的な構成
- クエリが強力で GroupBy なども書ける
- 線形回帰で数時間後の予測に基いて監視できる
- え！それは凄いなー！と思った
- 監視は Alertmanager で行う
- 数時間後まで再送しない設定や同じアラートをまとめる設定など気が利いている
- Alertmanager | Prometheus
- LINE レベルのトラフィックで既に運用できていることに驚いた
Prometheus on AWS / @mtanda
- AWS の AZ ごとにメトリクスを比較している
- Service Discovery 機能も入ってる
- プル型だからこそ Prometheus 側からノードを検知する必要がある
- Advanced Service Discovery in Prometheus 0.14.0 | Prometheus
- CloudWatch のメトリクスも Prometheus に取り込んでいる
- 長期保存用の Prometheus を立ててサマライズしたメトリクスを別途管理している
- デフォルトだと15日間で自動的に削除される
- 実際に運用してるからこその工夫で知見だなと感じた
t2.microやt2.midiumで十分動くっていうのは驚いた- t 系のインスタンスならバーストに頼れる
promgen - prometheus management tool / @tokuhirom
- ノードを管理する yaml を簡単に操作できる管理画面を作った
- jmx_exporter で JVM をモニタリングしている
- Log4j や Logback にポートできる
HBase, Kafka cluster monitoring with Prometheus and Grafana / kawamuray
- Pushgateway を使うとプッシュ型としても使える
- Prometheus 側が自由にクエリを書けるのは本当に強力
- Kafka や YARN をモニタリングしている
- チューニングオプションの話など実運用で使い倒してる事例だったから個人的には難しかった
5分で作るprometheus exporter / @moznion
- h2o 用の exporter をライブコーディングで実装する
- 普通に凄かった
- JSON から Golang の Struct を自動で変換してくれる JSON-to-Go は超便利なのでは？
- h2o_exporter.go · GitHub
合わせてチェックする
ChangeLog で Prometheus のコミッターが喋っているとのこと．聞こう！
SoundCloud 社のモニタリングシステムの歴史を紹介した資料．読もう！
まとめ
ドキュメントを読んでいたら “When does it not fit?” に特徴が書いてあった．絶対に取りこぼしなくメトリクスを収集するなら Prometheus は適さないかもとのこと．当然だけど pros/cons はあって，重要なのは pros/cons をちゃんと理解しておくことだと思う．
If you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice as the collected data will likely not be detailed and complete enough.
個人的に特徴的だなーと感じたのは，発表者が「インスタンスのライフサイクルは短いものである」や「サーバに名前を付けて個別で管理することは現実的ではない」と言っていたことだった．確かに Radar で既に Application Servers は HOLD 認定されてしまっているし，モダンなアーキテクチャだとそういうトレンドなんだと思う．それはわかる．
ただし，現状として僕が仕事で管理してるインフラは普通に数年動き続けることが前提のインスタンスだったりするから，Zabbix で半年前のメトリクスを見ることも頻繁にあるし，たった2週間でメトリクスが消えてしまうのでは困るなぁ…と感じた．だからこそ，アーキテクチャのライフスタイルに適したモニタリングシステムを選ぶことは重要だし，アーキテクチャを変えていくことも重要になる．勉強会に参加しながら，そんなようなことを漠然と考えていたりもした．
最高に刺激的な勉強会でした．ありがとうございました！