GithubのJason Dixon氏はローマで開かれたDevOps Daysにおいて、現在そして将来の最先端モニタリングツールについて、自身の考えを述べた。彼は「単一の責務にフォーカスした交換可能なコンポーネントによる構成可能なモニタリングシステム」を思い描いている。
Jason氏によると、そのようなシステムアーキテクチャには以下の特性が必要だという。
- 構成可能 (「責務、インターフェイス、プロトコルがきちんと定義されている」)
- 弾力性 (「モニタリングアーキテクチャ内部の機能停止に対して、弾力性がある」)
- セルフサービス (「デプロイするのにルートアクセスやOpsメンバの助けを必要としない」)
- 自動化 (「自動化できる」)
- 相関関係 (「サービス間に暗黙のモデル関係がある」)
- 職人技 (「使って楽しい」)
このようなシステムには、図にあるような互いにやりとりするコンポーネントが必要になるという。
- sensorは「ステートレスなエージェントであり、メトリクスを収集して、それをJSONとしてHTTPでログストリームに発行したり、直接メトリクスストアに発行する」
- aggregatorは「メトリクスを変換、集約したり、単なるリレーをする責務をもつ」
- state engineは「イベントストリーム内の変化をトラックし、理想的には季節性や予測により欠陥を突き止める」
- storage engineは「変換機能や集約をサポートしなくてはならない。理想的にはリアルタイムに近いメトリクス検索とJSON、XML、SVGなどの標準フォーマットでの出力ができなくてはならない」
- schedulerは「オンコールやエスカレーションカレンダーを管理するためのインターフェイスを提供する」
- notifierは「state engineによって提供されたデータとエスカレーションのための状態トラッキングを使って、アラートメッセージを構成する責務をもつ」
- visualizerは「ダッシュボードやその他ユーザインターフェイスからなり、システムからのメトリクスやアラートを提示する」
Jason氏は、データ収集計画の必要性とそれに必要な粒度の細かいメトリクスを収集できるアーキテクチャ変更について強調した。これによりトレンドと履歴データ解析から予測した閾値超えをトラックできる。
InfoQはこの分野で彼が現在取り組んでいるプロジェクトについて質問した。
目に見えるものとして、私はTasseoやDescartesといった、機能停止に対するOpsの対応を改善するツールに引き続き取り組んでいます。特に後者について、リアルタイムで異なるメトリクスを関連付けできることが、極めて重要だと思っています。シングルトングラフではめったにないエラーが連鎖した結果、機能停止が起こるというのはよくあります。これとは別に、Graphiteで不満を感じているのは、メトリクスの認可と名前空間がないことです。私はBackstopプロジェクトにメトリクス提出のためのトークン化されたアクセスを追加しようと計画しています。これにより管理者は個人開発者やアプリケーションに、metric名前空間への個別アクセスを許せるようになります。
これを含めて、ローマで開かれたDevOps Daysのプレゼンテーションはここからストリーミングされている。