Logstash 从 Azure Event Hubs 插件迁移至 Kafka 插件完整实战指南

第一章：架构变革的本质理解

1.1 两种协议路径的底层差异

在开始迁移前，必须理解AMQP 协议 与 Kafka 协议在 Azure Event Hubs 中的根本区别：
现代 Kafka 架构
Kafka Protocol 1.0+
Offset 内部管理
Logstash

kafka插件
Azure Event Hubs

内置Kafka端点
Legacy AMQP 架构
AMQP 1.0
Offset Checkpoint
读取偏移量
Logstash

azure_event_hubs插件
Azure Event Hubs
Azure Blob Storage

外部状态存储

关键认知转变：

Azure Event Hubs 在架构层面实现了"双协议栈"设计：

数据平面：统一的消息存储层（标准层及以上）
协议网关：前端暴露两种访问方式（AMQP 5671端口 / Kafka 9093端口）

这意味着同一组消息数据可以通过不同协议访问，但消费状态（Offset）是协议隔离的。

1.2 为什么要强制迁移？成本与性能的深层逻辑

成本陷阱剖析（GPv1 退役事件）

维度	GPv1 存储	GPv2 存储（强制迁移后）	成本倍数
写入操作费用（每万次）	$0.00036（固定）	$0.050（Hot tier）	139倍
事务特性	简单写入	完整事务支持（但 Logstash 不需要）	过度设计
延迟影响	<10ms	可能更高（默认优化不同）	-

为什么 Azure Event Hubs 插件必须依赖 Blob Storage？

AMQP 协议本身是无状态的。消费者需要在客户端维护消费进度，并通过外部存储定期持久化（Checkpoint）。这就是 storage_connection 存在的根本原因。

而 Kafka 协议内置了消费者组协调机制：

消费者定期向 __consumer_offsets Topic 提交偏移量
由 Kafka Broker（在 Azure Event Hubs 中是服务端托管）负责存储
Zero-cost：已包含在 Event Hubs 定价中

性能瓶颈的根因

Blob Storage Azure Event Hubs Logstash Blob Storage Azure Event Hubs Logstash AMQP 模式（Legacy）每个批次都需同步写入存储 Kafka 模式（目标） Offset 暂存内存后台异步提交获取消息批次返回 125 条消息 PUT Checkpoint（写入Blob）确认 fetch 请求返回消息批次异步提交 Offset

性能差异来源：

AMQP：同步 Checkpoint → 网络RTT × 批次数量
Kafka：批量异步提交 + TCP长连接复用

第二章：迁移前的关键决策与风险评估

2.1 版本兼容性矩阵

在动手前，确认以下版本要求：

组件	最低版本	推荐版本	备注
Logstash	7.6.0	8.11+	旧版本 Kafka 客户端有已知 Bug
logstash-integration-kafka	10.0.0	12.1.0+	需手动升级以获得 `by_duration` 功能
Azure Event Hubs	-	Standard+	Basic 层不支持 Kafka 协议

检查当前插件版本：

bash 复制代码

# 在 Logstash 主机执行
cd /usr/share/logstash
bin/logstash-plugin list --verbose logstash-integration-kafka

2.2 数据重复与丢失风险评估

重要警告：Offset 不兼容

这是迁移中最容易被忽视的风险点：
停止消费
Offset: 无

重置策略: latest
Offset: 无

重置策略: earliest
Legacy Consumer

Offset: 15,000

存储: Blob
切换至Kafka插件
从最新消息开始

可能跳过 15,001~16,000
从最早消息开始

重新处理 1~15,000

决策矩阵：

业务容忍度	推荐策略	配置参数	副作用
零容忍重复	停机迁移 + latest	`auto_offset_reset => "latest"`	切换期间消息可能丢失（窗口期取决于部署时间）
零容忍丢失	并行运行 + earliest	`auto_offset_reset => "earliest"`	切换后重复处理消息（需下游幂等）
平衡方案	时间戳定位	`auto_offset_reset => "by_duration:PT2H"`	需插件 12.1.0+，精确控制回溯窗口

2.3 迁移窗口规划

推荐的双轨并行策略：
2024-01-01 2024-01-01 2024-01-02 2024-01-02 2024-01-03 2024-01-03 2024-01-04 2024-01-04 2024-01-05 2024-01-05 2024-01-06 2024-01-06 2024-01-07 部署Kafka插件配置创建独立Consumer Group 双消费者同时运行监控Lag差异停Legacy插件清理Blob存储准备阶段并行运行切换零停机迁移时间线

