次の指標になるものを集めることで問題の調査や診断に役立てる事が可能である。リソースがリクエストを受けて応答した時間のパーセンテージEventイベントはどの時点で何が起きたのかを詳細情報とともに記録する。イベントを例えると、いつどんなコードがコミットされたか、またはマージされたのか、どのタイミングで問題が発覚してチケットが切られたのかなどを扱える。データを見た時に鮮明に表現されていることが大切である。これはどんなデータのメトリクスで、今のパーセンテージはどんなイベントによって生じているか瞬時に理解できるようなものである。メトリクスの収集はシステムが抱えている問題を見逃さない周期で実行する必要がある。データの本来の意味を損なってしまうことがないようする必要があるため、周期を決める時は次の項目に注意する。早期にデータを破棄する、またはメトリクスの保存コストを削減するために、ある期期間を経過した後にデータポイントを集約する加工をしたりすると、過去の経過として収集した重要な情報を失うことになる。年以上の生データを保存しておくことで正常範囲を把握することが容易になる。基本的に重要度の低いアラート(record)に値するが、これは原因解析に役立てるために記録される。重要度が中レベルのアラート(notification)として問題解決できるエンジニアへ通知されるべきである。基本的に重要度の高いレベルのアラート(page)になる。通知を受ける人の仕事や睡眠、プライベートなどの時間に関係なく、どのような時間にも割り込んでくる。まとめ以上で紹介したそれぞれのメトリクスが持つ関係性は次の図として表すことができる。モニタリングに必要なことは以下となる。今日会社ではじめて「RACI」という言葉を知った。実装した月別アーカイブはてなブログをはじめよう!codehexさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。