Logstash 对接 Kafka，在写入ES的时候，报错：Will Retry with exponential backoff {:code=＞400

[2022-05-12T15:09:13,065][ERROR][logstash.outputs.elasticsearch][unreasonable_use_kafka][d2128c0736a801fa462a2aea862c6bbf3923c3cce59e00fc70fa6e234d9dac33] Encountered a retryable error. Will Retry with exponential backoff  {:code=>400, :url=>"http://192.168.1.1:9111/_bulk"}
[2022-05-12T15:09:17,300][ERROR][logstash.outputs.elasticsearch][unreasonable_use_kafka][d2128c0736a801fa462a2aea862c6bbf3923c3cce59e00fc70fa6e234d9dac33] Encountered a retryable error. Will Retry with exponential backoff  {:code=>400, :url=>"http://192.168.1.1:9111/_bulk"}
[2022-05-12T15:09:25,525][ERROR][logstash.outputs.elasticsearch][unreasonable_use_kafka][d2128c0736a801fa462a2aea862c6bbf3923c3cce59e00fc70fa6e234d9dac33] Encountered a retryable error. Will Retry with exponential backoff  {:code=>400, :url=>"http://192.168.1.1:9111/_bulk"}
[2022-05-12T15:09:41,756][ERROR][logstash.outputs.elasticsearch][unreasonable_use_kafka][d2128c0736a801fa462a2aea862c6bbf3923c3cce59e00fc70fa6e234d9dac33] Encountered a retryable error. Will Retry with exponential backoff  {:code=>400, :url=>"http://192.168.1.1:9111/_bulk"}
[2022-05-12T15:10:14,027][ERROR][logstash.outputs.elasticsearch][unreasonable_use_kafka][d2128c0736a801fa462a2aea862c6bbf3923c3cce59e00fc70fa6e234d9dac33] Encountered a retryable error. Will Retry with exponential backoff  {:code=>400, :url=>"http://192.168.1.1:9111/_bulk"}

排查过程：
首先，我以为是ES master 节点挂了，检查后，发现没问题。
然后，百度，有很多说是索引别名问题导致的。
比如：https://elasticsearch.cn/question/9776
https://elasticsearch.cn/?/question/9054
然后，我就查询自己索引在ES里面是否有别名，发现没有。

经过这么几番，我怀疑是kafka刷取的数据量太大导致的。
查看logstash-plain.log发现，会打印kafka参数：

参数中，我注意到以下配置：

	fetch.max.bytes = 52428800
	fetch.max.wait.ms = 500
	fetch.min.bytes = 1
	max.poll.interval.ms = 300000
	max.poll.records = 500
	metadata.max.age.ms = 300000

百度查询这些参数的含义：

		auto.commit.interval.ms = 5000
        auto.offset.reset = latest
        bootstrap.servers = [testserver7:9092, testserver5:9092, testserver4:9092]
 
        check.crcs = true 
        自动检查CRC32记录的消耗
        
        client.id = 
        用户设定，用于跟踪记录消息，默认""
        一个ID字符串，在发出请求时传递给服务器。这样做的目的是为了能够跟踪请求的来源，而不仅仅是ip/port，允许在服务器端的请求记录中包含一个逻辑应用的名称。
        Type:	string
        Default:	""
        Valid Values:	
        Importance:	medium
        
 
        connections.max.idle.ms = 540000
        在此配置指定的毫秒数之后关闭空闲连接
        
        default.api.timeout.ms = 60000    
        指定客户端api超时时间(以毫秒为单位)。此配置用作未指定超时参数的所有客户端操作的默认超时。
 
        enable.auto.commit = true
 
        exclude.internal.topics = true
        Kafka 中有两个内部的主题： __consumer_offsets 和 __transaction_state。exclude.internal.topics 用来指定 Kafka 中的内部主题是否可以向消费者公开，默认值为 true。如果设置为 true，那么只能使用 subscribe(Collection)的方式而不能使用 subscribe(Pattern)的方式来订阅内部主题，设置为 false 则没有这个限制。
 
        fetch.max.bytes = 52428800
        该参数与 fetch.min.bytes 参数对应，它用来配置 Consumer 在一次拉取请求中从Kafka中拉取的最大数据量，默认值为52428800（B），也就是50MB。
        如果这个参数设置的值比任何一条写入 Kafka 中的消息要小，那么会不会造成无法消费呢？该参数设定的不是绝对的最大值，如果在第一个非空分区中拉取的第一条消息大于该值，那么该消息将仍然返回，以确保消费者继续工作。Kafka 中所能接收的最大消息的大小通过服务端参数 message.max.bytes（对应于主题端参数 max.message.bytes）来设置
 
        fetch.max.wait.ms = 500
        这个参数也和 fetch.min.bytes 参数有关，如果 Kafka 仅仅参考 fetch.min.bytes 参数的要求，那么有可能会一直阻塞等待而无法发送响应给 Consumer，显然这是不合理的。fetch.max.wait.ms 参数用于指定 Kafka 的等待时间，默认值为500（ms）。如果 Kafka 中没有足够多的消息而满足不了 fetch.min.bytes 参数的要求，那么最终会等待500ms。这个参数的设定和 Consumer 与 Kafka 之间的延迟也有关系，如果业务应用对延迟敏感，那么可以适当调小这个参数.
 
        fetch.min.bytes = 1
 
        group.id = console-consumer-51256
        heartbeat.interval.ms = 3000
 
        interceptor.classes = []
        拦截器，可以在生产端和消费端拦截。统计前后消耗时间等
 
        internal.leave.group.on.close = true
 
        isolation.level = read_uncommitted
        key.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer
        max.partition.fetch.bytes = 1048576
        服务器将返回的每个分区的最大数据量。记录由使用者批量获取。如果fetch的第一个非空分区中的第一个记录批处理大于这个限制，该批处理仍然会被返回，以确保消费者可以取得进展。代理接受的最大记录批大小是通过message.max.bytes(代理配置)或max.message.bytes(主题配置)定义的。请参见fetch.max.bytes限制消费者请求的大小。
 
        max.poll.interval.ms = 300000
        max.poll.records = 500
        metadata.max.age.ms = 300000
        metadata.max.age.ms 这个参数,元数据有效期毫秒值5601000(5分钟)
        这个参数用来配置元数据的过期时间，默认值为300000 ( ms ），即5 分钟。如果元数据在
        此参数所限定的时间范围内没有进行更新，则会被强制更新，即使没有任何分区变化或有新的
        broker 加入。。
 
        metric.reporters = []
        重要性：低
        类型：List
        默认值：Collections.emptyList()
        被作为metrics reporter的类的列表，这些类都实现了接口org.apache.kafka.common.metrics.MetricsReporter，因此当有新的metric生成时，这些reporters类都可以接收到通知。通常都会包含JmxReporter类，以用于注册JMX统计。
        JMX（Java Management Extensions）
        kafka使用jmx调取kafka broker的内部数据，来监控一些敏感的数据。
 
        metrics.num.samples = 2
        重要性：低
        类型：int
        默认值：2
        维护用于计算度量metrics的样本数量。
 
        metrics.recording.level = INFO
        metrics.sample.window.ms = 30000
        重要性：低
        类型：Long
        默认值：30000毫秒，即30秒
        计算度量样本的时间窗口，度量用于kafka监控
 
        partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor]
        轮询策略设置
        partition.assignment.strategy=org.apache.kafka.clients.consumer.RoundRobinAssignor
        范围策略设置
        partition.assignment.strategy=org.apache.kafka.clients.consumer.RangeAssignor
        简单来说就是要配置全路径类名，否则没用
 
        receive.buffer.bytes = 65536
        socket的接收缓存空间大小
 
        reconnect.backoff.max.ms = 1000
        重新连接到多次连接失败的代理时等待的最大时间(以毫秒为单位)。如果提供，每一个连续的连接失败，每个主机的回退将呈指数增长，直到这个最大值。在计算回退增加后，添加20%的随机抖动以避免连接风暴。
 
        reconnect.backoff.ms = 50
        在尝试重新连接到给定主机之前等待的基本时间。这样可以避免在紧密循环中重复连接到主机。此回退适用于客户端对代理的所有连接尝试。
       

于是，我把logstash配置file方式，读取数据，看看能否正常存入。
发现，读取file，8条数据，可以正常刷入ES。

于是，断定，确实是kafka数据太多，每次推送的bulk数据太多，导致的报错。

然后，我修改了logstash input kafka的配置如下：
9个线程，每次拉取90条消息，最大数据大小是5M

input{
  kafka{
    bootstrap_servers =>["1.1.1.1:1111,2.2.2.2:2222,3.3.3.3:3333"]
    group_id => "a_topic_group"
    auto_offset_reset => "latest"
	fetch_max_bytes => 5242880
	max_poll_records => 90
    consumer_threads => 9
    decorate_events => true
    topics => ["a_topic"]
    type => "default"
	codec => plain { charset => "UTF-8" }
  }
}

经过这么修改后，数据可以正常进入ES了。