こんにちは、Site Reliability Engineerの @r_takaishi です。Reproではログの管理や検索に Papertrail を使っています。今回、Papertrailに送られるログの流量をDatadogで監視し、流量の増加に気づくための仕組みを整えたので紹介します。
課題
Reproでは様々なログをPapertrailに送り、エラー検知や検索などに活用しています。Papertrailの料金プランは例えば1GB/月で7ドルのようなログのデータ量で契約します。これを越えた場合は従量課金となります( https://www.papertrail.com/plans/ )。そのため、筆者が所属しているシステム基盤チームが週に一度利用状況やログの流量が増えていないかチェックしています（ Account Usage を見ています ）。しかし、チェックとチェックの間にログ流量が増えていた場合気づくのが後れたり、流量は増えているけど何が原因なのかわかりにくいという課題がありました。
PapertrailのLog flood detection機能
まず、Papertrail自身がログ流量増加を検知・通知するための仕組みを持っているためこれを使ってみました。
Log flood detection - Papertrail
PapertrailのSettings画面に Log Flood Detection という項目があるので、そこで閾値（秒間のメッセージ数）を設定するだけです。とても簡単。
Log Flood Detectionの通知を受け取るには、Settings>Profileにある Emails で Usage にチェックを入れます。
これでログ流量が閾値を越えた際、メール経由で知ることができるようになりました。しかし、普段よく見るSlackにも通知がほしい。DatadogやPagerDutyのアラートもSlackに通知しているので、揃えたいものです。
そこでSlackのEmail Integrationを使い、PapertrailからのメールをSlackチャンネルに転送するようにしました。
これによりログ流量増加時にはSlackに通知が届き、すぐに気づけるようになりました。
Datadogと連携したログ流量の監視
PapertrailのLog Flood Detection機能とSlackのEmail Integrationを使うことでログ流量の増加に即座に気づけるようになったのですが、いくつか課題がありました。
まず、この方法だとログ流量が増えた時には通知が届きますが、閾値以下に戻った時には届きません。リクエストのスパイクによってログの量が増えることがあるのですが、スパイク終了後にログ流量が戻ったのかどうかはわかりません。次に、Reproではstagingやproductionなど環境毎にログをわけて管理しているのですが、どの環境で流量が増えたのかまではわかりませんでした。
これらの課題を解決するため、PapertrailとDatadogを連携し、Datadogのモニターを使ってログ流量を監視するように変更しました。
やり方は PaperTrail Integration を見ていただくとして、Reproでは以下のように環境毎(Group)に検索条件を作成、Datadogに1分毎にログの数を送っています。 .* のように全てのログを対象としたいのですがそれはできないようだったので、その環境のログであれば必ず含まれるであろう環境名を検索条件としています。メトリクス名は papertrail.${environment_name} としました。
これにより、環境毎にメトリクスが作られ、個別に監視することが可能になりました。後はモニターやダッシュボードを作成すればDatadogでPapertrailのログ流量を監視できます。アラートする条件ですが、例えば以下のように10分間のログ数/分が100をこえていた場合という風にしています。これは、スパイクによって数分間増えた場合は通知されず、リリースなどでログ流量が意図せず増えた場合に気づけるであろう条件となっています。条件については今後も微調整する予定です。
min(last_10m):avg:papertrail.staging{*} > 100
ダッシュボードは以下のウィジェットを用意しています。Log Floodのアラートが通知された際に、このダッシュボードを見るとどのホストでログが増えているのかがすぐわかるというわけです。
まとめ
PapertrailとDatadogを連携して、Papertrailのログ流量をDatadogで監視するようにしました。これによりPapertrailのLog Flood Detectionを使うよりも詳細にアラートでき、アラート時の調査も行いやすくなりました。また、閾値以下に戻った際は自動的にアラートが解除されるようになったため、対処完了かどうかの判断も行いやすくなりました。今のところ環境単位の監視で十分そうですが、今後必要であればサービス単位でメトリクスを取得・監視することで どのサービスでログ流量が増えているか ということもすぐにわかるようにできそうです。
ReproではSite Reliability Engineerを現在募集しています。1日数億セッションのアクセスに耐えられるサービスの信頼性向上に興味がある方は以下のページを参照ください。
