filebeat 应禁用 multiline，配置 filestream 输入、直连 logstash 并添加应用字段；logstash 用 dissect 解析 python 日志，优先处理标准格式，非标日志分流过滤；容器需持久化 registry 目录防重复；性能瓶颈时用 dissect 替代 grok，并合理设置失败丢弃与 jvm 内存。
Filebeat 怎么配置才能把 Python 应用日志发到 Logstash
Filebeat 本身不解析日志内容，它只负责可靠地读取、转发。Python 应用日志格式不统一（比如 logging 默认输出带时间、级别、模块名，而 print 或第三方库可能纯文本），所以关键不是“让 Filebeat 解析”，而是“让它按行准确切分 + 传原始内容给 Logstash 处理”。
常见错误是直接在 filebeat.yml 里配 multiline.pattern 想合并 traceback，结果漏掉日志或卡住。实际更稳的做法是：禁用 multiline，靠 Logstash 的 dissect 或 grok 做结构化解析。
- 确保 Python 日志输出为单行：用
logging.basicConfig(format='%(asctime)s | %(levelname)-8s | %(name)s | %(message)s')，避免换行符混入 -
filebeat.inputs中指定日志路径，type: filestream（新版默认），关闭multiline（即不写multiline.*配置） - 用
output.logstash直连，别走 Elasticsearch 中转；Logstash 地址写成hosts: ["logstash:5044"]，注意端口和网络连通性 - 加
fields: {app: "my-python-app", env: "prod"}方便后续过滤，这些字段会作为 top-level 字段透传到 Logstash
Logstash 的 pipeline 怎么写才能正确解析 Python logging 格式
Python 的 logging 默认格式有固定分隔特征（如 | 或空格分隔的时间、级别、模块名），用 dissect 插件比 grok 更快更轻量，也更少出错。
如果日志里混了非标准输出（比如 print("debug info") 或 requests 库的 debug 日志），建议先用 if 判断是否含 | 再分流处理，避免 dissect 失败导致事件丢弃。
- 在
filter块中优先用dissect { mapping => { "message" => "%{timestamp} | %{level} | %{logger} | %{msg}" } } - 对
timestamp字段立即做date { match => ["timestamp", "ISO8601"] }，否则 Kibana 里 @timestamp 不准 - 加
mutate { rename => { "msg" => "message" } remove_field => ["timestamp"] }整洁字段名 - 如果应用用了
structlog输出 JSON 行，改用json { source => "message" }，别硬 dissect
为什么 Python 应用重启后 Filebeat 会重复发日志
Filebeat 记录每个文件的读取位置（offset）在本地 registry 文件里，默认路径是 data/registry。Docker 容器或 k8s Pod 重建时，这个文件丢失，Filebeat 就会从头读——看起来像重复，其实是“重头开始”。
- 容器部署必须挂载
volume持久化/usr/share/filebeat/data（或你配置的path.data） - 不要用
start_position: "beginning"，保持默认"end"；首次运行才需要手动删 registry 强制重读 - 检查
filebeat.registry.flush: 1s（默认值），避免 offset 写入延迟导致小概率重复 - 如果日志文件被 logrotate 切走，确认
close_inactive: 5m和clean_removed: true已启用，否则旧文件句柄残留
Logstash filter 性能差、CPU 飙高怎么办
Python 日志量大时，grok 是最大瓶颈，尤其正则写得宽泛（比如 .* 开头）或没设 break_on_match => false。一个 grok 规则慢 1ms，每秒 1w 条就拖慢 10 秒 CPU 时间。
- 优先用
dissect替代grok解析固定分隔的日志；只有真正需要正则提取（比如从 message 里抽 URL、异常码）才用 grok - 所有
grok规则加tag_on_failure => ["_grokparsefailure"]，配合if "_grokparsefailure" in [tags] { drop {} }快速丢弃脏数据，防止 fallback 链路拖慢主流程 - Logstash JVM 堆内存至少 2G（
LS_JAVA_OPTS="-Xms2g -Xmx2g"），小内存下频繁 GC 会放大延迟 - 测试阶段用
stdout { codec => rubydebug }看字段是否按预期生成，别等进 ES 才发现字段为空
真正麻烦的是 traceback 跨多行且无规律缩进，这种没法靠 Filebeat 或 Logstash 单点解决，得倒逼 Python 应用层改用 structlog 或封装 logging.Formatter 把 stack trace 转成单行 JSON —— 否则无论怎么调 Logstash 规则，都只是在补漏洞。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
