CLS 监控告警:实时保障线上服务高可用性

作者:kingszhang

导语

日志服务CLS是腾讯云提供的一站式日志服务平台,提供了日志采集、存储、检索、图表分析、数据加工、日志投递、监控告警、仪表盘可视化等多项服务,协助用户解决业务运维、运营及审计等多种场景问题。

可观测性的意义

【服务的可用性】

对于任何一个线上服务来说,可用性都是一个重要的质量指标,用户能否用产品完成任务?效率如何?主观感受怎样?这实际上是从用户角度所看到的产品质量,是产品竞争力的核心,是产品可靠性、维修性和维修保障性的综合反映

99%的高可用意味着一年中服务只有3.56天不可用,而99.9%的高可用意味着一年中服务最多8小时不可用,99.99%的高可用则意味着一年中服务最多只有52分钟不可用。

更多线上服务,尤其是数据服务,其要求的可用性是5个9到6个9之间,也就是一年最多有5分钟不可用,那么如何完成这个巨大的挑战,如何巧妙地利用技术体系低成本做到这一点呢?

【微服务的问题排查】

对于很多比较老的线上服务,如果突然出现了线上问题,我们是可以登录机器查看日志的,但也面临着如下的棘手问题:

  • 如果访问量稍微大一点,日志很多怎么办?
  • 如果线上某个业务出了问题,如何通过日志一分钟内定位问题原因?
  • 如果服务调用链长,涉及很多服务,如何进行链路追踪?
  • 还有一个灵魂拷问,你怎么知道你的服务当前是否健康?怎么知道你的服务中的某个业务模块是否健康?

因此线上服务急需一种能力,能实时监控系统的状态,在系统发生异常时开发者能收到警告,而不是等待业务方反馈;当系统发生错误时,能帮助开发者更快更精准更快速地定位问题,也就是一种业务可观测型建设

微服务系统需要做到3-5-10,即系统发生问题时,3分钟定位问题原因,5分钟修复,10分钟上线。可观测性体系,要能主动发现99%以上的微服务问题,长期建设高质量高可靠性的系统。

业务日志监控体系

目前越来越多的用户选择将业务日志全部上报到腾讯云日志服务CLS内(包含全链路traceId),然后基于日志服务,制作各种业务监控大盘和获取告警信息。研发可以通过这套体系,获取全面的关于业务系统健康状况的信息。

在什么地方打印日志?

做好日志的打印是非常困难的,开发者必须明白哪些日志必须打印,而哪些日志是可以省略的。这里介绍几个非常非常重要的日志,这些日志都是必须要打印的。

以六边形架构为例,尽可能在所有的出站适配器和入站适配器的出入口处打印日志

用另外一张图更清晰的展示如下:

为什么打印这些日志?

【服务入口为什么打印日志】

  • 第一,对每一个请求都进行记录,当日志上报以后,可以根据请求的数量对系统的负载进行更好的监控;
  • 第二,对每一个响应都进行记录,当响应异常时,日志系统可以帮助开发者及时发现问题,而不必等待业务方的反馈;
  • 第三,一旦服务真正出现问题,可以通过服务入口处的日志在任何地方(开发环境/测试环境/线上环境)复现问题的场景。

【依赖的三方服务为什么需要打印日志】

  • 第一,任何第三方服务都是不可信任的,开发者必须面向失败编程,完整的记录三方服务的请求与响应,而不是依赖三方服务自己的日志信息;
  • 第二,当自己的服务出现问题而根据日志确实无法定位时(很极端的情况),就需要及时复现问题场景,但是如果复现是第三方服务响应的信息不一样,那复现必定是不成功的,但如果提前记录了第三方服务的响应,在开发环境复现时,就可以及时mock数据。

日志需要打印哪些值?

对于服务入口处和第三方依赖的日志,需要打印响应时间、返回状态码、当前操作人、调用的方法名、服务名、调用方IP、被调方IP、行号、日志级别、全链路ID、服务环境等等信息;对于普通的日志,主要注意全链路ID即可。

特别需要注意的是,全链路唯一ID必须在所有的请求中进行透传,一旦丢失,将会引起很多不必要的麻烦。

上报后的日志展示如下:

腾讯云日志服务CLS能力演示

面对业务日志的庞大监控诉求,腾讯云日志服务CLS拥有「百亿级日志,秒级分析」、「一分钟实时告警」等产品能力,提供日志一站式服务,轻松解决运维、运营等场景难题。

下面就让我们一起来看看CLS的核心功能演示。