第三章：配置迁移详细操作手册

3.1 基础单 Event Hub 迁移

步骤 1：提取现有凭证

从现有配置中提取关键信息：

ruby 复制代码

# 现有配置（待废弃）
input {
  azure_event_hubs {
    event_hub_connections => ["Endpoint=sb://myns.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=abc123=;EntityPath=myhub"]
    storage_connection => "DefaultEndpointsProtocol=https;AccountName=mystorage;AccountKey=xyz789=;EndpointSuffix=core.windows.net"
    consumer_group => "logstash-consumers"
    storage_container => "eventhub-checkpoints"
    checkpoint_interval => 10
  }
}

提取映射表：

原参数	值	Kafka 对应项
`sb://myns...`	Namespace: `myns`	`bootstrap_servers`: `myns.servicebus.windows.net:9093`
`EntityPath=myhub`	Event Hub: `myhub`	`topics`: `["myhub"]`
`SharedAccessKeyName`	`RootManageSharedAccessKey`	JAAS username 始终为 `$ConnectionString`
`SharedAccessKey`	`abc123=`	JAAS password 使用完整连接字符串
`consumer_group`	`logstash-consumers`	`group_id`: `logstash-consumers-kafka`（建议加后缀区分）

步骤 2：创建 JAAS 配置文件

方案 A：独立 JAAS 文件（推荐生产环境）

创建 /etc/logstash/kafka_jaas.conf：

conf 复制代码

KafkaClient {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="$ConnectionString"
    password="Endpoint=sb://myns.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=abc123=;EntityPath=myhub";
};

文件权限加固：

bash 复制代码

sudo chown logstash:logstash /etc/logstash/kafka_jaas.conf
sudo chmod 600 /etc/logstash/kafka_jaas.conf

方案 B：内联配置（开发/测试环境）

ruby 复制代码

input {
  kafka {
    bootstrap_servers => "myns.servicebus.windows.net:9093"
    topics => ["myhub"]
    group_id => "logstash-consumers-kafka"
    security_protocol => "SASL_SSL"
    sasl_mechanism => "PLAIN"
    
    # 注意：密码中包含特殊字符可能需要转义
    sasl_jaas_config => "org.apache.kafka.common.security.plain.PlainLoginModule required username='$ConnectionString' password='Endpoint=sb://myns.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=abc123=;EntityPath=myhub';"
  }
}

步骤 3：完整配置对照

迁移后（Kafka）
bootstrap_servers
命名空间:9093
topics
Event Hub名称数组
group_id
Kafka消费者组
auto_commit_interval_ms
10000毫秒
security_protocol
SASL_SSL
sasl_mechanism
PLAIN
jaas_path
JAAS配置文件
迁移前（AMQP）
event_hub_connections
连接字符串数组
storage_connection
Blob存储账户
consumer_group
AMQP消费者组
checkpoint_interval
10秒写入Blob

完整 Kafka 配置模板：

ruby 复制代码

input {
  kafka {
    # 连接配置
    bootstrap_servers => "myns.servicebus.windows.net:9093"
    topics => ["myhub"]
    group_id => "logstash-consumers-kafka"
    
    # 安全认证
    security_protocol => "SASL_SSL"
    sasl_mechanism => "PLAIN"
    jaas_path => "/etc/logstash/kafka_jaas.conf"
    
    # 性能优化参数（重要）
    consumer_threads => 4
    max_poll_records => "500"
    auto_commit_interval_ms => "5000"
    
    # 初始偏移策略（关键）
    auto_offset_reset => "latest"
    
    # 序列化配置（Event Hubs 默认）
    key_deserializer => "org.apache.kafka.common.serialization.StringDeserializer"
    value_deserializer => "org.apache.kafka.common.serialization.StringDeserializer"
  }
}

3.2 多 Event Hub 高级配置

架构选择决策

方案 A：单一 Input 多 Topics（适合同权限策略）

适用场景：所有 Event Hubs 使用相同的 SAS 策略（Namespace 级别权限）

ruby 复制代码

input {
  kafka {
    bootstrap_servers => "myns.servicebus.windows.net:9093"
    topics => ["hub1", "hub2", "hub3"]
    group_id => "multi-hub-consumer"
    # ... 其他配置
  }
}

限制警告：

