ブログトップ 記事一覧 ログイン 無料ブログ開設

wyukawa’s blog

2016-06-15

Prometheus Casual Talks #1を開催しました

Prometheus Casual Talks #1 - connpass

発表者、参加者の皆様おつかれさまでした。ありがとうございました。

Prometheusは日本ではあんまり使われていないと思うのでそんなに人集まらないと思ってたんですが、connpassに公開したその日にすぐ定員はうまるぐらい人気でした。

ただ97人の申し込みに対して実際に来たのは66人で、入退室の面倒くささを考えると今後はdotsを使うのが正しい気がしてきました。

参加者がどういうモニタリング、監視ソフトを使っているのか興味があったので、

事前に任意で「現在業務で使っているモニタリング、監視ソフトは何ですか?」という複数回答可のアンケートを実施したのですがその結果が下記です。

Zabbix66
Nagios48
Cloudwatch34
Kibana33
Elasticsearch28
Cacti26
NewRelic26
Mackerel22
Munin18
Grafana17
Ganglia14
Pagerduty14
Sensu14
その他14
Growthforecast13
内製のなにか13
Datadog10
InfluxDB10
Cloudforecast7
Prometehus5
Graphite4
Kurado2

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に関する情報がもっと出てくると嬉しいので何かありましたら是非シェアお願いします。

2016-06-12

南魚沼グルメマラソン

一昨年、去年に引き続いて3年連続で行ってきました。

南魚沼グルメマラソンで走ってきた - wyukawa’s blog

南魚沼グルメマラソンにいってきた - wyukawa’s blog

結果はネットタイムが2時間1分6秒でした。去年に比べるとだいぶ遅い。。。練習不足だな。

3年連続でとても天気が良くて暑かったのでビールがうまかったです。ていうかここで飲んだビールが人生で一番うまかったです。3年連続でそう思ってます。

f:id:wyukawa:20160612171028j:image

2016-06-05

OSSプロダクトにissue登録する

僕は今見ている社内のログ分析基盤に数多くのOSSプロダクトを使っています。

具体的に言うと、Fluentdでログ収集してHadoopに書き込んでAzkaban経由でHiveバッチを動かしてデータを加工してPresto, Prestogres経由でみたりしています。

また最近はKafkaやElasticsearch, Kibanaといったものも使っていますし、Prometheus, Grafanaを使ってモニタリングするようになっています。

このように数多くのOSSプロダクトを使っている理由は、部品一つ一つを自前実装していたら時間がいくらあっても足りないからです。OSSプロダクトを活用することにより、レバレッジを効かせることができます。

そしてまたOSS界隈の進化のスピードが速いので、仮に自前実装したとしてもすぐに陳腐化してしまう危険性がある。であれば最初からOSSプロダクトを使って巨人の肩に乗るのが望ましいです。

しかしどのOSSプロダクトを選ぶかは重要です。将来を予測するのは困難ですが、開発が活発なものを選ぶべきです。そしてそのOSSプロダクトがどういうユースケースを第一に考えているのかを感じ取るのも重要です。なぜならそのOSSプロダクトが想定していないユースケースで使うと、バグに遭遇しても対応してくれない危険性があるからです。

例えばPrestoがJDBCにイマイチ乗り気でなかったのはおそらくFacebookがHiveを前提にしていたからだと思います。ただこれも改善されそうで何よりです。

このように数多くのOSSプロダクトを使っていると、バグに遭遇することもあります。

その場合、Twitterにつぶやいただけだとすぐ流れてしまって良くないので最近はissue登録するようにしています。すでに登録されていたら俺も遭遇したよってコメントしてます。

簡単に直せそうだったらPull Requestしてもいいんですが、そういうのはそんなに多くないですし、まずはissue登録するのが良いと思います。

僕の場合の具体例はこの辺

https://issues.apache.org/jira/browse/AMBARI-15418

https://issues.apache.org/jira/browse/HIVE-13374

https://github.com/prestodb/presto/issues/5353

https://github.com/grafana/grafana/issues/5165

自分と同じ問題に遭遇して俺も遭遇したよって言った例は下記

https://github.com/kazegusuri/fluent-plugin-prometheus/issues/2

https://github.com/elastic/elasticsearch/issues/18635


もちろんissue報告したからといってすぐ対応されるわけじゃないですが、何もしないよりは作者に伝わって良いと思います。それに自分と同じ問題に遭遇している人がもしいたら参考になると思いますし。

