Cassandra慢查询日志无应用匹配语句时如何捕获实际查询原文

核心匹配偏差原因 #

你当前在慢日志中捕获的带token(user_id, id)过滤条件的语句，并非应用侧直接发送的原始请求。这是Cassandra协调节点收到应用的范围类查询后，为计算跨节点路由范围，自动对原始查询做内部改写生成的执行版本——这类改写完全在服务端内部完成，不会将改写后的语句回传给应用，自然和应用侧留存的查询记录无法匹配。
另外你观测到的日志显示slow timeout 500 msec，和你在cassandra.yaml中设置的5000ms阈值不一致，可优先核对配置是否完成加载、节点是否按修改后的配置重启。

可落地的原始查询捕获方式 #

• 启用Cassandra内置审计日志
  这是准确率最高的方案：审计日志的捕获链路在CQL请求进入查询处理器的最前端，在所有语法改写、路由拆分、绑定变量赋值操作之前，就会完整记录应用侧提交的原始CQL文本，和应用实际发送的内容完全一致。
  配置操作：在cassandra.yaml中开启audit_logging_options.enabled: true，过滤掉系统表产生的内部查询日志；后续即可通过匹配表名（mainschema.events）、语句携带的ID参数值、时间窗口，和慢日志里的内部改写语句做关联——内部语句上的事件ID、token范围边界，和原始查询的主键过滤条件是完全对应的，匹配成本极低。
• 调整慢查询日志的输出格式
  Cassandra的慢查询事件对象本身会存储原始提交的语句上下文，只是默认的日志格式化逻辑只输出了经过执行优化、路由改写后的内部语句版本。
  操作方式：找到Cassandra对应配置目录下的logback配置文件，定位到慢查询日志对应的logger（包路径为org.apache.cassandra.db.querylog），修改日志输出的格式Pattern，将默认仅输出内部执行语句的占位符替换为同时携带原始语句的配置（Cassandra 4.0及以上版本可使用%rawStatement占位符），修改后慢日志会同时展示内部执行语句和用户提交的原始语句。
  注意：如果应用使用预编译（prepared）语句，需要在cassandra.yaml中开启prepared_statements_cache_logging，避免预编译的原始语句被缓存回收后无法关联到对应执行记录。
• 低比例开启请求跟踪做关联
  针对观测到慢查询的时间窗口，临时使用nodetool settraceprobability将跟踪概率设置为低比例（比如0.01，避免过高的性能损耗），让落在该窗口的请求自动生成全链路trace。trace日志会同时记录协调节点收到的原始CQL、内部生成的token路由条件、跨节点的执行耗时，可直接将慢日志中带token范围的记录和对应的原始查询关联起来。
  注意：生产环境仅建议在低流量窗口临时开启，不建议长期高比例开启，避免对服务稳定性造成影响。

内容的提问来源于stack exchange，提问作者Sam