事情本身不复杂，线索都在日志里。Python 服务用 logging 加 json.dumps 输出日志，日志平台里中文全是反斜杠 u 开头的六位串，检索中文关键词一条都搜不到。
第一反应是「filebeat 的 decode 配置把非 ASCII 替换掉」，验证下来不成立。
把日志和配置对完，能解释这个现象的基本就这几处。json.dumps 默认 ensure_ascii 为 True。另一种情况是日志格式化器自己又转义了一次。
另外，终端编码是 GBK，写文件时已经被替换。
复现两种编码结果
python -c "import json;print(json.dumps({'msg':'启动'},ensure_ascii=True));print(json.dumps({'msg':'启动'},ensure_ascii=False))"再往下确认日志文件的真实编码
python -c "print(open('t.log','rb').read()[:40])"接着写入时指定 utf-8
python -c "open('t.log','w',encoding='utf-8').write('启动');print(open('t.log','rb').read())"等前面都确认过，再在新日志里检索中文
python -c "print('启动' in open('t.log',encoding='utf-8').read())"同样的操作我在测试机上先走了一遍，线上只做验证过的部分。
改完先别撤，确认这几项。新日志里中文原样可见，检索「启动」能命中，只有历史日志保留旧格式。
提醒一点。ensure_ascii 只影响序列化，不解决终端编码，两处都设成 utf-8 才能一路到底。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。