现实系统往往有着较高的复杂度，我们借助Trace、Log、Metric三驾马车使我们的系统具备了一定的可观测性，但观测位置和信息往往是固定的，而我们所遇到的问题常常是意料之外的，这就导致我们能够定位问题的范围，但是难以更进一步，这时候我们就需要在我们想要的位置采集信息来帮助我们，在通常的实践中这就意味着我们需要添加日志逻辑并重启应用，这种做法成本较高而且会丢失现场。而借助日志治理，只需要通过在控制台配置规则便可以在不重启应用的前提下，动态采集任意点位信息。接下来通过一个假想的排查流程来简单介绍下日志治理的实践。

动态日志打印

假设我们有一条如图所示的简单的请求数据库的请求调用链路，当该调用链路的请求出现了异常，在定位问题的过程中，我们往往会需要知道调用的堆栈信息，进而去排查堆栈上的方法，获取这些方法的参数、返回值、异常等信息，从而帮助我们查清问题的原因。借助日志治理的能力，我们也可以很方便的进行这些操作。

在这个场景下，当发现AppB的/sql请求部分报错，但我们并没有预先编写能够记录有效信息的日志，这时我们就可以通过配置一条日志治理的规则来打印现场的堆栈信息，以获取我们需要排查的方法列表，再进一步对逐个方法进行分析。假设是/sql的请求出现了部分报错，我们选择/sql作为Target，如果不知道具体的接口，也可以选择全部。

由于我们只需要分析错误的请求，所以在过滤规则条件中开启异常过滤，在打印内容中选中调用堆栈，其他的内容可以根据需要选择。

开启该规则后，可以看到系统帮助我们在日志文件中打印了包含堆栈信息的日志，在 /home/admin/.opt/ArmsAgent/logs/mse-log-governance.log 日志下。

at com.mysql.cj.jdbc.ClientPreparedStatement.executeQuery(ClientPreparedStatement.java:989)
  at com.alibaba.druid.pool.DruidPooledPreparedStatement.executeQuery(DruidPooledPreparedStatement.java:213)
  at com.alibabacloud.mse.demo.service.DruidCon.doCommond(DruidCon.java:57)
  at com.alibabacloud.mse.demo.service.DruidService.query(DruidService.java:15)
  at com.alibabacloud.mse.demo.BApplication$AController.sql(BApplication.java:89)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

截取其中一部分可以发现com.alibabacloud.mse.demo.service.DruidCon.doCommond以及com.alibabacloud.mse.demo.service.DruidService.query都是我们自身的业务逻辑方法，也是我们需要关注的方法，我们可以继续借助日志治理的能力，去获取这些方法的现场信息，比如参数、返回值、类加载器等等。

以com.alibabacloud.mse.demo.service.DruidCon.doCommond为例，以 doCommond 方法为例，我们只需要增加一条新的规则，指定该自定义方法。

随后在过滤规则条件中开启异常过滤，在打印内容中选中请求参数，其他的内容可以根据需要选择。

开启该规则后，可以看到系统帮助我们打印了JSON格式的日志信息，包含了我们所勾选的参数信息，在 /home/admin/.opt/ArmsAgent/logs/mse-log-governance.log 。

{
  "appName": "app-b",
  "attributes": {
    "mse.tag": "base",
    "mse.param": "{\"sql\":\"select * from log_demo where id = ?\",\"id\":\"1\"}",
    "mse.app.tag": "base",
    "mse.service.type": "CUSTOM"
  },
  "endTime": 1665974434728,
  "events": {},
  "ip": "10.0.0.166",
  "name": "com.alibabacloud.mse.demo.service.DruidCon:doCommond(java.lang.String,int)",
  "needRecord": true,
  "parentId": -4669550334584716586,
  "ruleIdSet": [
    288
  ],
  "spanId": -8047278153886744300,
  "startTime": 1665974434725,
  "statusCode": 2,
  "traceId": "ea1a00009d16659744347231724d0001"
}

以上只是简单的例子，但是能够由此发现，日志治理的能力能够让我们在Java方法任意点位收集信息，将排查工作变成零代码且动态的，由于不需要在测试环境中重复增加日志代码并不断重启应用，能够大大减小某些难以在测试环境中复现的问题的排查难度。

日志采集

在启用了日志治理功能之后，我们的日志会被自动滚动保存至本地，为了满足存储或是进一步分析的需求，我们可以将这些日志采集到日志服务系统中。这里以SLS的Logtail采集方式为例。

配置Logtail采集日志

在通过组件或是其他方式在我们的集群或是实例中安装了Logtail之后，可以通过日志服务SLS控制台来完成日志采集的配置，这部分内容可以详见SLS日志服务的相关文档。我们只关注其中的一些配置，首先是Logtail配置，在K8s集群场景下，我们所需要的配置如下：

• 日志路径为/home/admin/.opt/ArmsAgent/logs/mse-log-governance.log（使用OneAgent时，日志路径为/home/admin/.opt/ArmsAgent/plugins/ArmsAgent/logs/mse-log-governance.log）

• 打开是否为Docker文件的开关。
• 打开是否部署于K8s的开关。
• 模式选择JSON模式。

其次是查询分析配置，在控制台配置流程中，我们可以选择自动生成索引或是后续在SLS控制台中自行增加索引，为了方便我们的分析，statusCode、ruleIdSet、name、appName等字段建议增加索引。

查看日志

稍等片刻后便可以在SLS控制台查看收集的日志，并借助查询分析功能处理日志。

小结

借助日志治理的现有能力，我们能够在不重启应用的前提下，动态采集任意点位信息，同时由于日志治理在采集信息时会引入链路信息，在分析复杂调用问题时能够起到很好的效果。目前日志治理采集的信息会以JSON格式的形式滚动存储在本地，我们可以通过借助SLS这类日志服务系统提供的采集方法采集并进行进一步的查询和分析，后续日志治理也会不断完善优化，采集的信息组织完全兼容OpenTelemetry标准，并进一步提供完善的符合标准的上报方式。

如有产品上的疑问请加入钉群：34754806，可提供产品答疑服务