星环大数据基础平台 TDH
星环数据云平台 TDC
分布式数据库 ArgoDB
分布式交易型数据库 KunDB
星环大数据开发工具 TDS
智能分析工具 Sophon
星环知识平台 Transwarp Knowledge Hub
星环大模型一体机
星环智能识别一体机
星环国产ARM大数据一体机
星环X86超融合大数据一体机
9.3.3.1 服务日志阅读技巧
更新时间：2/27/2024, 6:50:19 AM
当 ArgoDB 中的服务出现异常，且无法通过 Manager 或其他可视化平台定位故障原因并有效解决时，可以通过查看对应服务的日志，进一步分析原因并解决问题。
本章节就 ArgoDB 日志中一些重要的信息和技术指标做出解释，帮助您更快更准确的阅读日志并定位故障信息。
筛选日志
ArgoDB 服务的日志是由多个线程提交单线程写入的，其中有大量可忽视的信息，因此在阅读日志之前，需要进行前期的信息收集和过滤工作，缩小日志检索的范围。
缩小和确定时间范围
由于并发高，任务量大，任务执行的日志可能只能保留数个小时，导致无法截取和保留对应的任务信息，此时就需要采取措施尽量的保留日志信息。提供一下思路：
-
修改日志配置，在存储允许的情况下，增大日志文件的保留数量。
-
修改日志输出格式或日志等级，减少冗余日志输出。
-
编写脚本，定期将日志文件转移到其他目录。
时间筛选
并发量不大的情况下，通过时间范围可以快速定位日志行数，找到任务执行信息。
sql 筛选
当并发量较大时，需要通过 sql 中的关键字，找到编译开始的标志：Parsing command: 后的 sql 语句，进而定位到任务执行的初始阶段。
session id 筛选
在找到 Parsing command: 后，该行日志的另一个重要信息，session id （如 SessionHandle=b23952ef-b981-4d0f-89cc-aafc3d05bd65）表示了这个查询任务所处的 session 的编号，以此可以进一步过滤日志，找到特定 session 连接中提交的任务执行情况。也因为 session 中任务执行是串行的，经过 session id 筛选后的日志可读性会更好。
|
但同时需要注意的是，部分日志信息中是不包含 session id 的，则这部分日志会被过滤掉。 |
日志类型筛选：
日志类型的筛选参考下一节中的日志分类以及后续各类型日志的解析。
服务日志分类
ArgoDB 的计算引擎 Quark 服务中，大部分包含了三个主要的角色：Server，Executor，Metastore。其中信息量最大，也同时作为连接两外几个角色的枢纽 ——— Server 的日志，是下文中的主要内容。
图 6.3.10：日志分类
Server 日志分析
连接情况
Session 连接情况
-
为 Server 的连接情况，体现了 Server 的并发压力。
-
打印出当前 ArgoDB 的连接情况，由于 session 内的任务执行是串行的，一定程度上也能代表了当前的并发情况。
2023-03-31 16:35:45,578 INFO service.CompositeService: [pool-28-thread-1()] - Current active session count after time out check: 7
复制
Connection 连接情况
-
是 server 与 metastore 建立的连接情况，这部分一般使用不到，但切实体现了 metastore 当前的健康情况。
-
以下日志包含了 ArgoDB 关闭一个 metastore 连接
2023-03-31 17:38:17,809 INFO hive.metastore: [HiveServer2-Handler-Pool: Thread-13864()] - Closed a connection to metastore, current connections: 10
复制
GC 日志
ArgoDB 5.2 中 Quark Server 日志 /var/log/<quark名称>/quark-server.log 中可以查看 GC 信息（如 gcTime 和 count）
GC 的信息是通过 GC 日志进行输出的且每分钟打印一次，其中需要注意：
-
打印 GC 日志需要设置日志级别为 INFO：
set inceptor.log.level= INFO（默认为 WARNING 不打印） -
如果 GC 日志间隔超过了 1 分钟，一定发生了比较严重的 GC，具体故障示例请参考Quark 服务高 gc 日志
-
count 和 gcTime 的数值是个积累值，两条记录相减，就是这段时间间隔内的 GC 总次数和总时间
-
如果 count 数值变小了，那一定是因为 server 重启。
Session 日志
ArgoDB 的并发可以认为是以 session 为单位的，也因此这部分日志是检查 ArgoDB 性能和任务执行情况时最主要的部分，获得这块日志的前置工作，可以参考上文阅读日志过滤部分。
Session Status 信息
如果获取的日志包含了一个完整的 session 的声明周期，那通过 SessionHandle 过滤出来的日志的开头和结尾可以看出，一个 session 连接的创建，伴随着一个临时目录的创建，session 创建的临时目录没有被及时删除，原因是当 session 没有被正常关闭时，这部分目录是不会被正常删除的。
PerfLog 日志
PerfLog 日志是 Session status 日志的子集，可以通过 session id 将 session 日志过滤出，然后用 PerfLog 字段，过滤出 PerfLog 日志。
PerfLog 日志使用了 PerfLogger 模块，包含一些 SQL 事件。同时 PerfLog 的日志格式较为固定：
-
事件开始：<PERFLOG method=EVENT>
-
事件结束：</PERFLOG method=EVENT start=xxx end=xxx duration=xxx>
通过 PerfLog 事件结束位的 duration 可以知道这个阶段共执行了多长时间，在检查性能问题的时候，这个时间是非常重要的数据。
Job Status 日志
由于不同类型的计算任务，设计到的表结构都会影响到最终输出的日志的内容，所以此处只是一个 HOLODESK 表查询任务的示例。
PerfLog 日志体现了 ArgoDB 执行任务的各个阶段的统计情况，具体的细节和一些其他的信息会在 session 日志中。相对的，完整的 session 日志内容也会更加冗余，最好是带有目的地去查询日志。
此时可以通过 PerfLog 来帮助更好地定位日志。也因此，这部分的介绍可以认为是对 PerfLog 日志的详细解读。
-
compile 编译过程
这个过程是能很清楚和直接通过 PerfLog 来定位找到的日志，非常明显的标志就是开头和结尾的 compile 的 PerfLog 锚点。
-
execute 计算过程
这个过程与有两个标志，可以类比编译过程一个是 PerfLog，另一个就是
Starting command:日志。 -
Fetch Result 过程：含有两部分，一般日志中显示的是第一步。
-
Server 从存储计算中间结果的临时目录将数据 move 到目标表目录中。
-
JDBC Client 从 hdfs 目录中 fetch 数据。
-
Heartbeating 日志
心跳日志是 ArgoDB 中比较常见的一种日志类型，很多线程都是通过心跳，来表明自己的状态。也因此，当遇到一些服务异常的情况，我们可以去查询对应服务的心跳情况来确认服务的健康情况。
ArgoDB 中许多服务都会打印对应的心跳日志。
日志常见故障处理
报错信息 1：
license is expired复制
解决方法：
License 相关报错，请进入 Manager 中检查许可证是否有效或已过期，详细处理步骤请参考Manager 异常。
报错信息 2：
InvalidOAuth2ConfigurationException: OAuth2 configuration not found复制
解决方法：
-
检查集群以及启动服务的安全开启是否一致。
-
在集群安全关闭的情况下，服务的认证参数改回默认值 NONE。
报错信息 3：
SPNEGO login failed with https://xxx:8380 and no more servers to retry the request复制
服务开了安全，但是连不上 Guardian 导致启动失败。
解决方法：
检查 Guardian 服务是否健康。
报错信息 4：
Failed to lock directory复制
解决方法：
常见的目录配置是否正确，比如文件配置的路径是否在对应的节点中真实存在。
报错信息 5：
Failed to bind to: /0.0.0.0:51888 Caused by: java.net.BindException: Address already in use a复制
端口冲突：报错中一般会直接报出冲突的端口号，比如该报错中冲突的端口号为 51888。
解决方法：
-
Manager 对应服务配置中查看该端口号对应信息。
-
运行命令查出端口冲突的进程 ID：
netstat -anp | grep <step1 中的端口号>复制 -
查出具体哪些服务端口冲突：
ps -ef | grep <step2 中的进程 ID>复制 -
根据情况修改对应的 Port。
报错信息 6：
ERROR [Thread-60] thrift.ThriftCLIService(ThriftBinaryCLIService.java:run(111))...TransportException: Could not create ServerSocket on address 0.0.0.0/0.0.0.0:10000复制
解决方法：
Zoopkeeper 上注册信息变化或 catalog 等角色关闭停止，导致 Quark 在 Zoopkeeper 上的注册信息发生变化，导致启动失败。
报错信息 7：
Readiness probe failed：HTTP probe failed with statuscode：500复制
解决方法：
health-check 检查失败 尝试刷新安全插件。
文档反馈
