この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の18日目です。
それでは18日目は mackerel-plugin-fluentd です。
mackerel-plugin-fluentdはデータの収集と送信、そしてバッファリングをいい感じにしてくれる Fluentd 専用プラグインです。
Fluentdって何？って人は 
id:tagomoris さんの記事がめちゃめちゃわかりやすいです。
読んだ多分使いたくなるので是非読みましょう。
Fluentd はデータのやりとりを管理するソフトウェアだ。デーモンとして動作する。今のところはLinux上での動作が主に想定されている*1
ちなみにこの記事のFluentdのバージョンは下記のとおりです。Fluentdはバージョンによって結構confなどは変わるので自分が使っているバージョンをしっかり確認して読み合わせください。
# td-agent --version td-agent 0.12.40
インストールと設定手順
FluentdのプラグインはFluentdがどのようにデータのやりとりをしているかを可視化してくれるプラグインです。
Fluentdの monitor_agent を利用しているので有効化が必要です。
まず td-agent.conf に下記のように追記してmonitor_agentを有効化します。
<source> type monitor_agent bind 0.0.0.0 port 24220 </source>
curl http://localhost:24220/api/plugins.json を実行してJSONデータが返ってくれば設定ができています。
その後、Fluentdを再起動しましょう
本プラグインはプラグイン集として提供しているパッケージの mackerel-agent-plugins に含まれています。
インストール先は /usr/bin/mackerel-plugin-fluentd です。
次にMackerelのプラグインはコマンドですので実行する事ができます。
-- /usr/bin はPATHが通っているので省略出来ます # mackerel-plugin-fluentd fluentd.retry_count.td 0.000000 1513548519 fluentd.retry_count.debug 0.000000 1513548519 fluentd.buffer_queue_length.td 0.000000 1513548519 fluentd.buffer_queue_length.debug 0.000000 1513548519 fluentd.buffer_total_queued_size.td 0.000000 1513548519 fluentd.buffer_total_queued_size.debug 0.000000 1513548519
設定ファイルであるmackerel-agent.confは標準では /etc/mackerel-agent/mackerel-agent.conf にインストールされます。
こちらに下記のとおり追記しましょう。
[plugin.metrics.fluentd] command = "mackerel-plugin-fluentd"
以上を行った上でmackerel-agentを再起動してください。
見れるメトリック
各グラフ定義ごとに説明します。
それでは各グラフ定義ごとに説明します。
また表に出てくるdiffとはプラグイン上で差分値計算をするかどうかです。
◯ となっている項目はプラグインで前回の実行時の値と差分値計算して出力しています。
Fluentd retry count
| メトリック名(ラベル) | プラグインの出力名 | diff | 説明 |
|---|---|---|---|
| {Object名} | fluentd.retry_count.{Object名} | ー | Fluentdの再試行回数 |
こちらはFluentdがデータを送信する際にどれだけリトライしているかです。
またmackerel-plugin-fluentd全体にいえますが、やり取りしているデータの種類毎に集計してくれます。
そのため Fluentd retry count でも複数データをやり取りしている場合は下記の通り、複数のメトリックになってくれます。
これにより、どのデータが負荷が高いなども一目瞭然です。 またFluentdの良いところにデータの送信に失敗するとFluentd側が調整してリトライしてくれるところにあります。 リトライの処理、ちゃんと書くの大変ですからこれはとてもうれしいですよね！ そうなるとFluentdがどれくらいリトライしているかを確認することはとても大切になってきます。 Fluentdのretry_limitで設定した回数を超えると溜まっているバッファがリセットされるので監視しましょう。
Fluentd queue length
| メトリック名(ラベル) | プラグインの出力名 | diff | 説明 |
|---|---|---|---|
| {Object名} | fluentd.buffer_queue_length.{Object名} | ー | Fluentdのバッファにあるキューの長さ |
こちらはFluentdがバッファリングしているキューの長さです。
Fluentdのbuffer_queue_limitで設定した値を超えるとデータがロストしますので監視が必要です。
バッファリングしているキューが貯まる=即問題ではありません。
ですのでリトライ数や下記のキューの合計サイズと比較しながら見ていきましょう。
しかしキューが右肩上がりに増えている場合は危険信号です。
その原因は受取側のシステムかもしれませんし、ネットワークかもしれません。
よくあるケースは 受け取り側のServerが不安定で、ログの転送に失敗してキューが溜まっている などがあります。
この場合はリトライも増えているはずなので見てみましょう。
また受け取り側のServerの状態を調べるために受け取り側でMackerelのシステムメトリックなどを活用しましょう。
Fluentd buffer total queued size
| メトリック名(ラベル) | プラグインの出力名 | diff | 説明 |
|---|---|---|---|
| {Object名} | fluentd.buffer_total_queued_size.{Object名} | ー | Fluentdのバッファにあるデータの合計サイズ |
こちらはFluentdがバッファリングしているデータの合計データサイズです。 Fluentdのbuffer_queue_limit×buffer_chunk_limitの値を超えるとログデータがロストするので監視が必要です。 サイズに収まっているうちは問題は無いのですがデータサイズが大きいと当然ネットワークやディスクに負担が掛かります。 キューが溜まっている理由が受け取り側のServerの問題だとしても根本的な原因は転送しているログデータが大きくてネットワークやDisk I/Oが追いついていないことも多くあります。 リトライ、キューの数、合計サイズと3つの軸でしっかり監視しましょう。
matchにidを指定しよう！
mackerel-plugin-fluentdはのObject名はデフォルトは object:3fedbb579cdc のようにRubyのobject_idです。
兎に角これがわかりづらい！メトリック名=自分が監視したいObject名にするためにはmatchにidを指定すると任意の名前を付けることができます。
<match debug.**> type stdout id debug </match>
これはmackerel-plugin-fluentdを使いこなすためにとても大切なノウハウなので是非使ってください。
Fluentdの死活監視にはcheck-tcpがオススメ
Fluentdの振る舞いだけでは無く、死活監視も大事です。 メトリック監視ではFluentdが死んでデータが送信されてない場合は0なので気づきにくいという問題があります。 そこでcheck-tcpを併せて使いましょう。 Socket監視の説明の際も例に出しています。
FluentdとMackerelの組み合わせは無限大の可能性
Fluentdはデータを受信して 任意のデータストア に転送することができます。
任意のデータストア には勿論Mackerelも含まれます！
fluent-plugin-mackerel を使えばFluentdでログを集計してMackerelのサービスメトリックに投稿することができます。
この応用は他にも課金ログやアプリケーションのエラーログなど応用がめちゃめちゃ効くので是非マスターして活用してください。
18日目はデータを便利に扱えるFluentdのプラグインについての説明でした。 明日は皆さんお待ちかね、いよいよWindows監視です！！ 引き続き、Mackerel プラグインアドベントカレンダーをお楽しみに！
