一篇文章带你了解监控告警设计

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/pursuing0my0dream/article/details/88815713

“哎哎,XX,很多客服反馈这个业务挂了怎么回事,赶紧看看。” 正在安安静静写代码的你心头一颤,出问题了。赶紧打开业务链接看看,真出问题了,怎么办,怎么查问题?一脸闷逼。

据说现代医学始于听诊器的发明,医生凭借该物收集放大从各个器官发出的声音以诊断问题。

我一直喜欢把我们做后台做业务的,称之为在快速飞行的飞机上修零件。边飞边升级。。在飞机上有各种各样的仪表盘指示着各个模块的运行情况。如果没有这些,估计只有等到飞机坠毁的时候才知道出问题了,这个时候为时已晚。

飞机如此,我们的业务与服务又该有什么样的仪表盘/听诊器呢?

这是我这篇文章想说的,当我们自己的后台服务及业务运行情况生病出问题了,怎么做好服务/业务的仪表盘-业务监控告警

意义与想要达到的效果

没有一个系统是100%没有问题的,那么我们要保证我们的业务和服务的可靠性。我们希望达到如下的效果:

  • 我们要能够及时的发现问题(先于客户/老板发现问题)。
  • 不想每天半夜爬起来处理不知道怎么来的问题(有一些事情准备)。
  • 出了问题,能够帮助我们,快速定位问题。

需要想清楚的问题

为了达到这样的效果,我不得不思考我们需要解决的问题和点。

1.什么是我们需要关心的点

只有了解你的业务,才能做出更好的系统设计。

通常来说,只有了解你的业务,你才知道哪些点应该是你重点关注的、哪些点是容易根据业务进展而做扩展的。一般来讲,一个业务服务应该关注的点,我觉得如下:

  • 机器系统资源(CPU/内存/网络/磁盘)、CDN等。
  • 如果是JAVA,需要关注JVM虚拟机运行情况。
  • 接口的调用量、耗时情况、错误异常等。
  • 具体业务节点(如注册、开户、交易、付款等等流程)
  • 具体运营节点(运营渠道来源统计、场景等)

2.怎么定义异常情况

通常来讲,如果没有什么特殊处理,今天同一时间与昨天同一时间的监控数值应该会基本一致。基于这样一个依据,我们可以做一些比较以发现问题。

  • 同比:当前时间跟昨天同一时刻进行比较,是上升还是下降。 用于突然的掉底或上升问题发现。
  • 环比:当前一段时间与前一段时间比较,一般用得比较少。
  • 七日平均值:当前时间与前七天同一时刻平均值进行同比。减少某天波动带来的影响。

3.什么时候发现异常情况

通常来讲,做一件事情,投入的成本时效性准确性三者之间同时达到比较好的状态是一件及其困难的事情。这个时候我们希望投入的成本带来最大化的,部分作出妥协。

冲突

  • 实时监控处理:强调实时性,针对关键节点、存在少量数据不一致或丢失情况。
  • 隔日处理:有充足的资源、全量节点、数据准确、利用大数据能力。

4.异常的程度如何

如同一个人生病一样,可能只是一个小感冒,也有可能得了大病。我们不可能为了小感冒而住院,也不可能忽略了大病的存在。因此我们需要给异常分级处理。

  • 忽略:一些可以忽略的数据波动,影响比较小的、不紧急的情况。
  • 通知:提醒负责人该关注一下这里的问题,视情况而处理,比如钱不够了加钱,交易上升了等等。
  • 告警:出现比较大的问题了,需要安排人力紧急排查了。

5.怎么通知

跟上面异常程度相对应的,我们需要有不同的告警方式通知关注者,既减少骚扰有能及时发现问题。
紧急程度依次是:短信/电话 > IM(微信钉钉等) > 数据图表

  • 短信/电话:对应异常告警等级。
  • IM:对应异常通知等级。
  • 数据图表:对应异常忽略/通知等级。

6.怎么做到是告警而非骚扰

这一点,我觉得把握住两点就可以:

  • 以人为本:人都是懒惰的,做到高内聚低耦合,暴露给外部是简单的。
  • 精细化处理(细节):精细化处理某些节点。根据不同场景采取不同策略。

如何去做的问题

我大概分3个阶段去说明一下

1.简单处理

当业务或系统刚开始做的时候,这个时候也需要监控告警,但是暂时又没有这么大的人力去做,这个时候我们可以简单处理一下,对几个关键节点根据数据库记录,做隔日统计和分析,先做一个。完成从0到1的过程。

  • 定时扫描关键节点数据库统计同比。
  • 统一阀值波动告警。

简单处理

2.业务数据计算统计模块

当业务或系统成长到一定阶段,这个时候简单的全量扫表会出现各种问题,比如性能耗时等等,这个时候,我们可以将监控告警独立成单独的模块做处理。

  • 实时统计自己若干节点,保存到统计数据库(5分钟粒度)
  • 根据今明两天数据做同比。
  • 分不同紧急程度不同阀值实时告警(可配置中心配置)
  • 统计数据库通过otter同步到大数据做数据分析和报表。

业务数据计算统计模块.png

3.日志收集分析系统

随着业务或系统的发展,可能不止一个业务或系统需要这样的监控告警的能力,这个时候,我们可以将监控告警做成一个系统,可供多个业务或系统使用。抽象成业务关注的节点通过行为日志上报,大数据中心做数据分析和存储。

  • 定义需要统计的节点的维度、度量、原始数据留存时间。
  • 业务上报日志客户端。
  • 明细日志数据临时存储、通过otter或kafka同步到大数据中心。
  • 大数据中心根据节点、统计维度、度量、统计时间做交叉数据统计。
  • 根据交叉数据做实时监控告警。
  • 根据明细数据做全量数据报表。

日志收集分析系统.png

效果

针对一些比较关注的点,当出现比较大的下滑或上升的时候就可以人工介入。
实时告警

这个时候,我们收到了告警,有时候很难一下子发现问题,这个时候曲线图去查问题就要方便很多。

image.png

最后,希望看到最后的你有所收获。>-<

都看到这里了,关注个公众号吧,一起交流学习
微信公众号rudy_tan_home

展开阅读全文

没有更多推荐了,返回首页