fluent-plugin-mackerel の使い方

Mackerel に fluentd からメトリクスを送信するためのプラグイン fluent-plugin-mackerel の使い方の例を紹介します。

機能

機能としては大きくわけて以下の二つがあります。

• mackerel にメトリクスを送信する (out_mackerel)
• タグやレコードに mackerel の hostid を追加する (out_mackerel_hostid_tag )

前者はホスト毎及びサービスのメトリクスの送信の双方に対応しています。ホスト毎のメトリクスを送信する場合には hostid もしくは hostid_path にて、どのホストのメトリクスかを指定する必要があります。hostid には直接 hostid もしくは ${tag_parts[n]} の形式 (nは任意の整数)が指定でき、hostid_path は hostid が格納されているファイルのパスを指定します。( yum でインストールした場合は /var/lib/mackerel-agent/id に格納されます)

後者は複数ホストのメトリクスをどこか特定の fluentd から集約して送信したい場合に、mackerel の hostid をタグやレコードに追加するために利用します。受け取り側は hostid の指定に ${tag_parts[n]} を指定するとよいでしょう。

デフォルトでは1分間に1回メトリクスを送信します。flush_interval で送信頻度は制御出来ますが、1分以下に設定する事は出来ません。

設定例

ウェブサーバのステータスコード毎の集計を送信

nginx や apache のログを datacounter プラグイン を経由して送信すると以下のようなグラフが生成されます。

設定は以下のようになります。

<source>
  type tail
  format ltsv
  time_format %d/%b/%Y:%H:%M:%S %z
  path /var/log/nginx/access.log
  pos_file /var/log/td-agent/nginx.log.pos
  tag raw.nginx
</source>

<match raw.nginx>
  type datacounter
  count_interval 1m
  count_key status
  input_tag_remove_prefix access
  tag nginx.status
  outcast_unmatched yes
  # patternX: X(1-20)
  pattern1 2xx ^2\d\d$
  pattern2 3xx ^3\d\d$
  pattern3 4xx ^4\d\d$
  pattern4 5xx ^5\d\d$
</match>

<match nginx.status>
  type mackerel
  api_key <あなたの API キー>
  hostid_path /var/lib/mackerel-agent/id
  metrics_name http_status.${out_key}
  out_keys nginx_2xx_count,nginx_3xx_count,nginx_4xx_count,nginx_5xx_count
</match>

Cloudwatch の RDS のメトリクスを登録

cloudwatch プラグイン で取得した RDS の CPUUtilization のメトリクスをサービスメトリクスとして登録している例です。

設定は以下のようになります。

<source>
  type cloudwatch
  tag  raw.cloudwatch.rds_cpu
  cw_endpoint <あなたの RDS のリージョンの Cloudwatch のエンドポイント>
  period 60
  interval 60

  namespace AWS/RDS
  metric_name CPUUtilization
  dimensions_name DBInstanceIdentifier
  dimensions_value <あなたの RDS インスタンスの ID>
</source>

<match raw.cloudwatch.rds_cpu>
  type mackerel
  api_key <あなたの API キー>
  service <あなたのサービス>
  metrics_name ${[1]}.${out_key}
  out_keys CPUUtilization
</match>

まとめ

fluentd のログをそのまま流すというよりは、上述の datacounter プラグイン や numericcounter プラグイン、grepcounter プラグイン を利用して、監視したい項目を数値化してポストするといった使い方が考えられます。上記ではウェブサーバのログでしたが、DB のスロークエリの件数や時間、アプリログの ERROR や WARN の数といった、ログの監視での使いどころは色々あると思います。

また、AWS のサービスは特定ホストには結びつけられませんが、サービスメトリクスとして登録することで、個々のホストのメトリクスと同様に、Mackerel 上にプロットすることができます。Cloudwatch では保存出来ないような長期間の傾向を把握したい場合には有効な手段の一つだと思います。上記では先の nginx と対比するために RDS のメトリクスにしましたが、ELB などもサービスメトリクスとして登録してよいリソースの一つだと思います。

また、Mackerel はグラフの UI も使いやすく作り込まれているので、障害発生時にホストの状況と同様に AWS のリソースも同じ画面である程度追えるようにしておくことで状況把握がしやすくなるかもしれませんです。