observer.log中搜不到相关trace_id信息

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】4.2.1
【问题描述】
在sql_audit中查询到相关语句的trace_id发现在observer.log中搜不到信息，后面尝试把syslog_io_bandwidth_limit参数设置为10G仍然搜不到，各位有遇见类似的问题吗

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

#3

根因分析场景: SQL 执行出错
根因分析命令: obdiag rca run --scene=sql_execution_error --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}” （如果能提供具体的 trace_id 和数据库连接信息，可以更精准地定位问题）

日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

为了更好地帮助您解决问题，请您按照上述命令进行日志采集，并将生成的日志压缩包提供给我们。此外，还需要您提供以下信息：

  1. 能否提供具体的 trace_id 以及对应的 SQL 语句？这有助于我们更准确地定位问题。
  2. observer.log 文件的路径是什么？是否确认该文件为最新的日志文件？
  3. 调整 syslog_io_bandwidth_limit 参数后，是否重启了相关服务以使配置生效？
  4. 当前集群的版本号是多少？不同版本可能存在不同的行为表现。
  5. 是否有其他参数调整或系统变更操作与问题发生时间点重合？如果有，请详细描述。

附上敏捷诊断工具 obdiag 使用帮助链接

#4

是不是给设置的日志级别有关系 有的日志信息未打印 或者在其他节点 或者日志被覆盖了

1 个赞
#5

sql_audit这条SQL对应的svr_ip机器上查的日志吗

#6

我都是默认的WDIAG级别，SQL执行的节点都搜不到。。我搜的不光是当前的observer，包括前几分钟都搜了

#7

是的

#8

根据您的描述，问题可能与日志级别、日志采集范围或 trace_id 的生成机制有关。以下是可能的原因及解决方法：

1. 确认日志级别

  • 默认的日志级别为 WDIAG，但某些 SQL 执行信息可能未被记录到此级别中。
  • 您可以尝试将日志级别临时调整为更详细的级别（如 DIAG 或 DEVELOP），以捕获更多细节。

操作步骤：

-- 设置全局日志级别为 DIAG
ALTER SYSTEM SET log_level='DIAG';

注意事项：

  • 调整日志级别可能会增加日志文件的大小和写入频率，建议在测试环境中验证后再应用于生产环境。
  • 修改后需要重启 observer 生效：
    obd cluster restart <cluster_name>

2. 确认 trace_id 的生成与传播

  • 在 OceanBase 中，trace_id 是用于跟踪 SQL 执行路径的重要标识符。如果 SQL 执行过程中未正确生成或传播 trace_id，则可能导致无法在日志中找到相关信息。
  • 确保 SQL 执行时确实生成了 trace_id。可以通过以下视图查询：
    SELECT trace_id, sql_text FROM oceanbase.GV$OB_SQL_AUDIT WHERE sql_id = '<your_sql_id>';

检查点：

  • 如果 trace_id 为空或不一致，可能是 SQL 执行过程中存在问题，例如网络异常或分布式事务未正确传播 trace_id。

3. 确认日志采集范围

  • 确保您搜索的日志文件是正确的 observer 节点的日志，并且覆盖了 SQL 执行的时间段。
  • 使用 obdiag 工具采集相关节点的日志，确保采集范围包括所有可能执行该 SQL 的 observer 节点。

示例命令：

obdiag gather log --start-time="2024-03-01 10:00:00" --end-time="2024-03-01 11:00:00" --scope=observer --target-dir=/path/to/save/logs

4. 排查其他可能原因

  • SQL 并行执行：如果 SQL 使用了并行执行计划，trace_id 可能分布在多个 observer 节点上。请参考文档片段《并行执行问题诊断 → SQL 诊断 → 确认 SQL 还在执行并行查询》中的视图 GV$OB_PX_WORKER_STAT 查看并行线程的分布情况。
  • 日志滚动或清理：如果日志文件已被滚动或清理，可能导致无法找到相关信息。请确认日志保留策略是否合理。

5. 进一步诊断建议

  • 如果以上方法仍无法解决问题，建议使用 obdiag rca 工具进行根因分析。具体命令如下：
    obdiag rca run --scene=sql_execution_error --env "{db_connect='-h<host> -P<port> -u<user>@<tenant> -p<password> -D<database>', trace_id='<trace_id>'}"

总结

您的问题可能存在以下几种情况：

  1. 日志级别不足，导致关键信息未被记录。
  2. trace_id 生成或传播异常，导致无法匹配到相关日志。
  3. 日志采集范围不完整，遗漏了部分 observer 节点的日志。

请按照上述步骤逐一排查，并提供更多信息以便进一步分析。如果仍有疑问，建议联系 OceanBase 技术支持团队获取专业帮助。

更多信息请查看:

  1. 并行执行问题诊断
  2. 监控索引
  3. enable_sql_plan_monitor
  4. SQL 基础操作（MySQL 模式）
  5. 分布式执行和并行查询
  6. 查看节点
  7. 主键操作
  8. 监控告警
  9. 查询排名 TOP N 的 SQL
  10. oceanbase.DBA_OBJECTS

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#9

注意：需要在同一个会话中执行

obclient [test]> select count() from test2;
±---------+
| count() |
±---------+
| 0 |
±---------+
1 row in set (0.003 sec)

obclient [test]> select last_trace_id();
±----------------------------------+
| last_trace_id() |
±----------------------------------+
| YB420BA1CC68-000615A0A8EA6511-0-0 |
±----------------------------------+
1 row in set (0.002 sec)

obclient [test]> select * from oceanbase.gv$ob_sql_audit where trace_id=‘YB420BA1CC68-000615A0A8EA6511-0-0’;

[root@x.x.x.x ~]$ grep “YB420BA1CC68-000615A0A8EA6511-0-0” rootservice.log
[root@x.x.x.x ~]$ grep “YB420BA1CC68-000615A0A8EA6511-0-0” observer.log

#10

下面我这个就比较具体了，第一条insert找到的trace_id在日志中能搜到，第二条insert的trace_id在日志中就搜不到

image
image832×382 28.2 KB

image
image830×270 41.2 KB

#11

是有啥我以前没注意到的参数吗 :joy:

#12

你的ob是社区版么