基于Prometheus和Grafana打造业务监控看板

前言

业务监控对许许多多的场景都是十分有意义，业务监控看板可以让我们比较直观的看到当前业务的实时情况，然后运营人员可以根据这些情况及时对业务进行调整操作，避免业务出现大问题。

老黄曾经遇到过一次比较尴尬的“事故”。

其中一条业务线，服务着的其中一个商家，把大部分流量切到另外一个地方去了，而我们的运营人员在当天却是完全不知情，第二天看了昨天的统计报表之后才发现这个商家的量少了很多，才能跟进协调处理。

ps: 当时实时报表比较欠缺，都是第二天凌晨生成昨天的数据报表，也没有告警机制。

后面就弄了个大屏幕做了业务监控的实时看板，看一眼就知道有什么风吹草动了。

先来看一下最终的效果图。

这个图里面主要包含了下面几个内容。

1. 总的订单数量
2. 退单的数量
3. 创建订单的频率
4. 不同渠道的订单量
5. 不同渠道的退单量

下面就介绍一下如何实现这样的业务监控。

搭建基础设施

这里涉及的基础设施就有两个，一个是prometheus，另一个是grafana。

先启动prometheus，这里直接用docker启动。

$base = Split-Path -Parent $MyInvocation.MyCommand.Definition
$prometheusyml = Join-Path $base prometheus.yml
$fileconfig = Join-Path $base "config"

write-host $prometheusyml
write-host $fileconfig

