ALBのアクセスログからAPIのレスポンスタイムを監視する

サービスのAPIのレスポンスタイムを監視することは運用において大事なことである。APIのレスポンスタイムを計測してモニタリングする方法は多様に考えられるが、このエントリでは次の図のようにALBのアクセスログをfluentdが収集してモニタリングツールと連携させることでAPIのレスポンスタイムを監視を実現していく。

f:id:n_soushi:20170629104620p:plain

  • ALBのアクセスログを有効にすると指定したS3のバケットにログファイルが貯まる
  • FluentdはS3へアクセスしログを収集する
  • 収集したログをElasticSearchへ転送しKibanaでモニタリング
  • 収集したログを解析し収集インターバル中のアクセスのうち最大レスポンスタイムや平均レスポンスタイムを統計しMackerelへメトリックを投稿
  • Mackerelでレスポンスタイムが閾値を超えた場合のアラート体制を整える

上記の構成はログのモニタリングと合わせてレスポンスタイムが閾値を超えた場合の通知を実現している。
また、ALBのアクセスログにはリクエストURLやUserAgentなどLBを通っているため監視に適した情報が揃っている。
モニタリングはkibanaで行うのでデータの集計やグラフを組み合わせてログ監視のダッシュボードを作れる。

そして、fluentdのプラグインを組み合わせれば、簡単にこの構成を実現できる。
利用したプラグインを一覧する。

どれも提示されている標準の使い方で実現できる。
詳細なfluentdの設定はgithubに置いているので参照いただきたい。

GitHub - nsoushi/alb-latency-collector: This repository contains fluentd setting for monitoring ALB latency.

1点、ログ監視の注意点として挙げておきたいことがある。
Fluentdで転送したログをLogstash形式でElasticsearchへインデキシングをしているときにALBのログタイムスタンプ(timeフィールド)を @timestampに置き換える必要がある。障害でログが転送されない状況から再開したときにログ転送の時刻を計測してしまうと実際のALBのログタイムスタンプと差異が生まれてしまう。これを予防するのが次の設定になる。

<match api.access_log>
  type copy

  <store>
    type record_reformer
    enable_ruby true
    tag api.access_log.es
    <record>
    @timestamp ${record['time']}
    </record>
  </store>

record_reformerでALBの timeフィールドをLogstashの @timestampへ置き換えている。

まとめ

  • Fluentdのプラグインを集めてALBのアクセスログを監視することができた。
  • その他のALBがあれば同様にFluentdの設定を追加することで柔軟にAPIのレスポンスタイム監視を増やすことができる。

コード

設定値を変更すればdocker-composeで動作確認を行えるコードを用意したので試したい方はgithubを参照してください。

github.com