直接回答：经典四层：采集层（节点 Agent 如 Fluent Bit/Vector，本地缓冲、背压、元数据富化）→ 传输/缓冲层（Kafka 集群削峰，按业务分 topic，保留数小时到数天）→ 处理与存储层（流式清洗后双写：全文索引进 ES/Loki 供检索，原始日志进对象存储做长期归档与离线分析）→ 查询层（检索 UI、告警规则引擎、采样与聚合接口）。Kafka 在中间是整个系统的“减震器”，下游任何一层故障都不丢数据。
展开解析：容量与细节：百万 EPS 约折合数 GB/s（按平均 1KB/条），Kafka 按分区水平扩展，key 按服务名散列防热点；采集端必须有磁盘队列与限流，日志风暴（某服务故障狂打栈）时宁可丢弃低优先级也要保核心链路——分级（error 必保、debug 可采样丢弃）要在采集端就实施。存储成本是大头：ES 的索引按天滚动、热温冷分层（热数据 SSD、温数据 HDD、冷数据冻结到对象存储）、副本数与 segment 合并策略调优；列式归档（Parquet + S3 + 查询引擎）的成本只有 ES 的零头，审计与离线分析走这条路。查询体验：检索慢的第一嫌疑是“通配符前缀查询 + 高基数字段全文索引”，引导用户用结构化字段过滤；追踪场景用 traceId 索引关联日志与调用链。SLO 定义：端到端延迟（产生到可查 < 1 分钟）、不丢率、查询 P99，三者分开监控。
追问方向：日志与指标、追踪如何打通（exemplar）？突发流量下的降级策略怎么排优先级？
（约 500 字）