Datadog のブログで公開されている "Monitoring 101: Collecting the right data" を読んだ。本記事は紹介した Datadog のブログ記事を独自に簡略化したものである。もっと詳しく知りたい場合は Datadog の記事を読むと良い。
記事では次の項目を実現するためにどんなデータを収集し分類するかが記載されている。
- 自動検知によって潜在的な問題に効果的なアラートを受信する。
- 素早く調査を行いパフォーマンスに関する原因へ到達する。
Metrics
メトリクスはある時点のシステムに関連する値を取得する。通常 1 秒間に 1 回もしくは 1 分間に 1 回など時間の経過とともに監視する。
メトリクスを以下の 2 つのとても大切なカテゴリに分けられる。
Work metrics
システムのトップレベルでの health 状態を表せられるメトリクスを指す。重要な要素は次のように分けられる。
- throughput: 一般的に絶対値で記載される、ある一定時間での処理量
- success: ある処理をして成功したパーセンテージ
- error: ある処理をして失敗したパーセンテージ（エラー数 / 処理数 で表現）
- performance: あるコンポーネントがどれくらい効率的に処理を行ったのか
Resource metrics
システムが持つロジックでデータベースを使っていた場合、そのデータベースは resource に該当する。
つまり外部のシステムをコンポーネントとして扱っていた場合、それが resource metrics になる。コンポーネントは CPU、メモリやディスク、ネットワークインターフェースといったような物理的なリソースもある中、データベースはもちろん、キーバリューストアなども resource として挙げられる。
resource metrics は次の指標になるものを集めることで問題の調査や診断に役立てる事が可能である。
- utilization: リソースがどれだけ busy 状態になっているかを表す指標
- saturation: リソースがサービスを行えず、どれだけ待ち状態にしているかを表している
- errors: 観測できない内部的なエラー
- availability: リソースがリクエストを受けて応答した時間のパーセンテージ
Event
イベントはどの時点で何が起きたのかを詳細情報とともに記録する。 イベントを例えると、いつどんなコードがコミットされたか、またはマージされたのか、どのタイミングで問題が発覚してチケットが切られたのかなどを扱える。
- Changes: 内部で実施したコードリリース、ビルドの実施およびビルドの失敗
- Alerts: 内部で派生または生成したアラートや第三者から受け取った通知
- Scaling events: ホストの追加や削除
良いデータはどう見えるのか
収集するデータは次の 4 つの特徴を持つ。
- Well-understood (よく分かること): データを見た時に鮮明に表現されていることが大切である。例えばこれはどんなデータのメトリクスで、今のパーセンテージはどんなイベントによって生じているか瞬時に理解できるようなものである。
- Granular (適切な収集間隔): メトリクスの収集はシステムが抱えている問題を見逃さない周期で実行する必要がある。データの本来の意味を損なってしまうことがないようする必要があるため、周期を決める時は次の項目に注意する。
- 周期は監視負荷の影響をシステムに与えない範囲
- 周期を短くしすぎない
- Tagged by scope (スコープに基づいたタグ付け): 固定化された構成に制限されることなく、供給停止(障害)状態でも迅速な対処をするために、収集しているデータと複数のスコープの関連性を保つこと
- Long-lived (長い保存期間): 早期にデータを破棄する、またはメトリクスの保存コストを削減するために、ある期期間を経過した後にデータポイントを集約する加工をしたりすると、過去の経過として収集した重要な情報を失うことになる。年やシーズンや月でメトリクスが変動する場合は、1 年以上の生データを保存しておくことで正常範囲を把握することが容易になる。
診断やアラートのためのデータ
- resource metrics は基本的に重要度の低いアラート(record)に値するが、これは原因解析に役立てるために記録される。
- Saturation
- Errors
- Availability
- resource metrics の utilization は重要度が中レベルのアラート(notification)として問題解決できるエンジニアへ通知されるべきである。
- Utilization
- work metrics は基本的に重要度の高いレベルのアラート(page)になる。通知を受ける人の仕事や睡眠、プライベートなどの時間に関係なく、どのような時間にも割り込んでくる。
まとめ
以上で紹介したそれぞれのメトリクスが持つ関係性は次の図として表すことができる。
モニタリングに必要なことは以下となる。
- できるだけ全てのメトリクスを収集する
- 気付く必要があるスパイク(急上昇)やディップ(急降下)が可視化できる程度の十分な粒度でメトリクスを収集する
- メトリクスとイベントには複数スコープに基づいてタグをつける
- 最低でも 1 年間はオリジナルの粒度で保存しておくべき
