应用监控

On this page

写在前面

应用监控实际要比 OS、中间件的监控更为关键，因为某个 OS 层面的指标异常，比如 CPU 飙高了，未必会影响终端用户的体验，但是应用层面的监控指标出问题，通常就会影响客户的感受、甚至影响客户的付费。

针对应用监控，Google提出了 4 个黄金指标，分别是：流量、延迟、错误、饱和度，其中前面 3 个指标都可以通过内嵌 SDK 的方式埋点采集，本节重点介绍这种方式。当然了，内嵌 SDK 有较强的代码侵入性，如果业务研发难以配合，也可以采用解析日志的方案，这个超出了夜莺（夜莺是指标监控系统）的范畴，大家如果感兴趣，可以了解一下快猫的商业化产品

埋点工具

最常见的通用埋点工具有两个，一个是 statsd，一个是 prometheus SDK，当然，各个语言也会有自己的更方便的方式，比如 Java 生态使用 micrometer 较多，如果是 SpringBoot 的程序，则使用 actuator 会更便捷，actuator 底层就是使用 micrometer。

夜莺自身监控

我们就以夜莺自身的代码举例，讲解如何内嵌埋点工具，这里选择 prometheus SDK 作为埋点方案。

夜莺核心模块有两个，Webapi 主要是提供 HTTP 接口给 JavaScript 调用，Server 主要是负责接收监控数据，处理告警规则，这两个模块都引入了 Prometheus 的 Go 的SDK，用此方式做 App Performance 监控，本节以夜莺的代码为例，讲解如何使用 Prometheus 的 SDK。

Webapi

Webapi 模块主要统计两个内容，一个是请求的数量统计，一个是请求的延迟统计，统计时，要用不同的 Label 做维度区分，后面就可以通过不同的维度做多种多样的统计分析，对于 HTTP 请求，规划 4 个核心 Label，分别是：service、code、path、method。service 标识服务名称，要求全局唯一，便于和其他服务名称区分开，比如 Webapi 模块，就定义为 n9e-webapi，code 是 HTTP 返回的状态码，200 就表示成功数量，其他 code 就是失败的，后面我们可以据此统计成功率，method 是 HTTP 方法，GET、POST、PUT、DELETE 等，比如新增用户和获取用户列表可能都是 /api/n9e/users，从路径上无法区分，只能再加上 method 才能区分开。

path 着重说一下，表示请求路径，比如上面提到的/api/n9e/users，但是，在 restful 实践中，url 中经常会有参数，比如获取编号为1的用户的信息，接口是/api/n9e/user/1，获取编号为2的用户信息，接口是/api/n9e/user/2，如果这俩带有用户编号的 url 都作为 Label，会造成时序库索引爆炸，而且从业务方使用角度来看，我们也不关注编号为1的用户获取请求还是编号为2的用户获取请求，而是关注整体的GET /api/n9e/user/:id这个接口的监控数据。所以我们在设置 Label 的时候，要把path设置为/api/n9e/user/:id，而不是那具体的带有用户编号的 url 路径。夜莺用的 gin 框架，gin 框架有个 FullPath 方法就是获取这个信息的，比较方便。

首先，我们在 Webapi 下面创建一个 stat package，放置相关统计变量：

  1. package stat
  3. import (
  4.     "time"
  6.     "github.com/prometheus/client_golang/prometheus"
  7. )
  9. const Service = "n9e-webapi"
  11. var (
  12.     labels = []string{"service", "code", "path", "method"}
  14.     uptime = prometheus.NewCounterVec(
  15.         prometheus.CounterOpts{
  16.             Name: "uptime",
  17.             Help: "HTTP service uptime.",
  18.         }, []string{"service"},
  19.     )
  21.     RequestCounter = prometheus.NewCounterVec(
  22.         prometheus.CounterOpts{
  23.             Name: "http_request_count_total",
  24.             Help: "Total number of HTTP requests made.",
  25.         }, labels,
  26.     )
  28.     RequestDuration = prometheus.NewHistogramVec(
  29.         prometheus.HistogramOpts{
  30.             Buckets: []float64{.01, .1, 1, 10},
  31.             Name:    "http_request_duration_seconds",
  32.             Help:    "HTTP request latencies in seconds.",
  33.         }, labels,
  34.     )
  35. )
  37. func Init() {
  38.     // Register the summary and the histogram with Prometheus's default registry.
  39.     prometheus.MustRegister(
  40.         uptime,
  41.         RequestCounter,
  42.         RequestDuration,
  43.     )
  45.     go recordUptime()
  46. }
  48. // recordUptime increases service uptime per second.
  49. func recordUptime() {
  50.     for range time.Tick(time.Second) {
  51.         uptime.WithLabelValues(Service).Inc()
  52.     }
  53. }

uptime 变量是顺手为之，统计进程启动了多久时间，不用太关注，RequestCounter 和 RequestDuration，分别统计请求流量和请求延迟。Init 方法是在 Webapi 模块进程初始化的时候调用，所以进程一起，就会自动注册好。

然后我们写一个 middleware，在请求进来的时候拦截一下，省的每个请求都要去统计，middleware 方法的代码如下：

  1. import (
  2.     ...
  3.     promstat "github.com/didi/nightingale/v5/src/webapi/stat"
  4. )
  6. func stat() gin.HandlerFunc {
  7.     return func(c *gin.Context) {
  8.         start := time.Now()
  9.         c.Next()
  11.         code := fmt.Sprintf("%d", c.Writer.Status())
  12.         method := c.Request.Method
  13.         labels := []string{promstat.Service, code, c.FullPath(), method}
  15.         promstat.RequestCounter.WithLabelValues(labels...).Inc()
  16.         promstat.RequestDuration.WithLabelValues(labels...).Observe(float64(time.Since(start).Seconds()))
  17.     }
  18. }

