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.

１点、ログ監視の注意点として挙げておきたいことがある。
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へ置き換えている。