Prometheus Casual Talks #1を開催しました
Prometheus Casual Talks #1 - connpass
発表者、参加者の皆様おつかれさまでした。ありがとうございました。
Prometheusは日本ではあんまり使われていないと思うのでそんなに人集まらないと思ってたんですが、connpassに公開したその日にすぐ定員はうまるぐらい人気でした。
ただ97人の申し込みに対して実際に来たのは66人で、入退室の面倒くささを考えると今後はdotsを使うのが正しい気がしてきました。
参加者がどういうモニタリング、監視ソフトを使っているのか興味があったので、
事前に任意で「現在業務で使っているモニタリング、監視ソフトは何ですか?」という複数回答可のアンケートを実施したのですがその結果が下記です。
Zabbix | 66 |
Nagios | 48 |
Cloudwatch | 34 |
Kibana | 33 |
Elasticsearch | 28 |
Cacti | 26 |
NewRelic | 26 |
Mackerel | 22 |
Munin | 18 |
Grafana | 17 |
Ganglia | 14 |
Pagerduty | 14 |
Sensu | 14 |
その他 | 14 |
Growthforecast | 13 |
内製のなにか | 13 |
Datadog | 10 |
InfluxDB | 10 |
Cloudforecast | 7 |
Prometehus | 5 |
Graphite | 4 |
Kurado | 2 |
ZabbixとNagiosという昔ながらのものがワンツーフィニッシュでした。
MackerelやDatadogといった新興のクラウドモニタリングサービスがもっと浸透しているかと思いきや意外とそうでも無かったです。
そしてPrometehusは5人でした。まあそんなもんだよね。
僕の発表資料はこちら
サンプリングしたアクセスログデータに対してHTTPステータスごとに集計する場合4xx, 5xxのエラーが実際はあるのにサンプリングの結果0になる可能性があるのでfluentdやnorikraを使うよりもFlinkやStormのような分散システム前提のものを使う必要があるのではという僕の主張に対していくつかツッコミがありました。
や、ありがたいことです。だいたい以下のようなコメントだったと思います。
- 200を除けばいいのでは
- HTTPサーバー側にagent的なものを置いてそこで集計すればいいのでは
- statsdを使えば良いのでは
1番目は言われてみればそうかもだけど、そうすると割合が求めらるのが難しくなるのとfluentdの設定を複雑にしたくないという思いがあります。
2番目は例えばGitHub - knyar/nginx-lua-prometheus: Prometheus metric library for Nginx written in Luaを使うことなのかなと理解しました。それはアリだと思いますが、現状のアクセスログをtailして集計するやり方に比べるとHTTPサーバー側に仕込みが必要なので若干独立性が落ちるのかなと思いました。
で、statsdはよく知らないんですがこれもHTTPサーバー側のマシンにagent仕込む必要があるかなと。
今のところうちにはHadoopクラスタがあるのでそこをうまく活用できないかなと思ってます。そうすれば既存のモニタリング対象サーバー側の仕組みを変えずに済むので。
他の発表者の資料はこちらです。
https://gist.github.com/moznion/20ad8797af22df6b1365c2fd6f5a8a74
togetterはこちら
Prometheus Casual Talks #1 まとめ - Togetter
他の方のブログレポートはこちら
#PrometheusCasual #1 に行ってきた - weblog of key_amb
各プレゼンそれぞれ多様性があってなかなか面白かったです。
簡単にまとめてしまうとPrometheusのクエリは強力で、exporterは簡単に書けるし、exporter側で無理に頑張らなくてrawに近いデータを渡せばあとでクエリで好きなようにできるというのは大きな強みかなと。
たとえばなんか障害があってTIME_WAITとかSlabとかそういうちょっとニッチなメトリクスをモニタリングする必要ができた場合普通はその時点からモニタリングスクリプト作成するしかないけど、
Prometheusの場合はnode_exporterを最初にセットアップしておけば後で大抵のマシン固有のメトリクスは取れるのでなんとかなります。
弱みはあまり長期間メトリクスを保持するのは向いていないのではということ。RRDはその逆ですね。resolutionとretentionのトレードオフになると思います。
以上です。Prometheusに関する情報がもっと出てくると嬉しいので何かありましたら是非シェアお願いします。