それに勢いのあるOSSプロダクトだとすぐ直ってリリースされるので効率がいいです。以前は諦めてその後何もしなかったけど、なんかしら報告しといたほうが残るので良いと思います。

とはいえ雑なissue登録しても迷惑なだけなので、もしissue templateがあればそれに従いましょう。無くても環境だったり設定だったりログだったりをちゃんと書きましょう。ただしパスワードなどの機密情報をうっかり書かないようにちゃんとマスクしましょう。

僕の考え方としてforkして独自パッチというのは原則として考えてないです。そういうケースもありますけど、なるべく避ける。理由はバージョンアップについていくのが辛いから。ただ開発が止まっているプロダクトならありかも。

それに使っているOSSプロダクトのパッチを書くのは本来の仕事じゃないよなとちょっと思っているし、微妙なパッチを送るよりかは専門家に任せたいなあと。もちろん放置されてたら別ですけど。

まあ、そんな感じです。以前も似たようなこと書いてた。

OSSプロダクトとのつきあい方 - wyukawa’s blog

2016-06-03

fluentdのCPU使用率をPrometheus, Grafanaでモニタリングしたい

fluentdはRubyで実装されていることもあり複数CPUを使えないので、トラフィックが増えてきた場合などはポートを分けて複数プロセスで起動することが一般的です。

なのでマシンごとのCPU使用率を見てもfluentdの状況がどうなのか判断することは難しいです。

ちなみにJavaだとそういうことをする必要がないしJMXもあるのでfluentdが特殊なミドルウェアなのかなという気がします。

fluentd以外でユースケースを思いつかない。

そこでfluentdのプロセスごとのCPU使用率をモニタリングしたいわけですが、どうやるかというのが今回のテーマです。

やっかいなことにfluentdはsupervisorとworkerの2プロセスあってモニタリングしたいのはworkerです。まずはworkerのpidを求めないといけないわけですが、その辺の話は省略します。

process_nameがあるなんて知らなかったぜ。。。

http://www.fluentd.org/blog/fluentd-v0.12.18-has-been-released

以前、僕はworkerのpidに対してpsコマンドを実行して%cpuをモニタリングしてました。

が、しかしpsの%cpuは起動時からの平均CPU使用率なのでtopと比べると低くなりがちで、モニタリングするべきメトリクスではないです。

pidstatを使う手もありますが、こちらもインターバル指定しないとその瞬間の値を取れないです。

なので以下のようにして実行した値をモニタリングするのが正しいわけですが、これをそのままprometheusのexporterで実装するとポーリングのたびに5秒ブロックすることになるのでイマイチ

pidstat -h -u -r -p <PID> 5 1

というかprometheusはクエリが書けるので変に端末側で計算するのではなくCPU時間をそのままメトリクスとして取得してクエリを書いてGrafanaでグラフ化すればいい。

そんなノリで書いたfluentd_exporterがこちら

https://github.com/wyukawa/fluentd_exporter

最初のほうはworkerのpidを求めるためのアヤシイ処理が入っていますが、そこは置いといて最終的には/proc/(worker pid)/stat内のutime+stimeをメトリクスfluentd_cpu_timeとして取得しています。

このメトリクスに対して下記のようにクエリを書けば1sあたりどれだけCPUを使っているかがわかるので結果的にfluentdのCPU使用率になるはず。他の手法で取った値と比べて合ってる感じなので多分大丈夫

rate(fluentd_cpu_time[1m])

グラフ化するとこんなかんじ

f:id:wyukawa:20160603150712p:image

2016-05-16

洞爺湖マラソンいってきた

去年は3時間48分のベストを出した相性の良い大会で、今回のタイムはぎりぎりサブ4でした。

天気も良く、しそジュースうまかったです。給食はゆで卵食いました。味は普通でした。

去年と比べると受付がなくなったのと、宿はスタート地点から近かったので荷物をホテルに預けられて楽でした。

レース後にホテルの風呂にも入れてすっきりしました。

この大会は風景もいいし5000人規模の大会なのでそこまで混雑しないので良い大会だと思います。

ただ千歳空港からバスで2時間なのと、市街地じゃないので応援が少ない、最後の3kmぐらいが歩道でちょっと走りづらい、などがありますが、この時期のフルマラソンとしては数が少ないので来年も検討します。今年は黒部名水マラソンと悩んだんですけど、気温と去年の良いイメージがあったので今年も洞爺湖マラソンにしました