Kicjstarterで技術担当副社長を務め，“The Docker Book”の著者でもあるJames Turnbull氏が，FOSDEMとConfig Management Campの２回にわたって，モニタリングをテーマとするプレゼンテーションを行った。その中で氏は，現代的でスケーラブル，かつビジネス指向のモニタリングとして，セルフサービスAPIによるサービスとしてのモニタリング提供，プロジェクト開発への統合といった，氏のビジョンを公開した。
Turnbull氏の意見では，従来のモニタリングは注目するものが間違っている上に，時代遅れであったり，管理が難しいことが多いという。モニタリングは重要度のレベルに基づいて，ビジネス的な成果に注目するものでなければならない。
- ビジネスロジック。
- アプリケーション。
- サービス。
- インフラストラクチャ。
Turnbull氏はモニタリングの現状について，いくつかの数値を紹介した。それによると，モニタリング責任者の68%がビジネスロジックをモニタしていないという。検出されていない障害は90%，アクションの取られていない警告は80%であり，33%では場当たり的なモニタが行われている。
従来型ツールのアーキテクチャはもはや役に立たないし，中央集中型のモニタリングアプローチにはスケール性がない。中央に位置するモニタが対象システムの状態を監視するというプルモデルは，ターゲットシステムがイベントを送信するプッシュモデルに変更する必要がある。
モニタリングは，サービスが利用可能かどうかではなく，その実行状態に注目しなければならない。
障害検出は昨日のこと。 メトリクスは王である。 重要なのは自動化だ。
Etsyではすべてが計測され，グラフ化される。最上位のメトリクスはドルだ。なぜなら，それが彼らのビジネスだから。
モニタリングを現代化する次のステップは，ユーザに提供するもの，すなわちサービスを作り出す側への注目だ。それはビジネスオーナであり，あるいは開発者であり ... サービスとは常に，ユーザ中心のものなのだ。開発のモニタリングは，アプリケーションが運用段階に移行する時に行うものではない。常にプロジェクト開発の一部であるべきだ。
あなたはモニタリングの顧客ではありません。 製品開発をモニタリングするのです。それは別の機能です。 その他の開発として扱ってください。 モニタリングの責任者の説明責任を変えるのです。自分自身を調べる方法を，アプリケーション開発者たちに教えてください。
Turnbull氏は，開発者でモニタリングを行っているのが，わずか9%であることを紹介した。 開発者はヘルプディスクのチケットではなく，セルフサービスAPIにアクセスしてモニタリングを管理するべきだ。コンフィギュレーションとメトリクスへのアクセスが必要だからだ。
- サービス: 現在のコンフィギュレーション，ログ, ... 開発者とビジネスオーナのため。
- コンソール: アプリケーション開発者にコンソールで何を見たいかを確認し，彼らのメトリクスを見るためのツールを提供する。
- ログとレポート: 開発者の要望を集めて，ログやレポートで何を見たいのか確認する。
氏はモニタリング成熟モデルを書いて，組織が通過する３つの大きなステージについて説明している。
- マニュアル: モニタリングはダウンタイムの最小化を主な目標として，チェックリストや単純なスクリプトを使って，手作業で行われる。
- リアクティブ: Nagiosのようなツールを使って，大部分は自動的に実施される。可用性の測定と資産管理に重点が置かれる。
- プロアクティブ: モニタリングはインフラストラクチャとビジネスを管理するためのコアであるという理解の下，NagiosやSensu, Graphiteといったツールを使って，サービス品質やユーザエクスペリエンスを測定する。
Turnbull氏は現在，現在的なインフラストラクチャのモニタリングとメトリクスに関する技術の入門書として，“The Art of Monitoring”という書籍を執筆中だ。 FOSDEMとConfig Management Campで使用したスライドは，いずれもSlideShareで公開されている。