所有 Topic 共享相同的 group_id
无法为单个 Hub 设置不同的 auto_offset_reset
如果 Hub2 需要回溯 2 小时，Hub1 需要从 Latest 开始，此方案不适用

方案 B：多 Input 独立配置（推荐）

适用场景：不同 Hub 需要独立的消费组、偏移策略或线程配置

ruby 复制代码

input {
  # Hub 1：日志数据，关注实时性
  kafka {
    id => "kafka_logs_input"
    bootstrap_servers => "myns.servicebus.windows.net:9093"
    topics => ["application-logs"]
    group_id => "logs-consumer"
    auto_offset_reset => "latest"
    consumer_threads => 2
    max_poll_records => "1000"
    # ... 认证配置
  }
  
  # Hub 2：审计数据，不允许丢失
  kafka {
    id => "kafka_audit_input"
    bootstrap_servers => "myns.servicebus.windows.net:9093"
    topics => ["audit-events"]
    group_id => "audit-consumer"
    auto_offset_reset => "earliest"
    consumer_threads => 4
    auto_commit_interval_ms => "1000"  # 更频繁的提交
    # ... 认证配置（如密钥不同，使用不同JAAS文件）
  }
}

Tag 区分策略：

ruby 复制代码

filter {
  if [@metadata][kafka][topic] == "application-logs" {
    mutate { add_tag => ["logs"] }
  } else if [@metadata][kafka][topic] == "audit-events" {
    mutate { add_tag => ["audit"] }
  }
}

3.3 参数深度映射与优化

核心参数对照与调优建议

原 Azure 参数	Kafka 参数	转换公式	优化建议
`checkpoint_interval => 10`	`auto_commit_interval_ms`	值 × 1000	生产环境建议 5000-30000ms。太短：增加 Azure API 调用成本；太长：重复消费风险增加
`threads => 8`	`consumer_threads`	1:1	Kafka 中线程数应与 Event Hub 分区数成比例。最佳实践：线程数 = 分区数
`max_batch_size => 125`	`max_poll_records`	1:1	可增大至 500-1000 以提升吞吐，注意内存消耗
`initial_position => "beginning"`	`auto_offset_reset`	`beginning`→`earliest` `end`→`latest`	迁移时建议先用 `latest`，稳定后如需重新处理历史数据可改为 `earliest`
`decorate_events`	`decorate_events`	同名	建议保持 true，保留 `@metadata` 用于调试

新增关键 Kafka 参数详解

1. session_timeout_ms（默认 10000）

作用：消费者多久不发送心跳会被视为离线
Azure 调优：建议设为 30000（30秒），因为 Event Hubs 网络延迟可能不稳定
关联参数：heartbeat_interval_ms 应设为 session_timeout_ms 的 1/3

2. max_poll_interval_ms（默认 300000）

作用：两次 poll() 调用的最大间隔
重要性：如果 Filter 阶段有复杂处理（如外部 API 查询），需增大此值防止消费者被踢出组

3. fetch_min_bytes & fetch_max_wait_ms

吞吐优化：设置 fetch_min_bytes => "1048576"（1MB）可减少空轮询，提升高吞吐场景效率

高级优化配置示例

ruby 复制代码

input {
  kafka {
    bootstrap_servers => "myns.servicebus.windows.net:9093"
    topics => ["myhub"]
    group_id => "optimized-consumer"
    
    # 认证
    security_protocol => "SASL_SSL"
    sasl_mechanism => "PLAIN"
    jaas_path => "/etc/logstash/kafka_jaas.conf"
    
    # 并行度优化
    consumer_threads => 6  # 假设 Event Hub 有 6 个分区
    
    # 批处理优化
    max_poll_records => "1000"
    max_poll_interval_ms => "600000"  # 10分钟，防止复杂处理超时
    
    # 获取优化
    fetch_min_bytes => "524288"  # 512KB
    fetch_max_wait_ms => "5000"  # 最多等待5秒
    
    # 提交优化
    auto_commit_interval_ms => "30000"  # 30秒提交一次
    
    # 稳定性优化
    session_timeout_ms => "30000"
    heartbeat_interval_ms => "10000"
    
    # 连接重试
    reconnect_backoff_ms => "1000"
    reconnect_backoff_max_ms => "10000"
    
    # 元数据刷新（关键：Event Hubs 分区变化时自动发现）
    metadata_max_age_ms => "300000"  # 5分钟刷新一次元数据
    
    decorate_events => true
  }
}

