拯救发际线，Prometheus在线服务监控实操指南，千万别再错过！

主动监控

• 主动监控：业务上线前，按照运维制定的标准，预先埋点。具体的实现方式又有多种，可能通过日志、向本地 Agent 上报、提供 REST API 等。
• 被动监控：通常是对主动监控的补充，从外围进行黑盒监控，通过主动探测服务的功能可用性来进行监控。比如定期ping业务端口。
• 旁路监控：主动监控和被动监控，通常还是都在内部进行的监控，内部运行平稳也不能保证用户的体验都是正常的（比如用户网络出问题），所以仍然需要通过舆情监控、第三方监控工具等的数据来间接的监控真实的服务质量。

Prometheus

http_requests_total{instance="1.1.1.1:80",job="cluster1",location="/a"} 100http_requests_total{instance="1.1.1.1:80", job="cluster1", location="/b"} 110http_requests_total{instance="1.1.1.2:80", job="cluster2", location="/b"} 100http_requests_total{instance="1.1.1.3:80", job="cluster3", location="/c"} 110

• 如果你想统计单机qps，sum(rate(http_requests_total[1m])) by (instance)
• 如果想用统计每个集群每个不同 location 的 path 的 qps， sum(rate(http_requests_total[1m])) by (job, path)，PromQL会依据标签job-path的值聚合出结果。

• Counter（计数器）：标识单调递增的数据，比如接口访问次数。
• Gauge（刻度）：当前瞬时的一个状态，可能增加，也可能减小，比如CPU使用率，平均延时等等。
• Historgram（直方图）：用于统计数据的分布，比如95 percentile latency。

服务框架的改造

• 类似于 Nginx 的多进程架构（master/worker），但同时也支持多线程的事件循环编程模型
• 支持多种接入协议（HTTP，Thrift，PB等），但主流是HTTP
• 业务通过 Module 来加载进框架执行（类似 Nginx 的 module，但更简单）
• 提供纯异步的下游访问 API

• 提供基础数据类型
1）目前并没有官方的Prometheus Client Library，几种开源实现也都不太符合框架的需求。目前实现了支持多线程多进程的Counter和Histogram（除了初始化之外，更新操作都是无锁的），而Gauge由于多进程场景有的情况是无法聚合监控数据的（没用统一的聚合方法，并不一定都可以相加），所以没有提供具体实现
2）基础数据要有类似注册表的功能，方便自动导出数据到/metrics接口
• 在服务框架埋点
1）要足够灵活，将容易变化的信息通过标签来表达。
比如一个web服务可能有echo，date两个location，如果要统计它们qps，不要定义echo_requests_total, date_requests_total两个不同名字的 metrics，而应该定义一个名为http_requests_total的 metrics，通过标签location（分别为echo/date）来区分，这样再增加/减少接口是不需要改代码的
2）理想情况是业务几乎为各种通信功能自行埋点，所以内置埋点要将常用监控项都要覆盖到（QPS，Latency，Error Ratio）

数据的抓取与展现

• 用户定义的metrics名字，可能是不符合Prometheus规范的，而遇到一条不合法的数据，Prometheus就会停止抓取，所以导出数据时要先做一遍过滤和改写
• 要控制导出数据规模，一些只对单机监控有意义的数据可以不导出（框架有针对单机的监控页面）

• Prometheus即是一个CPU密集型（查询）也是一个IO密集型（数据落地）的，CPU数量是多多益善，内存越大越好（来缓存抓取的数据，所以应该减少不必要的业务数据导出），尽量要使用SSD（这个很关键！），因为一旦Prometheus的内存使用量达到阈值会停止抓取数据！这个停止抓取的时间，至少是分钟级，甚至是无法恢复！所以只要有条件就要用SSD。
• Prometheus号称支持 reload，但目测不是很好用，比如你修改了告警规则文件，重载之后，新旧告警规则似乎会一起计算执行….

• 我没有找到将默认模板打包进 Grafana 的方法，只能迂回的创建了一个新的Grafana Plugin，在启动之后，每个业务实例只需要启动下这个插件，然后配置一个默认的 Prometheus 数据源，就可以使用统一的监控 Dashboard
• Dashboard 分为3行
1）第一行展示实时的 QPS，平均延时，平均排队时间，Coredump 数量，下游引擎失败率，下游引擎延时变化
2）第二行展示业务的延迟（50%和95%延迟），流量，吞吐（按照不同错误码）
3）第三行展示下游引擎的延迟（50%和95%延迟），流量，吞吐（按照不同错误码）

topk(5, 100*sum(rate(downstream_responses{error_code!="0"}[5m])) by (job, server)/sum(rate(downstream_responses[5m])) by (job, server))

注意这里的 Range Vector Selector - [5m]，意味着我们是基于过去5分钟的数据来计算rate，这个值取的越小，得到的监控结果波动越大，越大则越平滑，选择多大的值，取决于你想要什么结果。建议图表使用5m，而告警规则计算采用1m。如果业务不是很重要，可以适当增大这个值。

这一套监控模板基本覆盖了业务对可用性监控的需求，同时业务也可以自己定义监控指标并进行监控。

AlertManager

• 可以通过 webhook 机制，发送告警到一个中间服务转换格式再发送到内部告警接口
• 如果使用第三方告警管理平台，如PageDuty、OneAlert，可以直接用内置的 pageduty 支持或 webhook 发送告警过去
• 如果是一穷二白的团队，建议配置 email + slack，实现告警归档和手机 Push

Prometheus + Grafana + Mesos

• 目前并没有将 Prometheus 和 Grafana 容器化部署，因为这两者本身就没有什么特殊依赖；安装包存储在 minio 中。
• 由于 Prometheus 系统的特殊性，我们通常将其指定在一台固定的机器上执行，且将数据落地到一个固定的目录，这样重启 Prometheus 的影响会非常低
• Grafana 是展示给用户的，需要尽可能的保持固定入口，所以我们通过 HAPROXY_CONSUL 给其配置了代理

结论