diaryこの広告は、90日以上更新していないブログに表示しています。connpass発表者、参加者の皆様おつかれさまでした。ありがとうございました。Prometheusは日本ではあんまり使われていないと思うのでそんなに人集まらないと思ってたんですが、connpassに公開したその日にすぐ定員はうまるぐらい人気でした。97人の申し込みに対して実際に来たのは66人で、入退室の面倒くささを考えると今後はdotsを使うのが正しい気がしてきました。事前に任意で「現在業務で使っているモニタリング、監視ソフトは何ですか?」という複数回答可のアンケートを実施したのですがその結果が下記です。2ZabbixとNagiosという昔ながらのものがワンツーフィニッシュでした。MackerelやDatadogといった新興のクラウドモニタリングサービスがもっと浸透しているかと思いきや意外とそうでも無かったです。Prometehusは5人でした。5xxのエラーが実際はあるのにサンプリングの結果0になる可能性があるのでfluentdやnorikraを使うよりもFlinkやStormのような分散システム前提のものを使う必要があるのではという僕の主張に対していくつかツッコミがありました。だいたい以下のようなコメントだったと思います。200を除けばいいのではHTTPサーバー側にagent的なものを置いてそこで集計すればいいのではstatsdを使えば良いのでは1番目は言われてみればそうかもだけど、そうすると割合が求めらるのが難しくなるのとfluentdの設定を複雑にしたくないという思いがあります。Luaを使うことなのかなと理解しました。それはアリだと思いますが、現状のアクセスログをtailして集計するやり方に比べるとHTTPサーバー側に仕込みが必要なので若干独立性が落ちるのかなと思いました。statsdはよく知らないんですがこれもHTTPサーバー側のマシンにagent仕込む必要があるかなと。今のところうちにはHadoopクラスタがあるのでそこをうまく活用できないかなと思ってます。すれば既存のモニタリング対象サーバー側の仕組みを変えずに済むので。他の発表者の資料はこちらです。key_amb各プレゼンそれぞれ多様性があってなかなか面白かったです。簡単にまとめてしまうとPrometheusのクエリは強力で、exporterは簡単に書けるし、exporter側で無理に頑張らなくてrawに近いデータを渡せばあとでクエリで好きなようにできるというのは大きな強みかなと。障害があってTIME_WAITとかSlabとかそういうちょっとニッチなメトリクスをモニタリングする必要ができた場合普通はその時点からモニタリングスクリプト作成するしかないけど、Prometheusの場合はnode_exporterを最初にセットアップしておけば後で大抵のマシン固有のメトリクスは取れるのでなんとかなります。弱みはあまり長期間メトリクスを保持するのは向いていないのではということ。RRDはその逆ですね。resolutionとretentionのトレードオフになると思います。Prometheusに関する情報がもっと出てくると嬉しいので何かありましたら是非シェアお願いします。Grafanaでモニタリングできるのはもうわかったので...2016-05-06レポーティング、モニタリング、監視で使うストレージは何が良いんだろう題記のようなことを考えていて、レポーティング、モニタリング...2016-02-22hadoop用のexporterを作ってみた。Kibanaを6.7.1から7.1.1にupgradeした南魚沼グルメマラソン黒部名水マラソンで走ってきた掛川・新茶マラソンで走ってきた月別アーカイブはてなブログをはじめよう!wyukawaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。