第四章：代理（Proxy）环境特殊处理

4.1 协议层差异详解

为什么原有代理配置失效？
新方案原生 Kafka
直接TCP
需要
TCP
Logstash
连接拒绝
TCP Layer 4 Proxy

Port 9093
Azure Event Hubs

9093端口
旧方案 AMQP over WebSocket
HTTP CONNECT
TLS
Logstash
HTTPS Proxy

Port 8080
Azure Event Hubs

443端口

根本原因：

AMQP 插件支持 TransportType=AmqpWebSockets，将 AMQP 帧封装在 HTTPS 中
Kafka 协议是二进制 TCP 协议，无法通过 HTTP 代理（不支持 CONNECT 隧道到非 HTTP 端口，或配置复杂）

4.2 Layer 4 代理配置实战

方案 A：DNS 劫持（推荐）

适用于：代理服务器有独立 IP，且可以修改 Logstash 主机的 /etc/hosts

步骤：

代理服务器配置（使用 Nginx Stream 或 HAProxy）：

nginx 复制代码

# /etc/nginx/nginx.conf
stream {
    upstream eventhub_kafka {
        server myns.servicebus.windows.net:9093;
    }
    
    server {
        listen 9093;
        proxy_pass eventhub_kafka;
        proxy_ssl on;
        proxy_ssl_protocols TLSv1.2;
        proxy_ssl_server_name on;
        proxy_ssl_name myns.servicebus.windows.net;
    }
}

Logstash 主机 DNS 覆盖：

bash 复制代码

# /etc/hosts
10.0.0.5  myns.servicebus.windows.net  # 10.0.0.5 是代理服务器IP

Logstash 配置保持不变：

ruby 复制代码

bootstrap_servers => "myns.servicebus.windows.net:9093"  # 实际指向代理

原理说明：

Logstash 尝试连接 myns.servicebus.windows.net:9093
DNS 解析返回代理 IP 10.0.0.5
代理建立到真实 Event Hubs 的 TCP 连接并透传
TLS 握手由 Logstash 直接与服务端完成（证书验证通过，因为目标域名正确）

方案 B：SASL_PLAINTEXT 委托（仅限可信网络）

适用于：代理与 Logstash 在同一安全 VPC/子网，代理负责 TLS 终结

警告：Logstash 到代理的数据未加密，仅在隔离网络使用！

ruby 复制代码

input {
  kafka {
    bootstrap_servers => "10.0.0.5:9093"  # 代理IP
    security_protocol => "SASL_PLAINTEXT"  # 注意：无SSL
    # ... 其他配置
  }
}

代理配置（Envoy 示例）：

yaml 复制代码

static_resources:
  listeners:
  - name: kafka_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 9093 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.sni_dynamic_forward_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.sni_dynamic_forward_proxy.v3.FilterConfig
          port_value: 9093
          dns_cache_config:
            name: dynamic_forward_proxy_cache_config
            dns_lookup_family: V4_ONLY
      - name: envoy.tcp_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
          stat_prefix: kafka_tcp
          cluster: eventhub_cluster
          tunneling_config:
            hostname: myns.servicebus.windows.net:9093
    
  clusters:
  - name: eventhub_cluster
    connect_timeout: 30s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    load_assignment:
      cluster_name: eventhub_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: myns.servicebus.windows.net
                port_value: 9093
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        sni: myns.servicebus.windows.net

4.3 企业防火墙策略申请模板

如果需要通过防火墙申请开放端口，使用以下技术说明：

申请事项： 开放 Logstash 服务器到 Azure Event Hubs 的出站 TCP 连接

目标端点： *.servicebus.windows.net:9093（如果 NSG 支持域名过滤）或具体 IP 范围（见 Azure IP 范围 JSON）

业务理由： 将日志采集从 AMQP 协议迁移至 Kafka 协议，降低存储成本 139 倍，提升吞吐量 2.5 倍

协议特性： 基于 TCP 的二进制协议，使用 TLS 1.2 加密和 SASL/PLAIN 认证

替代方案： 若 9093 无法开放，可考虑通过 Layer 4 代理转发（需额外代理服务器资源）

第五章：性能调优与验证

5.1 基准测试方法

创建测试管道验证性能提升：

ruby 复制代码

