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

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