docker run `
    --name prom `
    -p 9090:9090 `
    -v ${prometheusyml}:/etc/prometheus/prometheus.yml `
    -v ${fileconfig}:/etc/prometheus/fileconfig `
    prom/prometheus:v2.20.1

下面是prometheus.yml

global:
  scrape_interval:     15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

rule_files:

scrape_configs:
  - job_name: 'file_ds'
    file_sd_configs:
    - refresh_interval: 10s
      files:
      - ./fileconfig/*.yml

这里用了基于文件的发现机制，没有用静态的。更多其他方式，参见 https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config

这个时候prometheus已经是运行起来了。

再来就是grafana了，启动这个更加简单。

docker run -d --name grafana -p 3000:3000 grafana/grafana:7.1.3

执行完，访问 localhost:3000 就可以看到登录界面了。

确定业务指标(metrics)

确定指标可以说是整个业务监控中最最最最最为主要的一个环节了，只有明确了我们要监控什么，我们才可以在业务上去进行埋点，拿到想要的数据。

这个其实和我们平时面对的需求是一个样的，需求明确了，做出来的东西才可能是我们想要的，需求不明确，做出来的东西可能就不会是我们想要的了。

为了帮助大家简单的理解相关的内容，这里举个监控的例子，监控不同渠道的下单和退单量。

涉及到量的，在一天内基本上是属于只增不减的，这个时候我们一般会选用 counter 类型来处理。

一个是下单，一个是退单，所以这里定义两个

• yyyorder_created_total
• yyyorder_canceled_total

counter类型的，一般在命名的时候最好都用_total作为结尾。

还有不同渠道呢？

渠道我们就用 lable 来标识一下。

最后展现格式大致如下：

yyyorder_created_total{appkey="mt",opreator="cw"} 1
yyyorder_canceled_total{appkey="pdd",opreator="cw"} 2

这里也要注意一个问题，确定指标的时候，也要避免定义太多指标出来，如果可以，考虑用label去进行区分同性质的内容。

业务埋点

在明确了业务指标之后，就要在对应的业务上去进行埋点操作，会对业务代码有一定的侵入性，当然如果业务代码写得足够好，耦合的东西少，或许可以借助AOP来埋点，从而降低侵入性。

后面就写个简单的例子来模拟业务埋点这一块。

创建一个ASP.NET Core的项目，并安装prometheus-net.AspNetCore这个nuget包。

<ItemGroup>
    <PackageReference Include="prometheus-net.AspNetCore" Version="3.6.0" />
</ItemGroup>

其次是启用 ASP.NET Core exporter middleware

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseRouting();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        // 这一句。
        endpoints.MapMetrics();
        endpoints.MapControllers();
    });
}

最后就是埋点了。

[ApiController]
[Route("")]
public class HomeController : ControllerBase
{
    private static readonly Counter OrderCreatedCount = Metrics
        .CreateCounter("yyyorder_created_total", "Number of created orders.", new CounterConfiguration
        {
             LabelNames= new [] { "appkey", "opreator" }
        });

    private static readonly Counter OrderCanceledCount = Metrics
        .CreateCounter("yyyorder_canceled_total", "Number of canceled orders.", new CounterConfiguration
        {
            LabelNames = new[] { "appkey", "opreator" }
        });

    [HttpGet]
    public string Get()
    {
        var appKeys = new[] { "ali", "pdd", "mt" };
        var opreators = new[] { "cw", "pz" };

        var rd = new Random((int)DateTimeOffset.Now.ToUnixTimeMilliseconds()).Next(0, 2000);
        var appKeyidx = rd % 3;
        var opreatoidx = rd % 2;
        OrderCreatedCount.WithLabels(appKeys[appKeyidx], opreators[opreatoidx]).Inc();

        var cRd = new Random((int)DateTimeOffset.Now.ToUnixTimeMilliseconds()).NextDouble();

        if (cRd < 0.3d)
        {
            OrderCanceledCount.WithLabels(appKeys[appKeyidx], opreators[opreatoidx]).Inc();
        }

        return "ok";
    }
}

上面这个控制器中，创建了两个Counter，就是上面确定业务指标中定义好的。

这里是每访问一次，就创建一个订单，同时生成一个随机数，如果是小于0.3，那么就当它是退单的，这样就可以把两种指标都模拟出来了。

程序刚启动是有部分默认指标的。

当我们访问埋点的地址后，可以发现我们自定义的业务指标也已经有数据了。

到这里，数据已经有了，我们要怎么呈现呢？

要想呈现数据，我们需要先让prometheus来保存我们的业务指标数据。

数据写入

把数据写入prometheus有两钟方式，一种是pull，一种是push。

pull是让prometheus主动去拉取我们产生的数据，只要我们暴露一个地址出来即可，这中也是比较推荐的做法。

push方式要借助pushgateway，埋点数据要先主动推送到pushgateway，后面在由pushgateway把数据写进prometheus。

默认情况下，当我们用了endpoints.MapControllers();之后，就会把数据暴露在 http://ip:port/metrics 这个地址上。

知道要用pull的方式后，还要做什么呢？当然就是要去配置promethues了。

前面我们的 scrape_configs 是通过文件去自动发现的，所以只要在挂载的路径上面加一个对应的yml文件就可以了。

老黄这里加了一个nc-service.yml，具体内容如下：

- labels:
    service: nc
    project: demo
  targets:
  - 192.168.1.103:9874
  - 192.168.1.103:9875

这个时候就可以在Targets里面看到我们这两个地址的信息了。

通过prometheus的默认界面，也可以发现数据已经正常读取了。

后面就是真正的数据查询和展示了。

数据展示

通过上面的步骤，我们已经保证数据可以正常写入和查询了，现在就在grafana中创建一个业务监控看板了。

在grafana中先配置我们的数据源。

这里填上我们prometheuse的地址保存就可以了，可以看到那个绿色的提示，告诉我们这个数据源是正常工作的了。

先来一个总的订单数。

创建一个新的dashboard，再创建一个Panel。

我们在panel中填写我们的信息还有就是选择要的图形。

然后就是写上查询条件，就可以看到我们要的结果了。

订单总数这个查询如下：

sum(ceil(increase(yyyorder_created_total[1d])))

里面用到了， sum、ceil、increase这三个函数。

其中 increase 是用来统计一段时间范围内的增量。后面带了 [1d] 这个范围表明这里是查看1天内的增量。

ceil是用来把increase的结果进行四舍五入的，可能有人会好奇，怎么还会要四舍五入呢？

看看下面这个图，大家就会发现，非常多的小数点。

其实这个和prometheus的统计方法是有关系的，这里不展开，先这样用着。

sum 这个是用来求和的，指标中还包含了很多label，我们还要把每个label的求和，才是真正的结果。

所以这里就得到了下面这个结果。

退单总数的查询和订单总数一样，只是把名字换成退单的即可。

sum(ceil(increase(yyyorder_canceled_total[1d])))

再来看看各渠道的订单统计。

既然是看各渠道的统计，那么这里就要用到前面定义好的label了。appkey代表的就是渠道，那么我们基于它去分一下组就可以了。

就得到下面的查询。

sum by (appkey) (ceil(increase (yyyorder_created_total[1d])))

结果如下：

同理，各渠道退单的也是一样的写法

sum by (appkey) (ceil(increase (yyyorder_canceled_total[1d])))

ps: 如果想把订单和退单的放在一个图里面，可以加多个查询。

示例如下：

现在有了所有渠道的总量，各个渠道独立的总量，那么我们有办法知道某个时间段的趋势吗？

这个是肯定有的，且听老黄慢慢道来。

有上面这个疑问，多半是经历过，某个时间段量非常多，但是有的时间段又几乎为零，玩的就是心跳呀。

我们可以把这个称之为时间段内的订单增长情况。

这里需要用到rate函数，这个就是帮助我们统计增长速率的函数。

它统计的是每秒的平均增长率，这个粒度有点太细，所以我们会在这个基础上乘以60，放大到一分钟。

然后在看它sum的结果，最后才四舍五入。

ceil(sum(rate(yyyorder_created_total[5m]) * 60))

结果如下：

从这个结果可以看出，订单大部分时间都没有增长，只在中间那个时间段，有部分单进来。

到这里主要的各个小panel已经完成了，剩下的就是在dashboard里面调整位置，大小那些了。

总结

这样打造出来的监控看板还是挺不错的，不过还是要注意下面几个问题的

1. prometheus是把数据存储在本地的，总是会达到上限的，这里要么是定期删，要么是写到远程存储。
2. prometheus自己独立的查询语法可能刚开始会比较不适应，查不出自己想要的结果，这里多查查资料，多实践基本问题也不大。
3. 业务埋点这一个块，还是要尽可能的减少对现有业务代码的侵入性。
4. 业务指标一定要确定好，不然埋点痛苦，查询也痛苦。

这里还没有涉及到告警相关的内容，后面有时间再写一个告警相关的。

文中示例代码：

https://github.com/catcherwong-archive/2020/tree/master/08/PromDemo

本文首发于我的个人公众号 不才老黄 ，不定期发布一些内容，有兴趣的可以关注一下哟！