# test_performance.conf
input {
  kafka {
    bootstrap_servers => "myns.servicebus.windows.net:9093"
    topics => ["test-hub"]
    group_id => "perf-test"
    security_protocol => "SASL_SSL"
    sasl_mechanism => "PLAIN"
    jaas_path => "/etc/logstash/kafka_jaas.conf"
    
    # 测试不同配置
    consumer_threads => 4
    max_poll_records => "500"
    
    # 关键：监控指标输出
    decorate_events => true
  }
}

filter {
  # 模拟轻度处理
  ruby {
    code => "event.set('processed_at', Time.now.to_f)"
  }
}

output {
  # 输出到 null 以测试纯摄入性能
  stdout { codec => dots }
  
  # 或发送到 monitoring
  # elasticsearch { ... }
}

测试执行：

bash 复制代码

# 1. 预热（5分钟）
sudo /usr/share/logstash/bin/logstash -f test_performance.conf --config.test_and_exit

# 2. 正式测试，监控吞吐量
sudo /usr/share/logstash/bin/logstash -f test_performance.conf 2>&1 | pv -l -i 5 -r > /dev/null

# 3. 使用 JMX 监控 JVM 指标（另一个终端）
jconsole  # 连接到 Logstash 进程

5.2 关键监控指标

通过 Logstash Monitoring API 或 Metrics 插件采集：

ruby 复制代码

# 启用 JMX 和 Monitoring
# logstash.yml
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.hosts: ["http://es:9200"]

需要关注的指标：

指标	获取方式	健康阈值	优化动作
Kafka Consumer Lag	JMX: `kafka.consumer:type=consumer-fetch-manager-metrics`	< 1000	Lag 持续增长：增加 consumer_threads 或优化处理逻辑
Poll 延迟	Logstash `@metadata[kafka][poll_time]`	< 100ms	延迟高：减少 max_poll_records 或检查网络
处理速率	`in` - `filtered`	稳定	波动大：检查 GC 或线程竞争
重平衡频率	Logs 中 "rebalance started"	< 1次/小时	频繁重平衡：增加 session_timeout_ms，减少 consumer_threads

5.3 常见问题诊断

问题 1：连接超时 `TimeoutException`

症状：

复制代码

[ERROR][org.apache.kafka.clients.NetworkClient] Connection to node -1 timed out

诊断流程：
否
是
否
是
否
是
连接超时
能否 telnet

9093 端口?
防火墙/NSG 阻断
DNS 解析正确?
检查 /etc/hosts

或 DNS 配置
JAAS 配置正确?
检查密码转义

特殊字符需转义
检查 Event Hubs

是否为 Standard+ 层

特殊字符处理：

如果 SAS Key 包含 ; 或 =，在 JAAS 文件中需要原样保留，但在内联配置中可能需要转义。

问题 2：认证失败 `SaslAuthenticationException`

症状：

复制代码

[SaslAuthenticator] Failed to authenticate

排查清单：

确认 username 必须是字符串 $ConnectionString（不是变量，是实际文本）
确认 password 是完整连接字符串，不只是密钥部分
确认连接字符串中的 EntityPath 与 topics 参数匹配
检查 Event Hubs 命名空间是否在 Standard 或 Premium 层

问题 3：消费者组重平衡风暴

症状：

日志频繁出现 Rebalance started 和 Rebalance completed，消费停滞。

根因：

session_timeout_ms 太短，处理延迟导致超时
max_poll_interval_ms 被超过（处理逻辑太慢）

解决方案：

ruby 复制代码

kafka {
  # 延长超时
  session_timeout_ms => "45000"      # 45秒
  heartbeat_interval_ms => "15000"   # 15秒（1/3 of session）
  max_poll_interval_ms => "600000"   # 10分钟
  
  # 减少批次大小，加快处理
  max_poll_records => "100"
  
  # 或增加处理线程
  consumer_threads => 8
}

第六章：迁移后的清理与长期维护

6.1 旧资源清理 checklist

迁移验证成功（建议观察 7 天）后执行：

停止 Legacy Logstash 实例（使用 azure_event_hubs 插件的实例）
删除 Blob Storage Container eventhub-checkpoints（如果是专用 Container）
评估 Storage Account 保留：如果该账户仅用于 Event Hubs Checkpoint，可整体删除
删除旧 Consumer Group：在 Azure Portal > Event Hubs > Consumer groups 中删除 AMQP 消费者组（释放限制额度）
更新文档：修改运维手册，移除 Blob Storage 相关监控告警

