​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用到的所有系统……目标从弥补现有监控的缺陷变成了要有一个基础设施的单一界面管理视图。