共计 3167 个字符，预计需要花费 8 分钟才能阅读完成。
作者： 屿山
事实零碎往往有着较高的复杂度，咱们借助 Trace、Log、Metric 三驾马车使咱们的零碎具备了肯定的可观测性，但观测地位和信息往往是固定的，而咱们所遇到的问题经常是意料之外的，这就导致咱们可能定位问题的范畴，然而难以更进一步，这时候咱们就须要在咱们想要的地位采集信息来帮忙咱们，在通常的实际中这就意味着咱们须要增加日志逻辑并重启利用，这种做法老本较高而且会失落现场。而借助日志治理，只须要通过在控制台配置规定便能够在不重启利用的前提下，动静采集任意点位信息。接下来通过一个假想的排查流程来简略介绍下日志治理的实际。
动静日志打印
假如咱们有一条如图所示的简略的申请数据库的申请调用链路，当该调用链路的申请呈现了异样，在定位问题的过程中，咱们往往会须要晓得调用的堆栈信息，进而去排查堆栈上的办法，获取这些办法的参数、返回值、异样等信息，从而帮忙咱们查清问题的起因。借助日志治理的能力，咱们能够很不便地进行这些操作。
在这个场景下，当发现 AppB 的 /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.doCommondcom.alibabacloud.mse.demo.service.DruidService.query
以 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 规范，并进一步提供欠缺的符合标准的上报形式。
MSE 云原生网关预付费、MSE 注册配置预付费首购 8 折，首购 1 年及以上 7 折 。点击此处，即享优惠！
