Webman框架下实现高性能的分布式日志收集-php教程-PHP中文网

Webman日志必须输出标准JSON格式并包含trace_id、service_name等根层级字段，Filebeat需开启json.parse和keys_under_root，Logstash用@metadata动态索引，ClickHouse写入须单例复用+异步批量+严格类型匹配。

webman框架下实现高性能的分布式日志收集

Webman 默认用 Monolog 写文件，日志是纯文本格式，没有 trace_id、service_name 等字段，直接丢给 Filebeat + Logstash 就会丢失链路追踪关键信息。ELK 查不到 trace_id，等于分布式追踪失效。

必须强制切换为 JSON 格式输出，并确保字段齐全：

trace_id（不能叫 traceId 或 tid，Logstash filter 依赖这个 exact key）
service_name（用于动态索引名，别写成 app_name）
level、timestamp、message（Logstash grok 不介入 JSON 日志，这些字段要原生存在）
所有字段必须在根层级，不能嵌套——所以 Filebeat 配置里必须开 json.keys_under_root: true 和 json.overwrite_keys: true

现象是 filebeat 进程 running，但 Logstash 的 stdout 没任何输入，Kibana 里空荡荡。这不是网络或权限问题，而是配置错位：

没开 json.parse：Filebeat 默认不解析 JSON，需在 input 段加 json: true
json.keys_under_root 没设为 true，导致 {"trace_id":"xxx"} 被当成字符串塞进 message 字段，Logstash 看不到独立字段
Logstash filter 里误对 JSON 行用了 grok：报错 Cannot parse grok pattern 或静默跳过。正确做法是用 if [message] !~ /^\{.*\}$/ { grok { ... } } 只处理非 JSON 行
Filebeat 输出目标地址写错端口：Logstash beats input 默认监听 5044，不是 9200 或 8080

Webman 多实例部署时，user-api 和 pay-service 如果都往 webman-logs 这个固定索引写，Kibana 里根本分不清哪条是哪个服务的。更糟的是，ES 会因 mapping conflict 报错。

Logstash filter 中必须构造动态索引名：

Webman 2.2.0

Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。

下载

确认 Webman 日志 JSON 里有 service_name 字段（且非空）
用 mutate 注入：mutate { add_field => {"[@metadata][target_index]" => "%{[service_name]}-logs-%{+YYYY.MM.dd}"} }
加 fallback：if ![service_name] { mutate { add_field => {"[@metadata][target_index]" => "unknown-logs-%{+YYYY.MM.dd}"} } }
output 中只写：index => "%{[@metadata][target_index]}" —— 普通字段名无效，必须是 @metadata 下的变量

Webman 是常驻进程，但很多人还在控制器里调 $client->insert()，每条日志等一次 HTTP 请求返回，QPS 上不去，还容易拖垮整个服务。

真正能扛住每秒千级日志的写法只有三条铁律：

ClickHouse 客户端必须单例复用：在 app/bootstrap.php 绑定 \ClickHouseDB\Client::class，业务中用 $this->app->get() 获取，绝不在逻辑里 new
写入必须 batch + async：用 insertBatch()，每批 100–5000 行；数据先推到 Redis 队列或内存缓冲区，由定时器/Worker 异步消费
字段类型零容忍：ClickHouse 的 DateTime 字段只认秒级时间戳整数，传字符串如 "2026-07-28T10:00:00" 会转成 0，查不到数据还找不到原因

最易被忽略的一点：日志表建表时没设 PARTITION BY toYYYYMM(event_time)，查询条件再准也扫全表——Webman 接口慢，十次有九次栽在这儿。