Wantedlyを支えるモニタリング


## Introduction

[Wantedly Advent Calendar 2015](http://qiita.com/advent-calendar/2015/wantedly) 11日目です。

インフラチームの 坂部 @koudaiii です。

Wantedlyでは開発スピードが早く、また主力のサービスも日々拡大が進み、どんどんサービスの分割、新規サービスを出しています。
Wanteldyを支えるインフラ作りとして、Wantedlyが利用しているモニタリングを紹介したいと思います。

## モニタリング

モニタリングは大きく監視と観察の2つの側面があります。

具体的には、
**Application Metrics(Work Metrics)とSystem Metrics(Resource Metrics)とEventsとLog**
の4つに大きく分類して、Metricsを取得し傾向を掴みます。
またAlertを設定することで監視としても利用されます。

![Kobito.JSJMDU.png](https://qiita-image-store.s3.amazonaws.com/0/20833/859d802e-9586-6fa5-e473-b766178d28cb.png "Kobito.JSJMDU.png")

### 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](http://newrelic.com/) Application(Work)のモニタリング
* [Datadog](https://www.datadoghq.com/) System(Resouece), Eventのモニタリング 
* [Pagerduty](https://www.pagerduty.com/) Alert通知 
* [Logentries](https://logentries.com/) Log保管
* [HoneyBadger](https://app.honeybadger.io/) ApplicationのError管理

![Kobito.WPDehc.png](https://qiita-image-store.s3.amazonaws.com/0/18843/5b9d7c5c-ce4f-39de-9c32-664a3ede7731.png "Kobito.WPDehc.png")

## NewRelic, Datadog, Pagerduty, Logentries, HoneyBadger の用途

### NewRelic

Application(Work)を主に担当しています。
Responce, Throughput, Slow Query, Session Traceを取得しています。
エンジニアがパフォーマンス改善をする際にも利用されています。

著しくパフォーマンスが悪い場合にAlertとして通知しております。

* Browser(ネットワーク越しから見たモニタリング)

![Kobito.fNV8kS.png](https://qiita-image-store.s3.amazonaws.com/0/18843/a3b117e8-7f6b-be5b-93be-d5d14918ca3c.png "Kobito.fNV8kS.png")

* Session Trace

![Kobito.GNCwXj.png](https://qiita-image-store.s3.amazonaws.com/0/18843/f86c5399-c061-d9a0-ef79-bf38a242a1f6.png "Kobito.GNCwXj.png")

* Slow Query

![Kobito.x98Iai.png](https://qiita-image-store.s3.amazonaws.com/0/18843/320cc846-51c3-632f-46c9-ba89a22ecb29.png "Kobito.x98Iai.png")

### Datadog

Resourceを主に担当します。
Server, Container, Middleware, Third-party のStatus等を取得ています。
ここでは、いわゆるインフラの監視がメインとなります。(CPU Disk Memory)

ある程度傾向を観て閾値を設定し、
閾値を超えた際にAlertにしてPagerDutyに通知するようにしています。

* Metrics

![Kobito.UXkThV.png](https://qiita-image-store.s3.amazonaws.com/0/18843/cc39b561-c6d5-1b30-5560-a56e3eb51868.png "Kobito.UXkThV.png")

下記記載しますが、NewRelic等やDatadogのAPIを用いてカスタマイズしたものをDashboardに乗せています :)

### Pagerduty

各モニタリングやApplicationのErrorを通知する目的で利用しています。

* Slackに通知するアラート
* Pagerdutyによる電話アラート

![Kobito.AZ5YZa.png](https://qiita-image-store.s3.amazonaws.com/0/18843/9567ec24-3713-4e9d-b5a1-3f9d9283316d.png "Kobito.AZ5YZa.png")

### Logentries

主に原因調査のために利用しています。
System log, Middleware log, Application log を集約
またサービス間を超えたlogの調査を目的としています。

* Service毎にまとめて一覧でLog集約

![Kobito.ElULz8.png](https://qiita-image-store.s3.amazonaws.com/0/18843/9f283bf6-95f2-01c6-2ed3-e3a5b7ccef15.png "Kobito.ElULz8.png")

* Serviceを超えてLog表示

![Kobito.40uWSH.png](https://qiita-image-store.s3.amazonaws.com/0/18843/b37d79c5-4a27-7f11-3466-11b6454931b3.png "Kobito.40uWSH.png")

### HoneyBadger

Application Errorを管理用に利用しています。

* Show Code
* Application Trace
* issue
* Assign

![Kobito.bij6qB.png](https://qiita-image-store.s3.amazonaws.com/0/18843/23e0d8b7-38a1-5387-78dd-1c833f8a4f91.png "Kobito.bij6qB.png")

## Wantedlyにおけるモニタリングの考え方

* モニタリングはインフラチームためだけじゃないです。すべてのエンジニアがいつ観ても分かるよう心がけています
* オオカミ少年状態を避けるためにデフォルトの設定は利用しません。
* 緊急度高いものはAlertの設定をします。
* 緊急度が高くなくても重要度が高いものについては、電話通知はせずSlack通知を利用し、状況を記録しています。

## どう原因調査をするか

### 原因調査のフロー

![Kobito.xKOitZ.png](https://qiita-image-store.s3.amazonaws.com/0/20833/1cbb1a1c-56f7-162d-7029-e0248d37cec8.png "Kobito.xKOitZ.png")

0. アプリケーションメトリクス（Workメトリクス）から見る
 * 例] Rails のレスポンスタイム
0. その Work メトリクスが依存するシステム(Resource)メトリクスを見る
 * 例: DB のレスポンスタイム
 * 例: Containerの CPU, Mem, Disk, Network
 * Work メトリクスと相関していそうな Resource メトリクスを見つける
0. Resource メトリクスに当たりをつけたら、障害が起きてる時間帯のイベントとログを見る
0. 原因を突き止め、解決する

より具体的に、

* NewRelic の Overview から始める
* スループットやレスポンスタイム、エラーレートを見る
* External Services やコンテナの CPU、MEM を確認する
* 相関がありそうなグラフを見つける
* Slack, Datadog のタイムラインを見てその時間帯のイベントを調べる
* Logentries を見てその時間帯のログを調べる
* もしわからなければ、タイムレンジを伸ばしたり、前回似たようなことが起きたときいの時間帯で調べる

## Dashboard

### 誰でもひと目でわかることが大事

Wantedlyでは 1箇所にデータを集めて見られるようにしています。
それはインフラチームだけではなく、**すべてのエンジニア** にも一発で状況を把握するために利用しています。
理由は、Wantedlyの変化のスピードからCodeの変更やBuildをエンジニアで行われるからです。

そのため、ざっくりDeploy後のシステム状況を確認する際に、 **上から順番にApplication→Resource** を確認できるようにしています。

またインフラチームも一次調査、一次報告、対応をどうするべきか決めるのに非常に有効的です。

![Kobito.VGKzPY.png](https://qiita-image-store.s3.amazonaws.com/0/18843/435f45ff-f5f9-1b7c-87bf-4cb64387009a.png "Kobito.VGKzPY.png")

## まとめ

Wanteldyではこのようにして、ツールを組み合わせてモニタリングを行っております。
複数のツールを利用すると複雑な運用になりがちですが、Dashboardを作成し、誰もが最初に共通で見れるのを統一しております。
いわゆるTim Toady Bicarbonate*2な仕組みを意識してモニタリングを設計しています。 :)

### 参考

* [monitoring-101-collecting-data](https://www.datadoghq.com/blog/monitoring-101-collecting-data/)
* [The Tale of Plack - YAPC::Asia Tokyo 2010](http://transcripts.yapcasia.org/2010/The_Tale_of_Plack/)
* [Logentries doc](https://logentries.com/doc/)
* [NewRelic doc](https://docs.newrelic.com/)
* [Datadog doc](http://docs.datadoghq.com/)
* [Pagerduty doc](https://www.pagerduty.com/docs/)
* [HoneyBadger doc](http://docs.honeybadger.io/guides/errors.html)