有了这个 middleware 之后，new 出 gin 的 engine 的时候，就立马 Use 一下，代码如下：

  1. ...
  2. r := gin.New()
  3. r.Use(stat())
  4. ...

最后，监控数据要通过/metrics接口暴露出去，我们要暴露这个请求端点，代码如下：

  1. import (
  2.     ...
  3.     "github.com/prometheus/client_golang/prometheus/promhttp"
  4. )
  6. func configRoute(r *gin.Engine, version string) {
  7.     ...
  8.     r.GET("/metrics", gin.WrapH(promhttp.Handler()))
  9. }

如上，每个 Webapi 的接口的流量和成功率都可以监控到了。如果你也部署了夜莺，请求 Webapi 的端口（默认是18000）的 /metrics 接口看看吧。

💡

如果服务部署多个实例，甚至多个 region，多个环境，上面的 4 个 Label 就不够用了，因为只有这 4 个 Label 不足以唯一标识一个具体的实例，此时需要 env、region、instance 这种 Label，这些 Label不 需要在代码里埋点，在采集的时候一般可以附加额外的标签，通过附加标签的方式来处理即可

Server

Server 模块的监控，和 Webapi 模块的监控差异较大，因为关注点不同，Webapi 关注的是 HTTP 接口的请求量和延迟，而 Server 模块关注的是接收了多少监控指标，内部事件队列的长度，从数据库同步告警规则花费多久，同步了多少条数据等，所以，我们也需要在 Server 的 package 下创建一个 stat 包，stat 包下放置 stat.go，内容如下：

  1. package stat
  3. import (
  4.     "github.com/prometheus/client_golang/prometheus"
  5. )
  7. const (
  8.     namespace = "n9e"
  9.     subsystem = "server"
  10. )
  12. var (
  13.     // 各个周期性任务的执行耗时
  14.     GaugeCronDuration = prometheus.NewGaugeVec(prometheus.GaugeOpts{
  15.         Namespace: namespace,
  16.         Subsystem: subsystem,
  17.         Name:      "cron_duration",
  18.         Help:      "Cron method use duration, unit: ms.",
  19.     }, []string{"cluster", "name"})
  21.     // 从数据库同步数据的时候，同步的条数
  22.     GaugeSyncNumber = prometheus.NewGaugeVec(prometheus.GaugeOpts{
  23.         Namespace: namespace,
  24.         Subsystem: subsystem,
  25.         Name:      "cron_sync_number",
  26.         Help:      "Cron sync number.",
  27.     }, []string{"cluster", "name"})
  29.     // 从各个接收接口接收到的监控数据总量
  30.     CounterSampleTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
  31.         Namespace: namespace,
  32.         Subsystem: subsystem,
  33.         Name:      "samples_received_total",
  34.         Help:      "Total number samples received.",
  35.     }, []string{"cluster", "channel"})
  37.     // 产生的告警总量
  38.     CounterAlertsTotal = prometheus.NewCounterVec(prometheus.CounterOpts{
  39.         Namespace: namespace,
  40.         Subsystem: subsystem,
  41.         Name:      "alerts_total",
  42.         Help:      "Total number alert events.",
  43.     }, []string{"cluster"})
  45.     // 内存中的告警事件队列的长度
  46.     GaugeAlertQueueSize = prometheus.NewGaugeVec(prometheus.GaugeOpts{
  47.         Namespace: namespace,
  48.         Subsystem: subsystem,
  49.         Name:      "alert_queue_size",
  50.         Help:      "The size of alert queue.",
  51.     }, []string{"cluster"})
  52. )
  54. func Init() {
  55.     // Register the summary and the histogram with Prometheus's default registry.
  56.     prometheus.MustRegister(
  57.         GaugeCronDuration,
  58.         GaugeSyncNumber,
  59.         CounterSampleTotal,
  60.         CounterAlertsTotal,
  61.         GaugeAlertQueueSize,
  62.     )
  63. }

定义一个监控指标，除了 name 之外，还可以设置 namespace、subsystem，最终通过 /metrics 接口暴露的时候，可以发现：监控指标的最终名字，就是$namespace_$subsystem_$name，三者拼接在一起。Webapi 模块的监控代码中我们看到了 counter 类型和 histogram 类型的处理，这次我们拿 GaugeAlertQueueSize 举例，这是个 GAUGE 类型的统计数据，起一个 goroutine 周期性获取队列长度，然后 Set 到 GaugeAlertQueueSize 中：

  1. package engine
  3. import (
  4.     "context"
  5.     "time"
  7.     "github.com/didi/nightingale/v5/src/server/config"
  8.     promstat "github.com/didi/nightingale/v5/src/server/stat"
  9. )
  11. func Start(ctx context.Context) error {
  12.     ...
  13.     go reportQueueSize()
  14.     return nil
  15. }
  17. func reportQueueSize() {
  18.     for {
  19.         time.Sleep(time.Second)
  20.         promstat.GaugeAlertQueueSize.WithLabelValues(config.C.ClusterName).Set(float64(EventQueue.Len()))
  21.     }
  22. }

另外，Init 方法要在 Server 模块初始化的时候调用，Server 的 router.go 中要暴露 /metrics 端点路径，这些就不再详述了，大家可以扒拉一下夜莺的代码看一下。

数据抓取

应用自身的监控数据已经通过 /metrics 接口暴露了，后续采集规则可以在 prometheus.yml 中配置，prometheus.yml 中有个 section 叫：scrape_configs 可以配置抓取目标，这是 Prometheus 范畴的知识了，大家可以参考Prometheus官网。

或者，大家也可以使用 Categraf 的 prometheus 插件抓取 /metrics 数据，就是把 url 配置进去即可，比较容易。

参考资料