Nginx+Kafka+ClickHouse日志分析架构实现分流不丢、写入快、查得稳：Nginx结构化转发JSON日志，Kafka高吞吐缓冲并保障有序可靠，ClickHouse用Kafka引擎+物化视图实时入库与高效查询，Grafana直连构建轻量实时看板。
用 Nginx + Kafka + ClickHouse 搭一个高性能日志分析大盘，核心在于“分流不丢、写入快、查得稳”。Nginx 负责轻量采集与初步过滤，Kafka 承担高吞吐缓冲和解耦，ClickHouse 提供亚秒级聚合查询能力。三者各司其职，避免单点瓶颈。
一、Nginx：把日志“推”出去，而不是存下来
Nginx 本身不处理分析逻辑，重点是把访问日志标准化、低开销地转发出去。推荐用 nginx-log-format 定义结构化 JSON 日志（如含 $time_iso8601、$status、$upstream_response_time 等字段），再通过 ngx_http_log_module 的 syslog 或 pipe 方式发往下游。
- 用
log_format输出纯 JSON，避免解析歧义；时间统一用 ISO8601 格式，方便 ClickHouse 自动识别 - 禁用磁盘日志写入（
access_log off），改用access_log syslog:server=127.0.0.1:5140 json;推送到本地 rsyslog 或直接对接 Kafka 的 syslog 插件 - 若流量极大（>10k QPS），可启用 Nginx 的
flush_timeout和批量发送，减少网络小包
二、Kafka：扛住峰值，保障顺序与可靠
Kafka 是整个链路的“弹性缓冲区”，要防止日志在突发流量下丢失或积压。建议按业务域或日志类型划分 Topic（如 nginx-access-prod、nginx-error-staging），每个 Topic 至少 3 副本 + 2 个 ISR，确保写入 ack=all。
- Key 设计建议用
host:port或request_id，保证同一来源/请求的日志分区有序 - Consumer Group 由 ClickHouse 的
Kafka Engine表驱动，需配置kafka_group_name避免重复消费 - 监控 lag（使用
kafka-consumer-groups.sh），若持续增长，说明 ClickHouse 写入慢或 Kafka 分区数不足
三、ClickHouse：建表、消费、查表，一气呵成
ClickHouse 不是传统数据库，建表逻辑直接影响性能。推荐用 ReplacingMergeTree（去重）或 CollapsingMergeTree（状态变更），主键按高频查询维度设计（如 (toDate(time), host, path)）。
- 创建 Kafka 引擎表作为“中转站”，再用
MATERIALIZED VIEW实时写入目标表，解耦消费与存储逻辑 - 时间字段必须为
DateTime64(3)或DateTime类型，并设为ORDER BY首列，否则按时间范围查询会全表扫 - 日常看板 SQL 尽量走
PREWHERE+ 主键前缀，避免SELECT *；大表聚合优先用sum(), uniqCombined()等向量化函数
四、大盘可视化：轻量对接，聚焦指标
不强依赖复杂 BI 工具。Grafana 直连 ClickHouse（用 clickhouse-grafana 插件）即可构建实时 QPS、响应时间 P95、状态码分布、TOP URL 等核心看板。
- 每个面板对应一条预聚合 SQL，例如：
SELECT toStartOfMinute(time) t, count() c FROM logs WHERE time > now() - INTERVAL 30 MINUTE GROUP BY t ORDER BY t - 避免在 Grafana 中做 JOIN 或子查询，这类逻辑提前在 Materialized View 里固化
- 报警可结合 ClickHouse 的
SYSTEM METRICS（如KafkaConsumersLag）+ Prometheus + Alertmanager 实现链路健康监控
这套架构上线后，万级 QPS 日志可稳定做到端到端延迟
