当前位置:网站首页>基于阿里云日志服务快速打造简版业务监控看板

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

2020-11-08 13:48:00 Catcher8

前言

最近老黄一直在弄双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,用日志服务做统计肯定是不成问题的,难度相对比较低。

下面是具体的效果。

打码比较多,将就一下。

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

总结

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

不得不说,阿里云的日志服务确实是简化了很多繁琐的操作。

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

版权声明
本文为[Catcher8]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/catcher1994/p/13944136.html