作者：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监控告警相关功能的应用实践，感谢阅读！