Opserverは，Stack Overflowで有名なStack Exchangeがリリースした，オープンソースの監視ソリューションだ。この手のツールとしては珍しく，.NETフレームワークを使用して構築されている。
監視対象である各システムの状態の全体像をすばやく把握するためのツールだが，ドリルダウンアプローチを使うことによって，さらに深い調査を行うことも可能だ。開発者のひとりであるNick Craver氏は，InfoQに次のように説明している:
監視システムはシステムを高いレベルで可視化し，問題点を提示することによって，より詳細な調査を可能にするものであるべきだ，と私たちは考えています。
Opserverは複数のWebダッシュボードで構成されている。それぞれのWebダッシュボードが監視対象システムのひとつひとつに対応する。現時点ではSQL Server, ElasticSearch, HAProxy, StackExchange.Exceptional, Redisがサポート対象だ。またインフラストラクチャおよびネットワーク監視に，市販ツールであるSolarWindsのOrionを使用している。ただしOpserverのインストールにこれらのシステムすべてが必要ではなく，個々にオプトインベースで設定をすればよい。
例えばSQL Serverならば，CPUあるいはメモリ使用量に関する高レベル情報や，データベース全体の状況に関する情報をOpserverから取得することができる:
(画像をクリックして拡大)
10,000フィート上空から降りてくれば，もっと詳しい情報を見ることができる。例えばクエリを複数の基準(合計時間と平均CPU使用時間のように)でソートして確認することが可能だ。クエリ単位のクエリ実行プラン(実行時の手順に関する詳細)など，さらに詳細な情報も取得できる。
(画像をクリックして拡大)
Opserverのセットアップにはいくつかのステップが必要だ。GithubにあるOpserverのreadmeファイルの他にも，何人かのユーザが，自分たちのセットアップ作業体験について説明している。簡単に言えば，githubからのコードのクローン，コンパイル，IISサーバへの公開という手順だが，それ以外にもいくつか設定を行わなければならない。必要な設定には，セキュリティ設定とシステム設定の２種類がある。Opserverでは，Stack Exchangeが自ら使用しているものをベースとした，さまざまな設定例が提供されている。<site root>/Configにそれらの例がある。
認証方式などの項目は，SecuritySetting.configファイルで定義する。
<?xml version="1.0" encoding="utf-8"?>
<SecuritySettings provider="AD">
<!-- Optional, these networks can see the
overview dashboard without authentication -->
<InternalNetworks>
<Network name="SE Internal" cidr="10.0.0.0/8" />
</InternalNetworks>
</SecuritySettings>
<!--
Example of global access for everyone:
<SecuritySettings provider="alladmin" />
-->
システム毎にひとつの設定ファイルがある。現時点でサポートされている形式はJSONである。SQL Serverの場合の構成例を以下に示す:
{
"defaultConnectionString": "Data Source=$ServerName$;Initial Catalog=master;Integrated Security=SSPI;",
"clusters": [ // clusters are only available for SQL Server 2012
{
"name": "NY-SQLCL04",
"refreshIntervalSeconds": 20,
"nodes": [
{ "name": "NY-SQL03" }
]
}
],
"instances": [
{ // This instance cannot use the defaultConnectionString,
// so it has to specify its own.
"name": "NY-DB05",
"connectionString": "Data Source=NY-DB05;Initial Catalog=bob;Integrated Security=SSPI;",
},
// The server name on defaultConnectionString gets replaced by "name"
{ "name": "NY-DESQL01" } ]
}
Opserverで所定のシナリオをカバーできない場合は，ダッシュボードや設定オプションを追加して補うための拡張ポイントが用意されている。将来的にはこのプロセスを，より簡単で強力なものにする予定だ:
時間が許せば実施したいと思っている最大の変更は，プラグインモデルの導入です。タブやビュー，ポーラなどを簡単に追加して，それを他でも使用できるようにしたいと思っています。例えば監視タブの最上位にMongoDBを置いて，希望する任意の詳細レベルで情報を表示することが可能になります。
ロードマップに置かれた目標は他にもある。
監視ソリューションとも緊密に統合することで，リアルタイムデータだけでなく，データ履歴も保存できるようにしたいと思っています。
他のサードパーティ製ツールを使っている場合には，それらをベースインストールに取り込んで，Opserverを拡張できるような機能も必要でしょう。sp_WhoIsActive はすでに統合されていますし，sp_Blitzやsp_AskBrent，あるいはSQL Sentryのようなもっと大規模な製品も結合できるようになります。これらが必要だというのではありませんが，すでにあるのならば，そのビューや詳細情報を追加する ... つまり，そこから取得できる情報を利用できます。
Opserverはさらに，保有するデータの大部分を，JSONを使用したREST風な方法で公開しています。この方法ですべてのデータを利用可能にして，UIは完全にオプションにしてしまおうと考えています。そうすることで，誰でもスクリプトを書いてJSONを返すルートを再定義できるようになりますから，多くのユースケースに対して，本当の意味で解放されたものになると思います。
Stack Exchangeが独自の監視ツール開発を決定した理由を聞いてみた。 Nickによれば，組織的に成長したものだという。
もともとは，社内の全アプリケーションのログを収集しているStackExchange.Exceptionalデータベースで使用する例外ログビューアという位置付けで始まりました。その後，空き時間プロジェクトとしてそれまでなかった，あるいは正しく動作していなかった (SQL Server 2012のAlwaysOn監視の問題など) 監視に関する部分を追加し始めたのです。
次に，SQL関連で監視しておきたい部分の機能追加に着手しました。全システムを見るための単一の場所が欲しかったのです。それから後は，Stack Exchangeで使用しているすべてのシステムを追加する作業に取りかかりました ... 既存の監視機能のギャップを埋めるという当初の目標が，インフラストラクチャを写し出す１枚のビューを実現することに変わったのです。