前言
最近老黄一直在弄双11相关的东西，所以博客和github都没怎么更新，这期间在公司也弄了不少东西。
下面就简单分享一下最近做的业务监控相关的内容吧。
先来说一下背景。
某业务在双11第一波大促的时候因为没有提供实时的业务看板，总结会的时候技术同事被相关领导和业务人员投诉，说是没办法清晰的了解到当时的情况，不能及时有效的调整对应的策略。
事后老黄了解到，那个业务是比较老的业务了，资源比较紧张，不敢去实时怼数据库(单点)，怕数据库挂了，业务就全凉了。
为了避免尴尬的现状，不想再一次挨批，只能搞呀。
分析现状
3个应用，.NET Framework的项目，都是windows服务器，没有容器化。
离双11只有几天，不能改动太大，而且还要应对业务部门新的需求。
当时能想到的方案
业务埋点，接入prometheus，结合grafana
业务发MQ，消费数据到ES，前端做个面板
业务埋点，接入日志服务，结合仪盘表
大致分析
方案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，用日志服务做统计肯定是不成问题的，难度相对比较低。
下面是具体的效果。
打码比较多，将就一下。
由于控制台上面提供了自动刷新和全屏的功能，所以挂面板出来的时候就可以省去人工的干预了。
总结
周一晚上被投诉，周二上午出方案，周二下午开搞，周三出结果，这一波操作真的是猛如虎。
不得不说，阿里云的日志服务确实是简化了很多繁琐的操作，解决了这一次问题的痛点。
但是抽取日志的方式还有待完善，有点别扭。
