Stack Exchange架构主管Nick Craver在最近的一篇文章中介绍了他们的监控系统。他在文章中讨论了监控策略背后的理念和动机，并介绍了他们的工具集——主要是Bosun、Grafana和Opserver。

Stack Overflow及其姐妹站点Stack Exchange运行在.NET和MS SQL Server、IIS Web服务器、HAProxy（作为负载均衡器）以及Redis和Elasticsearch提供的服务上。他们的主要数据中心位于纽约，在俄勒冈州有一个故障转移中心。Craver指出，Stack Exchange的监控通常包括“日志、指标、运行状况检查和分析”，他们使用Bosun、Opserver、Grafana和MiniProfiler作为主要工具。

Stack Exchange监控系统的数据源是日志、运行状况检查和时间序列指标。在日志方面，他们使用了标准机制和自定义库将日志推送到数据库中。日志包含了来自HAProxy负载均衡器的HTTP请求汇总日志以及来自Logstash的日志事件。他们的运行状况检查可以测试最终用户看到的内容，例如主页。度量指标被收集并保存在自己构建的开源监控工具Bosun中，Bosun将OpenTSDB作为后端存储。Bosun还会发送警报，Pagerduty负责处理事故升级。他们还有一个叫作Opserver的工具——显示整个监控系统的仪表盘视图。

所有Stack Exchange的应用程序都使用一个叫作StackExchange.Exceptional的日志记录库，这个库将日志发送到MSSQL Server。它其实是.NET日志库ELMAH的一个分支。Redis、Elasticsearch和SQL Server将日志记录到标准的位置，但不清楚这些日志是否会被发送到中央服务器进行聚合和搜索。来自网络设备的日志将被发送到Logstash，并可以通过Kibana仪表盘查看。可以使用MiniProfiler详细分析页面加载时间，MiniProfiler将显示跨越各层的方法调用时间。

Bosun先是由Stack Exchange开发，然后被开源出来。Bosun的主要功能是根据历史数据测试警报，提供了用于计算时间序列数据的查询语言、模板化警报以及时间序列趋势的警报和预测。与Nagios、Zabbix等传统监控工具不同，但与Prometheus等现代监控工具类似，Bosun不需要为每台服务器设置单独的警报。对于跨所有服务器的时间序列测量（例如CPU使用率），设置单个阈值检查就足够了。警报当中包含了违反阈值的时间序列清单，可以用来识别有问题的服务器。

Bosun支持多个后端存储，Stack Exchange还使用了OpenTSDB（和HBase一起）。Bosun的原始作者之一Kyle Brandt在文章写道，这是他们的痛点之一，由于他们“在其他地方没有使用HBase，所以管理HBase会占用他们大量的时间”。Bosun的附加代理是scollector，它负责从受监控的机器收集指标。它使用Go语言开发，用于替换OpenTSDB的tcollector代理。他们使用BosunReporter推送应用程序的指标。

健康检查侧重于检查最终用户体验以及内部服务的健康状况。Pingdom检查外部可访问的URL。Craver写道，面向最终用户URL（如主页）的检查非常关键，因为“主页检查可能会检查到我们无法检查到的问题，进行整体检查也很重要”。Fastly充当Stack Exchange站点的CDN和代理，它的运行状况检查可以确保在主数据中心发生故障时可以故障转移到辅助数据中心。除服务器端监控外，他们还使用浏览器API跟踪客户端的时间。

将所有这些结合在一起的是Grafana和Opserver。Grafana接入Bosun数据，用以显示时间序列指标。Opserver专注于整个基础设施的整体监控状态。为什么团队要自己构建Opserver，而不是使用Nagios或类似的工具？Craver解释说，当时没有一种工具可以满足他们的所有需求。与大多数工具一样，它是根据特定要求而开发出来的。Opserver仪表盘可用于深入查看各个服务和服务器。它需要以JSON格式进行静态配置，如果用于监控云环境（可能包含了一些临时主机）可能会有些问题。

查看英文原文：

https://www.infoq.com/news/2018/12/stackoverflow-monitoring

创作场景

Stack Overflow 监控系统内部架构初探