Introduction
Wantedly Advent Calendar 2015 11日目です。
インフラチームの 坂部 @koudaiii です。
Wantedlyでは開発スピードが早く、また主力のサービスも日々拡大が進み、どんどんサービスの分割、新規サービスを出しています。
Wanteldyを支えるインフラ作りとして、Wantedlyが利用しているモニタリングを紹介したいと思います。
モニタリング
モニタリングは大きく監視と観察の2つの側面があります。
具体的には、
Application Metrics(Work Metrics)とSystem Metrics(Resource Metrics)とEventsとLog
の4つに大きく分類して、Metricsを取得し傾向を掴みます。
またAlertを設定することで監視としても利用されます。
Application Metrics(Work Metrics)
Application Metrics(Work Metrics): RailsのThroughput やNginx Requestなど、システムの状態をトップレベルであわらすMetrics
- Throughput
- Success
- Error
- Performance
System Metrics(Resource Metrics)
System Metrics(Resource Metrics): ServerのCPU使用率やContainerのMemory使用量などインフラレイヤーのMetrics
- Utilization
- Saturation
- Errors
- availability
Event
Event: コードチェンジ、AWS 側の障害、スケール、デプロイ、エラーシステムのEventを集約
- code release, build
- third-party notifications
- Adding or subtracting hosts
Log
Log: アプリケーション及びシステムのログを集約
- syslog
- Middleware log
- Applocation log
Metricsとは
Metricsはある特定の情報(Free Memory等)を継続的に保持することで、
時系列並べたり、他の情報を組み合わせることで意味を持たせるものになります。
またProductの傾向をつかむことができます。
このMetricsより、緊急度と重要度を把握することが出来ます。
- 死活監視の意味合いに近いもの(緊急度): ping, Memory 使用率 100% など
- 将来への予防線(重要度): ディスク使用量の減るペース、Nginxのrequest増加
どうやってモニタリングするか
- NewRelic Application(Work)のモニタリング
- Datadog System(Resouece), Eventのモニタリング
- Pagerduty Alert通知
- Logentries Log保管
- HoneyBadger ApplicationのError管理
NewRelic, Datadog, Pagerduty, Logentries, HoneyBadger の用途
NewRelic
Application(Work)を主に担当しています。
Responce, Throughput, Slow Query, Session Traceを取得しています。
エンジニアがパフォーマンス改善をする際にも利用されています。
著しくパフォーマンスが悪い場合にAlertとして通知しております。
- Browser(ネットワーク越しから見たモニタリング)
- Session Trace
- Slow Query
Datadog
Resourceを主に担当します。
Server, Container, Middleware, Third-party のStatus等を取得ています。
ここでは、いわゆるインフラの監視がメインとなります。(CPU Disk Memory)
ある程度傾向を観て閾値を設定し、
閾値を超えた際にAlertにしてPagerDutyに通知するようにしています。
- Metrics
下記記載しますが、NewRelic等やDatadogのAPIを用いてカスタマイズしたものをDashboardに乗せています :)
Pagerduty
各モニタリングやApplicationのErrorを通知する目的で利用しています。
- Slackに通知するアラート
- Pagerdutyによる電話アラート
Logentries
主に原因調査のために利用しています。
System log, Middleware log, Application log を集約
またサービス間を超えたlogの調査を目的としています。
- Service毎にまとめて一覧でLog集約
- Serviceを超えてLog表示
HoneyBadger
Application Errorを管理用に利用しています。
- Show Code
- Application Trace
- issue
- Assign
Wantedlyにおけるモニタリングの考え方
- モニタリングはインフラチームためだけじゃないです。すべてのエンジニアがいつ観ても分かるよう心がけています
- オオカミ少年状態を避けるためにデフォルトの設定は利用しません。
- 緊急度高いものはAlertの設定をします。
- 緊急度が高くなくても重要度が高いものについては、電話通知はせずSlack通知を利用し、状況を記録しています。
どう原因調査をするか
原因調査のフロー
- アプリケーションメトリクス（Workメトリクス）から見る
- 例] Rails のレスポンスタイム
- その Work メトリクスが依存するシステム(Resource)メトリクスを見る
- 例: DB のレスポンスタイム
- 例: Containerの CPU, Mem, Disk, Network
- Work メトリクスと相関していそうな Resource メトリクスを見つける
- Resource メトリクスに当たりをつけたら、障害が起きてる時間帯のイベントとログを見る
- 原因を突き止め、解決する
より具体的に、
- NewRelic の Overview から始める
- スループットやレスポンスタイム、エラーレートを見る
- External Services やコンテナの CPU、MEM を確認する
- 相関がありそうなグラフを見つける
- Slack, Datadog のタイムラインを見てその時間帯のイベントを調べる
- Logentries を見てその時間帯のログを調べる
- もしわからなければ、タイムレンジを伸ばしたり、前回似たようなことが起きたときいの時間帯で調べる
Dashboard
誰でもひと目でわかることが大事
Wantedlyでは 1箇所にデータを集めて見られるようにしています。
それはインフラチームだけではなく、すべてのエンジニア にも一発で状況を把握するために利用しています。
理由は、Wantedlyの変化のスピードからCodeの変更やBuildをエンジニアで行われるからです。
そのため、ざっくりDeploy後のシステム状況を確認する際に、 上から順番にApplication→Resource を確認できるようにしています。
またインフラチームも一次調査、一次報告、対応をどうするべきか決めるのに非常に有効的です。
まとめ
Wanteldyではこのようにして、ツールを組み合わせてモニタリングを行っております。
複数のツールを利用すると複雑な運用になりがちですが、Dashboardを作成し、誰もが最初に共通で見れるのを統一しております。
いわゆるTim Toady Bicarbonate*2な仕組みを意識してモニタリングを設計しています。 :)