初识 Opserver，StackExchange 的监控解决方案

Opserver 是闻名遐迩的网站 Stack Overflow 的开源监控解决方案，由 Stack Exchange 发布。它基于.NET 框架构建，这在监控工具领域有些与众不同。

旨在为每个受监控系统的健康状况提供一个快速的总体视图，还允许用户使用下钻方法进行深入挖掘。 Nick Craver 是 Opserver 的创建者之一，他告诉 InfoQ：

我们认为，监控系统应该在一个较高的层次上展示系统，出现了什么错误，并允许用户通过下钻来了解更多细节。

Opserver 以 Web 仪表板的形式进行组织，每个仪表板专门针对一个特定的系统。Opserver 目前支持 SQL Server 、 ElasticSearch 、 HAProxy 、 StackExchange.Exceptional 和 Redis 。 Orion 是一款来自 SolarWinds 的商业工具。Opserver 还使用它提供基础设施和网络监控。一次 Opserver 安装并不需要使用所有这些系统，因为它们可以基于选择进行配置。

以 SQL Server 为例，Opserver 提供了关于 CPU 和内存消耗的高层次信息或者数据库的总体健康状况：

（点击图片可以查看大图）

在概览视图下面，Opserver 提供了额外的数据。例如，它提供了一个最常用查询的列表，可以按照多个条件进行排序（总执行时长、平均CPU 消耗）。对于每个查询，它提供了更多的细节信息，包括查询执行计划（查询执行步骤的详细分解）。

（点击图片可以查看大图）

SecuritySettings.config 文件定义诸如身份验证方法这样的设置项：

 
<?xml version="1.0" encoding="utf-8"?>
<SecuritySettings provider="AD">
   <!—可选，这些网络无须身份验证就可以看到概览仪表板 -->
   <InternalNetworks>
       <Network name="SE Internal" cidr="10.0.0.0/8" />
   </InternalNetworks>
</SecuritySettings>
 
<!-- 
面向所有人的全局访问示例
<SecuritySettings provider="alladmin" />
-->

每个系统有一个配置文件。目前支持 JSON 格式。下面是 SQL Server 配置的一个例子：

 
{
   "defaultConnectionString": "Data Source=$ServerName$;
Initial Catalog=master;Integrated Security=SSPI;",
   "clusters": [ // 集群只能用于 SQL Server 2012
       {
       	"name": "NY-SQLCL04",
       	"refreshIntervalSeconds": 20,
       	"nodes": [
       		{ "name": "NY-SQL03" }
       	]
       }
   ],
   "instances": [
       { // 该实例不能使用 defaultConnectionString，因此它得自己指定。
           "name": "NY-DB05",
           "connectionString": "Data Source=NY-DB05;
Initial Catalog=bob;Integrated Security=SSPI;", 
       },
       // defaultConnectionString 中的服务器名会被“name” 替换
       { "name": "NY-DESQL01" }     ]
}

如果 Opserver 没有包含某个特定场景，那么它还提供了若干扩展点，用户可以通过它们使用额外的仪表板和配置选项来增强该工具。按照计划，这个过程将来会更简单易用而且功能更强大：

若时间允许，即将到来的最大变化是加入插件模型。人们将能够增加其他人也可以使用的选项卡、视图、轮询器等。例如，用户可以增加一个 MongoDB 监控选项卡，并在上面可以添加想要添加的任何层次的细节。

在该工具的路线图上，Opserver 团队还有其它目标：

它还会在很大程度上与我们的监控解决方案集成，保存历史数据而不仅仅是实时数据。

如果用户使用了其它的第三方工具，那么我计划在基本安装中包含针对这些工具的功能，从而增强 Opserver。例如， sp_WholsActive 已经集成进来了，诸如 sp_Blitz 和 sp_AskBrent 这样的东西和像 SQL Sentry 那样更大的产品也将会绑定到里面。他们肯定不是必须的，只是如果有了它们会增加视图和细节……因为随后便可以获得它们提供的信息。

Opserver 还通过 JSON 以 REST-feeling 方式暴露它所拥有的几乎全部数据。我计划使所有数据都可以通过这种方式获得，那样，用户界面就是完全可选的。这允许任何人针对返回 JSON 的路径编写脚本，并以其它方式使用返回结果，那真的会开辟许多新的应用场景。

InfoQ 问 Stack Exchange，为什么决定构建自己的监控工具。Nick 告诉我们，它是自然长成的：

开始的时候，它是 StackExchange.Exceptional 数据库的中央异常日志查看器，是我们所有应用程序日志的集中存放位置。从那开始，作为一个业余项目，我开始添加还没有监控的方面，或者已经存在但还不准确的方面（例如，一个关于 SQL Server 2012 永远在线的监控问题）。

从那开始，我为我们想要留意的东西添加 SQL 功能，因为我想在一个位置查看所有系统。之后，我开始添加我们在 Stack Exchange 用到的所有系统……目标从弥补现有监控的缺陷变成了要有一个基础设施的单一界面管理视图。

查看英文原文：**** A first look at Opserver, Stack Exchange’s monitoring solution