Fluentdで始めるPrometheus / Prometheus Tokyo Meetup #1

Try Prometheus with Fluentd

Transcript

1. Fluentdで始めるPrometheus @kazegusuri /Masahiro Sano Prometheus Tokyo Meetup #1
2. 自己紹介  佐野 正浩(@kazegusuri)  Principal Engineer@Mercari, Inc.  Platform Team  Go と PHP で開発してます
3. さわってきたもの  Fluentd (2012~, v0.10)  Docker (2013~, v0.6)  Kubernetes (2015~, v0.10)  Prometheus (2015~, v0.13)  gRPC (2016~)
4. さわってきたもの  Fluentd (2012~, v0.10)  Docker (2013~, v0.6)  Kubernetes (2015~, v0.10)  Prometheus (2015~, v0.13)  gRPC (2016~)
6. fluent-plugin-prometheus  大きくわけて3つの機能  FluentdにPrometheus用のエンドポイント提供  prometheus Input Plugin  メッセージからメトリクスを取得  prometheus Output/Filter Plugin  Fluentd自体の内部メトリクス  prometheus_monitor Input Plugin https://github.com/kazegusuri/fluent-plugin-prometheus
7. prometheus Input Plugin  FluentdにPrometheus用のエンドポイント提供  PrometheusからのPull  他のプラグインで取得したメトリクスを返す <source> @type prometheus port 24231 </source> GET /metrics scrape_configs: - job_name: fluentd static_configs: - targets: - 'localhost:24231‘ metrics_path: /metrics
8. prometheus Output/Filter plugin  メトリクスをログから収集  Output/Filter pluginとして実装  メトリクスはInput Pluginで回収  アプリケーションの外でメトリクス収集  使えるメトリクスの種類  counter, gauge, summary, histogram  類似のツール  https://github.com/google/mtail
9. メトリクス収集の例 <filter nginx> @type prometheus <metric> name nginx_size_counter_bytes type counter desc nginx bytes sent key size <labels> host ${hostname} foo bar </labels> </metric> </filter> {"size": 200} {"size": 100} # TYPE nginx_size_counter_bytes counter # HELP nginx_size_counter_bytes nginx bytes sent nginx_size_counter_bytes{host=“hoge",foo="bar"} 100 # TYPE nginx_size_counter_bytes counter # HELP nginx_size_counter_bytes nginx bytes sent nginx_size_counter_bytes{host=“hoge",foo="bar"} 300
10. prometheus_monitor Input plugin  Fluentdの内部状態をメトリクスに  monitor_agent プラグイン相当の機能  取得可能なメトリクス  buffer_queue_length  buffer_total_queued_size  retry_count http://docs.fluentd.org/v0.12/articles/monitoring <match nginx> @type forward @id test_forward disable_retry_limit <server> host 127.0.0.1 </server> </match> fluentd_status_buffer_queue_length{ plugin_id="test_forward", plugin_category="output", type="forward“ } 17 fluentd_status_buffer_total_bytes{ plugin_id="test_forward", plugin_category="output", type="forward“ } 228 fluentd_status_retry_count{ plugin_id="test_forward", plugin_category="output", type="forward“ } 19
11.  prometheus_monitorを使えば監視できそうな気はする  だがFluentdで監視したいのはそれだけなのか…  retryに失敗しすぎてretry_waitが長過ぎ問題…  実は全部emitに失敗していた…  そもそもoutputに来てなかった…  tailしていたと思ったらパスが変わっていた…
12.  prometheus_monitorを使えば監視できそうな気はする  だがFluentdで監視したいのはそれだけなのか…  retryに失敗しすぎてretry_waitが長過ぎ問題…  実は全部emitに失敗していた…  そもそもoutputに来てなかった…  tailしていたと思ったらパスが変わっていた… ＿人人人人人人人＿ ＞ 作ってみた ＜ ￣Y^Y^Y^Y^Y^Y￣
13. prometheus_output_monitor  アウトプットプラグインの詳細なメトリクスを収集  収集可能なメトリクス  buffer_queue_length  buffer_total_bytes  retry_count  num_errors ★  emit_count  retry_wait ★ (現在のretry_wait (秒))  emit_records (v0.14 only)  write_count (v0.14 only)  rollback_count (v0.14 only)
14. prometheus_output_monitor  retry_wait で現在のretry_wait がわかる  max_retry_wait の設定漏れがわかる  num_errors の差を見ればエラー出過ぎがわかる  emit_count の差を見ればそもそも来てないのがわかる
15. prometheus_tail_monitor  in_tail プラグインのメトリクスを収集  pos_fileの情報  position (どこまで読んだか)  inode (読んでいるファイル)  pos_fileを指定してなくても動作  labelにファイルのpathが自動で付与
16. prometheus_tail_monitor  positionの差を見ることで  in_tail されてないことがわかるよ  position自体でログサイズもわかるよ  inodeでログローテートされてないことがわかるよ
17. max_retry_wait 指定無し
18. max_retry_wait指定有り
19. max_retry 指定 v0.12 v0.14
20. tailのposition
21. まとめ  fluent-plugin-prometheus  FluentdとPrometheusをつなぐプラグイン  Fluentdの監視に必要なメトリクスを収集  他にもネタ(メトリクス)があれば実装します！ おわり