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

Transcript

1. 1.

   Fluentdで始めるPrometheus @kazegusuri /Masahiro Sano Prometheus Tokyo Meetup #1

2. 2.

   自己紹介  佐野 正浩(@kazegusuri)  Principal Engineer@Mercari, Inc.  Platform

   Team  Go と PHP で開発してます
3. 3.

   さわってきたもの  Fluentd (2012~, v0.10)  Docker (2013~, v0.6) 

   Kubernetes (2015~, v0.10)  Prometheus (2015~, v0.13)  gRPC (2016~)
4. 4.

   さわってきたもの  Fluentd (2012~, v0.10)  Docker (2013~, v0.6) 

   Kubernetes (2015~, v0.10)  Prometheus (2015~, v0.13)  gRPC (2016~)
5. 5.

   None
6. 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. 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. 8.

   prometheus Output/Filter plugin  メトリクスをログから収集  Output/Filter pluginとして実装  メトリクスはInput

   Pluginで回収  アプリケーションの外でメトリクス収集  使えるメトリクスの種類  counter, gauge, summary, histogram  類似のツール  https://github.com/google/mtail
9. 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. 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. 11.

     prometheus_monitorを使えば監視できそうな気はする  だがFluentdで監視したいのはそれだけなのか…  retryに失敗しすぎてretry_waitが長過ぎ問題…  実は全部emitに失敗していた…  そもそもoutputに来てなかった…

     tailしていたと思ったらパスが変わっていた…
12. 12.

     prometheus_monitorを使えば監視できそうな気はする  だがFluentdで監視したいのはそれだけなのか…  retryに失敗しすぎてretry_waitが長過ぎ問題…  実は全部emitに失敗していた…  そもそもoutputに来てなかった…

     tailしていたと思ったらパスが変わっていた… ＿人人人人人人人＿ ＞ 作ってみた ＜ ￣Y^Y^Y^Y^Y^Y￣
13. 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. 14.

    prometheus_output_monitor  retry_wait で現在のretry_wait がわかる  max_retry_wait の設定漏れがわかる  num_errors

    の差を見ればエラー出過ぎがわかる  emit_count の差を見ればそもそも来てないのがわかる
15. 15.

    prometheus_tail_monitor  in_tail プラグインのメトリクスを収集  pos_fileの情報  position (どこまで読んだか) 

    inode (読んでいるファイル)  pos_fileを指定してなくても動作  labelにファイルのpathが自動で付与
16. 16.

    prometheus_tail_monitor  positionの差を見ることで  in_tail されてないことがわかるよ  position自体でログサイズもわかるよ  inodeでログローテートされてないことがわかるよ

17. 17.

    max_retry_wait 指定無し

18. 18.

    max_retry_wait指定有り

19. 19.

    max_retry 指定 v0.12 v0.14

20. 20.

    tailのposition

21. 21.

    まとめ  fluent-plugin-prometheus  FluentdとPrometheusをつなぐプラグイン  Fluentdの監視に必要なメトリクスを収集  他にもネタ(メトリクス)があれば実装します！ おわり