基于阿里云日志服务快速打造简版业务监控看板

前言

最近老黄一直在弄双11相关的东西，所以博客和github都没怎么更新，这期间在公司也弄了不少东西。

下面就简单分享一下最近做的业务监控相关的内容吧。

先来说一下背景。

某业务在双11第一波大促的时候因为没有提供实时的业务看板，总结会的时候技术同事被相关领导和业务人员投诉，说是没办法清晰的了解到当时的情况，不能及时有效的调整对应的策略。

事后老黄了解到，那个业务是比较老的业务了，资源比较紧张，不敢去实时怼数据库(单点)，怕数据库挂了，业务就全凉了。

为了避免尴尬的现状，不想再一次挨批，只能搞呀。

分析现状

3个应用，.NET Framework的项目，都是windows服务器，没有容器化。

离双11只有几天，不能改动太大，而且还要应对业务部门新的需求。

当时能想到的方案

1. 业务埋点，接入prometheus，结合grafana

2. 业务发MQ，消费数据到ES，前端做个面板

3. 业务埋点，接入日志服务，结合仪盘表

大致分析

• 方案1，业务团队对prometheus几乎是0认知，了解相关概念都要花不少时间，pass

• 方案2，MQ目前用的是腾讯云的CMQ，被坑过2次了，也不能很好的hold住ES，pass

• 方案3，有按内部规范打日志，业务方只要在关键地方加一行对应的日志，然后交由logtail去采集，上传到日志服务

所以在这三种方案中，老黄还是选了方案三。

首先日志服务在内部各个系统都已经接入过了，也算是团队里面比较熟悉的了，其次是不会影响主业务，只在关键地方埋点，加日志。

虽说对业务代码有侵入性，但无疑是现阶段的一个最优解。

整体实现逻辑如下。

业务埋点

业务埋点，其实是一个非常简单，也是最为重要的一步。

我们有对应的日志帮助类，所以这里要处理的只是日志的内容。

SerilogHelper.Info($"[field1] [field2] [field3]", "metrics_name");

老黄这里给的约定是，字段内容放在[]里面，每个字段要用空格隔开。

然后就会把日志落盘到具体的某个目录，等着被Logtail采集到日志服务了。

当然这里有遇到一个问题，就是日志文件的格式，之前指定的是UTF-8，结果生成的文件是 UTF-8 with bom格式的。

这个会导致第一行日志不能被正确解析，所以要特别注意。

数据接入与展示

代码层面在上面一步已经搞定了，下面要做的就是日志的接入了。

根据业务场景，目前是一个应用一个指标，所以要建立三个日志库，按需选择存储时间，默认是永久。

建好日志库后要接入数据源，这里老黄选的是正则-文本日志。

然后就是一堆常规配置了。

最重要的是Logtail配置这一步。

日志路径，就是程序日志输出的路径，这样logtail才会去设置的路径采集。

正则是一个比较重要的内容，logtail会根据这个正则去解析日志，提取成一个个的字段，这样会比较方便后面的查询。

接下来是查询分析的配置了。

这里就是要把统计的字段指定一下，还有一个是关掉全文索引，因为这种场景下，开全文索引意义不大，浪费钱。

到这一步，我们就可以把数据采集上来了。

最后要做的就是查询结果了。只要会简单的sql，用日志服务做统计肯定是不成问题的，难度相对比较低。

下面是具体的效果。

打码比较多，将就一下。

由于控制台上面提供了自动刷新和全屏的功能，所以挂面板出来的时候就可以省去人工的干预了。

总结

周一晚上被投诉，周二上午出方案，周二下午开搞，周三出结果，这一波操作真的是猛如虎。

不得不说，阿里云的日志服务确实是简化了很多繁琐的操作，解决了这一次问题的痛点。

但是抽取日志的方式还有待完善，有点别扭。