[LogStash] Logstash marcando la URL como resolución de problemas inactiva

Original: https://www.cnblogs.com/liang1101/p/8509978.html

El problema específico se muestra en la siguiente figura:

La información INFO se imprime de la siguiente manera:

[2018-03-05T16:26:08,711][INFO ][logstash.setting.writabledirectory] Creating directory {
    
    :setting=>"path.queue", :path=>"/usr/share/logstash/data/queue"} <br>[2018-03-05T16:26:08,727][INFO ][logstash.agent ] No persistent UUID file found. Generating new UUID {
    
    :uuid=>"f4d5f9a9-42ca-4765-b3fb-0f4566f440df", :path=>"/usr/share/logstash/data/uuid"}
[2018-03-05T16:26:09,175][INFO ][logstash.outputs.elasticsearch] Elasticsearch pool URLs updated {
    
    :changes=>{
    
    :removed=>[], :added=>[http://logstash_system:xxxxxx@localhost:9200/_xpack/monitoring/?system_id=logstash&system_api_version=2&interval=1s]}} <br>[2018-03-05T16:26:09,176][INFO ][logstash.outputs.elasticsearch] Running health check to see if an Elasticsearch connection is working {
    
    :healthcheck_url=>http://logstash_system:xxxxxx@localhost:9200/, :path=>"/"} <br>[2018-03-05T16:26:09,262][WARN ][logstash.outputs.elasticsearch] Attempted to resurrect connection to dead ES instance, but got an error. {
    
    :url=>#<URI::HTTP:0x59e42e4f URL:http://logstash_system:xxxxxx@localhost:9200/_xpack/monitoring/?system_id=logstash&system_api_version=2&interval=1s>, :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch Unreachable: [http://logstash_system:xxxxxx@localhost:9200/][Manticore::SocketException] Connection refused (Connection refused)"}

En primer lugar, se puede ver en el registro que es posible que se haya escrito hasta la muerte, es decir, que no se pueden escribir más datos. En este caso, es natural pensar en la escritura de datos de logstash que limitan la corriente, logstash-5.4.1/config/logstash.ymlmodificación de la configuración :

Reducir el número de trabajadores en la tubería,由原来的 32 -> 16， batch size 修改 1000 -> 500， delay 修改 200 -> 1000， output.workers: 16 -> 8

Después de la modificación, reinicié logstash y descubrí que habrá registros correspondientes después de un período de tiempo. Después de buscar durante mucho tiempo, finalmente encontré un extranjero en Google que puede verse afectado por la verificación de seguridad realizada por xpack. Vi que los registros en realidad correspondían cada 1s. Haga una verificación de estado en es, así que agregue una línea en logstash.yml:

xpack.monitoring.enabled: false

Es decir, después de eliminar el monitoreo de xpack, reiniciar logstash y observar por un período de tiempo, no habrá más registros WARN y ERROR, y el problema está resuelto.

para resumir

Supongo que esto es un problema con xpack, porque hace ping al estado es cada 1s. Cuando el clúster está ocupado, es fácil provocar un tiempo de espera. En este momento, logstash cree que es inalcanzable y seguirá sondeando y esperando. Elimine la supervisión de la verificación de helth de xpack, etc., y juzgue cuando logstash escriba por sí mismo.

【2018-03-06 18:08:56 registro】

Ayer, terminé la modificación. Descubrí que todavía existen los registros anormales mencionados anteriormente después de verificar hoy, así que continué verificando. La carga y cpu del correspondiente servidor logstash y ElasticSearch no son demasiado elevadas, inicialmente se sospecha que puede ser un problema io, es decir, la interacción io es muy frecuente.

Al verificar el registro, descubrí que el error de "enviar una solicitud masiva a elasticsearch" se solicitó repetidamente durante mucho tiempo, lo que significa que logstash envía de forma constante y rápida solicitudes masivas a ES. Comprobamos la configuración de logstash y encontramos que la configuración predeterminada es:

# How many events to retrieve from inputs
pipeline.batch.size: 125
# milliseconds
pipeline.batch.delay: 5

Y mi configuración actual es:

pipeline:
  workers: 32
  batch:
    size: 200
    delay: 100
  output:
    workers: 8
  unsafe_shutdown: false

queue:
  type: persisted
  page_capacity: 250mb
  max_events: 10000
  max_bytes: 1gb
  checkpoint:
    acks: 10000
    writes: 10000
    interval: 1000

La unidad aquí es milisegundos, es decir, para cada instancia de logstash, se enviarán 200 solicitudes al clúster de ES cada 100 milisegundos, lo que provocará que la red io del clúster de ES se sobrecargue.

Entonces, ¿significa que tenemos que aumentar el intervalo entre cada lote y aumentar el tamaño de cada lote? Por ejemplo, batch.size = 500, batch.delay = 500, ¿se pueden prevenir los problemas anteriores?

Esto es factible después de la prueba.

Debido a la limitación de max_bytes y max_events configurados a continuación, la configuración modificada es la siguiente (solo como referencia):

pipeline:
  workers: 16
  batch:
    size: 500
    delay: 200
  output:
    workers: 12
  unsafe_shutdown: false

queue:
  type: persisted
  page_capacity: 250mb
  max_events: 10000
  max_bytes: 1gb
  checkpoint:
    acks: 10000
    writes: 10000
    interval: 1000

Hay varios propósitos para esta configuración:

1. Intente leer la mayor parte de datos posible a la vez, para minimizar la interacción IO con ES.

2. El intervalo no puede ser demasiado largo. Al comienzo de la configuración de 1000, se encuentra que el error se reduce a 500 y el error se reduce. El análisis encontró que el intervalo debería ser más largo, y los datos bloqueados por logstash en la cola aumentarán, lo que conducirá a la frecuencia de lectura Nunca disminuirá, especialmente después de un período de tiempo, se encuentra que algunos de los retrasos en la recolección con una cantidad relativamente grande de calidad solar se vuelven mayores. Por lo tanto, el tiempo de retraso se revisa a 200 después de una consideración exhaustiva.

3. Dado que el número de núcleos de CPU supera los 40, el número de subprocesos de output.workers aumenta para mejorar la capacidad de procesamiento, reducir la congestión de datos y reducir la latencia.

Finalmente, para resumir :, 以上报错信息其实并不影响整体日志收集，这个错误只是 logstash 自己认为可能不可达es causado por los componentes en él. Verifique la declaración en github. La última versión del seguimiento puede resolver este problema de falso positivo, pero no significa que lo ignoremos.而是要想办法将这个错误频次降低，尽最大可能使其运行良好。

【2018-05-06 10:18:56 grabar】

Durante este período, se resolverá el problema de que ELK recopile registros que faltan registros. La razón principal es la configuración irrazonable. El motivo del problema es que el tiempo de espera inalcanzable en el filebeat configurado es: 3 min. Si la congestión de logstash es grave en el medio y la carga de elasticsearch es alta, puede hacer que filebeat se suspenda durante más de 3 min. Consulte la última versión de filebeat de forma predeterminada durante 1 día. De hecho, La configuración es razonable, aunque un poco grande, es mejor que perder datos. Después de aumentar la configuración a 1h, no habrá pérdida de registro.

Resolvió el problema del retraso relativamente alto de la recopilación de registros de ELK. Probé muchas optimizaciones y descubrí que no se podía resolver fundamentalmente, por lo que los nginx_log y push_log más intensivos en recursos se migraron a sus respectivos clústeres pequeños, y todos los demás registros permanecieron en el En el clúster, se han resuelto varios problemas desde entonces. Se reduce a una frase:有多大能力就干多大的事，不要超过其最大承受能力。