使用 prometheus 监控应用
生产环境的应用往往都需要 7x24 小时高强度服务用户, 上线之后如果想睡好觉, 就需要知晓应用运行的某些状态指标, 以此判断应用是否健康, 这也就是监控的意义之一.
当然还可以有更高的追求, 例如: 接口 QPS, 接口的错误率, 接口的 90 分位响应时间等等, 这些可以帮助我们更好的了解应用的运行状态, 更好得确立优化方向.
于是接下来介绍一下开源监控组件 prometheus
本文假定您已经了解 prometheus 的基本概念.
指标类型⌗
简单介绍下我们将要用到的指标.
Counter⌗
Counter 是一个单调的计数器, 只能增加或重置, 常用来统计请求数之类的指标.
Histogram⌗
Histogram 常用来追踪请求响应时间之类的值, 使用 histogram_quantile() 函数可以计算不同分位指标.
如何使用⌗
应用端⌗
应用端我们使用简单的 koa 应用举例, 并且使用 prom-client 作为 prometheus client lib.
此应用会随机 0-100ms 的延迟, 并有 10% 的概率 http status = 400.
统计请求数量⌗
接着我们创建一个中间件, 来统计请求数量.
注: 为了演示方便, 直接使用 path 作为 label, 正常时候应该使用 matchRoute, 这样才能正确处理 path 中含有占位符的情况.
此时运行应用, 访问 http://localhost:3000/metrics 可以看到没有任何指标, 当我们手动发送几条请求, 便可看到指标:
请求次数与我们发送次数是匹配的.
统计响应时间⌗
响应时间也是同理, 只是指标类型不一样.
选用更加精确的 process.hrtime 计算时间差.
手动发送请求便可得到相应指标:
上面指标含义是, 一共 9 个请求, 总耗时 340.23ms, 响应时间都小于 100ms, 有 6 条小于 50ms 并且 3 条小于 25ms.
服务端⌗
可以 clone zcong1993/prometheus-grafana 项目快速启动一个 prometheus 和 grafana docker 应用.
修改 prometheus.yml 配置
访问 http://localhost:9090 查看 web 端.
常用查询语句⌗
- 最近 2 分钟平均 QPS, 根据路由分组
- 最近 1 分钟平均响应时间, 根据路由分组
- 最近 1 分钟 90 分位响应时间, 根据路由分组
- 最近 5 分钟, 非 200 请求率, 根据路由分组
总结⌗
对于一个普通的应用, 简单的监控中间件思路就是上面的情况, 但是如果你的应用是 cluster 模式, 那么问题会复杂很多, prom-client 项目里面也有示例. 但是我觉得云平台, 容器技术火热的今天, 我们已经没必要使用 node cluster 了, 多启用几个 pod 会更好.
虽然我们可以用语句拿到上面的那些指标, 但是还是不够直观, 所以后面还会继续介绍如何配合 grafana 使用, 使得这些指标更直观.