日志检索功能

CLS的检索和分析可以使用Lucene和SQL语法,针对每一个字段进行搜索。也可以使用全文检索,这都是最基本的功能。我们对日志进行格式化之后,每个字段都可以单独检索,可以说是目前最灵活最为强大的和方便的检索工具之一

同时支持丰富的算数操作符:

详情请见:概述及语法规则

日志分析功能

日志服务最强大之处在于对于搜索出来的日志结果,可以使用SQL语句进行分析,CLS也可以做OLAP分析引擎使用。

如下图所示,分析了最近15分钟各个方法的平均耗时:

还可以切换成不同图表等来进行展示,并且可以保存为监控大盘:

支持众多的分析函数:

详情请见:检索分析

日志监控

上面说到,我们可以使用SQL语句配置一些图表,这些图表可以配置为一个专题的仪表盘,比如部分业务数据接出情况统计的看板:

制作仪表盘非常简单,只需要使用SQL和一些函数,会写SQL就会配置仪表盘。

我们可以针对每个接口的成功失败、错误码、接口QPS等制作看板。也可以上报tomcat、trpc框架,甚至用Nginx日志来做分析和指标看板。

监控告警

1. 配置告警

对于上述日志的分析结果,可以针对于某个指标配置监控和告警。

下图是选择了ERROR级别的日志,在近15分钟中进行聚合,如果聚合结构大于0,则触发告警。

下图是告警效果:

其中,告警策略是策略名称,触发条件是此接口一分钟内报错数量大于15就告警。当前数据是当前的报错数量。

下方的多维分析会展示出具体的报错原因和全链路ID,可以快速查看报错信息;也可以点击查询日志的链接,快速查看报错的详细信息。

如图,点击后可以查看详细的堆栈信息和全链路日志,快速定位问题。

2. 业务使用的场景举例

场景一

某次用户的服务突然发出告警,一分钟内失败数量达到40个以上。开发同学点击告警链接,然后使用SQL语句后快速分析得出报错集中在一台机器IP上,查看机器信息发现是宿主机故障,因此快速停止了该机器后,告警也随之解除。

如下图所示:

只花费1分钟,就定位到问题原因然后解决了问题。可以看到,如果没有日志服务,挨个上机器查看犹如大海捞针,可能一上午也无法定位具体原因!

场景二:

某用户业务告警突然发出电话告警。我们通过全链路日志快速分析后,得出问题原因是OLAP数据库性能瓶颈急需扩容,扩容后业务恢复了正常。从定位问题原因到解决问题只花费了不到10分钟

CLS在全链路场景的应用

在CLS中,只要拥有一个traceId,就可以借此一次性查询所有日志。

下图是一个全链路日志,它由多个服务产生,并最终聚合到CLS日志平台。CLS全链路日志主要用于日志的查看和聚合。

结语

在成本允许的前提下,除了业务监控,后续还可以增加JVM的监控, GC的监控,内存监控,Trpc线程池的监控。容器层还可以增加内存监控、CPU监控、网络IO监控。

业务监控和告警已经可以覆盖大部分场景了,剩下的这些在极特殊场景下才会发挥作用,如做全链路压测或性能压测时才可能需要查看线程监控信息。

对于分布式服务,保证服务质量需要关注的点有很多(如下图),一般的业务只需要做好其中几个点就可以保障服务的质量了。

很多质量问题都可以在开发上线阶段发现并且解决,下面附上一个开发注意的测试要点:

在需求上线后,对于新增的接口和业务,做好监控和告警,对于数据报表服务来说,如果上线后出现RT增加或者失败率增加的现象,需要及时排查,必要时回滚然后再查清原因。

在未来,CLS会继续打磨日志服务细节,不断精进监控告警能力,帮助用户在日志运维、运营、合规审计等业务方面实现跨越式发展,为线上服务的高可用性保驾护航,造福更多运维团队与开发团队。


以上就是将CLS监控告警相关功能的应用实践,感谢阅读!

版权声明:
作者:日志服务CLS小助手
链接:https://jkboy.com/archives/14089.html
来源:随风的博客
文章版权归作者所有,未经允许请勿转载。

THE END
分享
二维码
打赏
海报
CLS 监控告警:实时保障线上服务高可用性
对于任何一个线上服务来说,可用性都是一个重要的质量指标,用户能否用产品完成任务?效率如何?主观感受怎样?这实际上是从用户角度所看到的产品质量,是产品竞争力的核心...
<<上一篇
下一篇>>