日志平台迁移别急着推倒重来老旧 ELK 平台遇到性能或成本问题时很容易被“换一套就好了”的想法推动。日志链路却牵涉采集、缓冲、索引、查询和保留策略任何一段切换得太快都可能让排障时失去最需要的数据。更可靠的迁移方式是保留旧链路先让新链路旁路接收少量流量再核对字段、延迟和丢失情况。确认告警、查询和回退流程都可用后才扩大范围。双写不是永久方案必须提前设定观察指标和退出条件。ELK 向云原生可观测架构演进的四阶段路线图针对存量系统最稳妥的迁移路线是在采集层做双写在路由层做收敛在存储层做冷热渐进切割。第一阶段采集端解耦——用 Vector 替代臃肿的 Logstash旧 ELK 架构最大的痛点通常在于 Logstash 占用极高内存且 CPU 开销巨大。迁移的第一步是在不修改业务日志输出格式的前提下用高性能轻量级采集器Vector 或 Log-Agent替代 Logstash。Vector 双写与分流配置实战下面的 Vector 配置文件演示了如何接收业务 JSON 日志并将其同时投递给旧 Elasticsearch 和新架构的 ClickHouse# /etc/vector/vector.toml [sources.app_logs] type file include [/var/log/pods/*/*/*.log] read_from beginning [transforms.parse_json] type remap inputs [app_logs] source . parse_json!(.message) .timestamp parse_timestamp!(.time, format: %Y-%m-%dT%H:%M:%S%.fZ) # 路由 1保持发往旧 Elasticsearch (保障现存 Kibana 报表可用) [sinks.legacy_elasticsearch] type elasticsearch inputs [parse_json] endpoints [http://elasticsearch-old.internal.net:9200] mode bulk index app-logs-%Y.%m.%d # 路由 2旁路复制发往 OpenTelemetry 统一分析层 (灰度验证) [sinks.new_otel_collector] type vector inputs [parse_json] address otel-collector.internal.net:6000 version 2第二阶段链路追踪 Trace Context 的跨协议兼容在旧系统中团队可能使用了 SkyWalking 或 Zipkin 的 Header 格式如sw8而新 OpenTelemetry 遵循 W3C 规范traceparent。一旦强切分布式链路必然断裂。解决方案OpenTelemetry Collector 跨协议转换配置 OpenTelemetry Collector 兼容层同时接收旧版 Zipkin/SkyWalking 协议并自动将其转换为标准 OpenTelemetry 语义# otel-collector-config.yaml receivers: zipkin: endpoint: 0.0.0.0:9411 otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: batch: timeout: 1s send_batch_size: 1024 memory_limiter: check_interval: 1s limit_percentage: 75 spike_limit_percentage: 20 exporters: clickhouse: endpoint: tcp://clickhouse.internal.net:9000?databaseotlp ttl: 720h service: pipelines: traces: receivers: [otlp, zipkin] processors: [memory_limiter, batch] exporters: [clickhouse]第三阶段存储切割与数据一致性校验在双写运行 2 周后必须验证新旧平台的数据一致性避免因为 Vector 提取正则错误导致日志字段缺失。现场诊断利用命令行校验新旧集群数据量偏离# 1. 查询旧 Elasticsearch 中过去 1 小时的日志条数 curl -s -X POST http://elasticsearch-old.internal.net:9200/app-logs-*/_count \ -H Content-Type: application/json \ -d { query: { range: { timestamp: { gte: now-1h } } } } | jq .count # 2. 查询新 ClickHouse 中同时间段的日志条数 clickhouse-client --host clickhouse.internal.net --query \ SELECT count() FROM otlp.logs WHERE Timestamp now() - INTERVAL 1 HOUR对比两个结果时还要统一时间窗口、重试语义和去重规则。可接受偏差应由日志等级、业务用途和链路特性决定不能用一个固定数字替代判断。迁移全流程的排障极简指南当迁移过程中遇到日志延迟增大的情况按以下优先级定位# 1. 检查 Vector 采集器是否有 Disk Buffer 堆积 (排查下游限制) vector top --endpoint http://127.0.0.1:8686 # 2. 检查 OpenTelemetry Collector 内存与 Backpressure (反压) 指标 curl -s http://otel-collector.internal.net:8888/metrics | grep otelcol_processor_refused_spans # 3. 查看旧 ES 集群是否正在发生拒绝写入 (429 Too Many Requests) curl -s http://elasticsearch-old.internal.net:9200/_nodes/stats/thread_pool | \ jq .nodes[].thread_pool.write | {active, queue, rejected}旧系统迁移的三大硬卡点法则前期尽量不改业务日志格式采集器和解析规则的变化应能独立回退。按服务和日志类型灰度并同时观察吞吐、积压、字段完整性和查询体验。新链路稳定后再设置旧数据的保留和下线计划保留期应满足审计与排障需要。