6.2 监控告警迁移

旧监控项（可移除）：

Blob Storage 容量增长
Blob Storage 写入操作次数
AMQP 连接延迟

新监控项（需添加）：

yaml 复制代码

# Prometheus 告警规则示例（使用 logstash_exporter）
groups:
  - name: kafka_input_alerts
    rules:
      - alert: KafkaConsumerLagHigh
        expr: logstash_input_kafka_consumer_lag > 10000
        for: 5m
        annotations:
          summary: "Logstash Kafka lag is high"
          
      - alert: KafkaConnectionFailed
        expr: logstash_input_kafka_connection_errors_total > 0
        for: 1m
        annotations:
          summary: "Kafka connection issues detected"

6.3 灾难恢复预案

场景：Kafka 插件故障，需要回滚到 AMQP
Blob Storage Event Hubs Logstash 运维人员 Blob Storage Event Hubs Logstash 运维人员实际上 Offset 不互通建议采用时间戳定位而非精确 Offset 回滚停止 Kafka 插件实例检查 Kafka Consumer Group Lag 确认消费位置手动更新 Blob Checkpoint 指向 Kafka 最后消费的 Offset （需脚本转换 Offset 格式）启动 AMQP 插件实例配置 auto_offset_reset = none （强制从 Checkpoint 读取）

更实际的回滚策略：

由于 Offset 存储不兼容，建议回滚时使用 initial_position => "look_back"（AMQP）或 auto_offset_reset => "by_duration:PT1H"（Kafka），接受少量重复处理而非尝试精确对齐 Offset。

附录：快速参考卡

A. 最小可用配置（MVP）

ruby 复制代码

input {
  kafka {
    bootstrap_servers => "NAMESPACE.servicebus.windows.net:9093"
    topics => ["EVENT_HUB_NAME"]
    group_id => "logstash-consumer"
    security_protocol => "SASL_SSL"
    sasl_mechanism => "PLAIN"
    jaas_path => "/etc/logstash/jaas.conf"
    auto_offset_reset => "latest"  # 或 earliest
  }
}

B. 版本升级命令

bash 复制代码

# 升级 Kafka 插件到最新
cd /usr/share/logstash
sudo bin/logstash-plugin update logstash-integration-kafka

# 安装指定版本（如需 by_duration 功能）
sudo bin/logstash-plugin install --version 12.1.0 logstash-integration-kafka

C. 调试模式启动

bash 复制代码

# 前台启动，DEBUG 级别日志，单线程
sudo /usr/share/logstash/bin/logstash -f pipeline.conf \
  --log.level debug \
  --pipeline.workers 1 \
  --config.debug

Logstash 从 Azure Event Hubs 插件迁移至 Kafka 插件完整实战指南

第一章：架构变革的本质理解

1.1 两种协议路径的底层差异

1.2 为什么要强制迁移？成本与性能的深层逻辑

成本陷阱剖析（GPv1 退役事件）

性能瓶颈的根因

第二章：迁移前的关键决策与风险评估

2.1 版本兼容性矩阵

2.2 数据重复与丢失风险评估

2.3 迁移窗口规划

第三章：配置迁移详细操作手册

3.1 基础单 Event Hub 迁移

步骤 1：提取现有凭证

步骤 2：创建 JAAS 配置文件

步骤 3：完整配置对照

3.2 多 Event Hub 高级配置

架构选择决策

3.3 参数深度映射与优化

核心参数对照与调优建议

新增关键 Kafka 参数详解

高级优化配置示例

第四章：代理（Proxy）环境特殊处理

4.1 协议层差异详解

4.2 Layer 4 代理配置实战

方案 A：DNS 劫持（推荐）

方案 B：SASL_PLAINTEXT 委托（仅限可信网络）

4.3 企业防火墙策略申请模板

第五章：性能调优与验证

5.1 基准测试方法

5.2 关键监控指标

5.3 常见问题诊断

问题 1：连接超时 TimeoutException

问题 2：认证失败 SaslAuthenticationException

问题 3：消费者组重平衡风暴

第六章：迁移后的清理与长期维护

6.1 旧资源清理 checklist

6.2 监控告警迁移

6.3 灾难恢复预案

附录：快速参考卡

A. 最小可用配置（MVP）

B. 版本升级命令

C. 调试模式启动

问题 1：连接超时 `TimeoutException`

问题 2：认证失败 `SaslAuthenticationException`