如何识别缓慢 Filebeat 摄取的瓶颈

Question

我正在使用 Filebeat 监视单个快速滚动的日志文件。在繁忙的系统时间，文件每隔几秒滚动一次。一旦达到 10mb（在 15k 和 35k 行之间），日志记录配置将设置为滚动。我将 close_timeout 设置为 5m 以防止在日志滚动太快时保留太多打开的文件句柄，因为这可能导致我的磁盘填满，因为滚动的文件无法删除。

我的问题是明显遗漏了日志行（Kibana 显示此日志中没有数据的时间段，即使我可以在系统中看到 activity）并且当前也需要很长时间显示在 Elasticsearch 中的数据（最多 15 分钟）。

这是我的 Filebeat 配置：

- type: log
  enabled: true
  fields:
    company.app: "myapp"
    myapp.logstyle: "myappsql"
  paths:
    # Match paths from any environment this filebeat is running on.
    # There is only a single environment and single file being monitored per filebeat process
    - /apps/myapp/*/runtime/logs/dataserver/myfile.log
  close_inactive: 1m
  close_timeout: 5m
  scan_frequency: 1s

output.logstash:
  hosts: [ "mylogstashhost:5046" ]
  compression_level: 3
  bulk_max_size: 4096
  loadbalance: true
  worker: 10

我在 filebeat 日志中每隔几秒就会看到这条消息：

Closing harvester because close_timeout was reached: /myfile.log

我还可以看到经常有很多 'open files' 和运行收割机，即使我只监视这个文件：

{
    "monitoring": {
        "metrics": {
            "beat":{
                "cpu":{
                    "system":{
                        "ticks":14660,"time":{
                            "ms":20
                        }
                    },"total":{
                        "ticks":84710,"time":{
                            "ms":38
                        },"value":84710
                    },"user":{
                        "ticks":70050,"time":{
                            "ms":18
                        }
                    }
                },"handles":{
                    "limit":{
                        "hard":1048576,"soft":1048576
                    },"open":38
                },"info":{
                    "ephemeral_id":"c885fa62-01b5-4d49-9a80-6acf89058539","uptime":{
                        "ms":1410214
                    }
                },"memstats":{
                    "gc_next":52842240,"memory_alloc":30249872,"memory_total":6000680424
                },"runtime":{
                    "goroutines":282
                }
            },"filebeat":{
                "harvester":{
                    "open_files":15,"running":34
                }
            },"libbeat":{
                "config":{
                    "module":{
                        "running":0
                    }
                },"output":{
                    "read":{
                        "bytes":72
                    }
                },"pipeline":{
                    "clients":2,"events":{
                        "active":4118
                    }
                }
            },"registrar":{
                "states":{
                    "current":1458
                }
            },"system":{
                "load":{
                    "1":0.01,"15":0.12,"5":0.07,"norm":{
                        "1":0.0006,"15":0.0075,"5":0.0044
                    }
                }
            }
        }
    }
}

Elastic Monitoring 统计数据显示有很多打开的句柄，这与上面的日志信息相关联。我还可以在 Elastic Monitoring 中看到 activity 的波浪，表明它经历了发送事件的波浪，然后是长时间无所事事：

最后，我的 logstash 日志只显示标准 INFO 消息。没有关于被淹没的警告。监控显示事件延迟为 12 毫秒，偶尔出现小峰值，这与来自 FileBeat

的事件转储一致

在试图弄清楚发生了什么时，我阅读了 this:

Filebeat uses a backpressure-sensitive protocol when sending data to Logstash or Elasticsearch to account for higher volumes of data. If Logstash is busy crunching data, it lets Filebeat know to slow down its read. Once the congestion is resolved, Filebeat will build back up to its original pace and keep on shippin'.

但是，该页面或我在文档中查看的任何地方都没有解释如何识别是否发生背压。如果不是背压，那么我还能调查什么来确定瓶颈是什么？

Answer 1

在撰写本文时，Filebeat 或 Logstash 中没有具体的日志记录，这清楚地表明存在 'backpressure' 或它来自哪里。正如一些论坛上所建议的那样，您需要做的是运行隔离每个组件以对性能进行基准测试。

将 Filebeat 设置为输出到控制台并将控制台重定向到 /dev/null。然后，您可以使用 filebeat 日志来衡量 Filebeat 处理特定文件所花费的时间。
将 Filebeat 指向 Logstash，并将 Logstash 输出重定向到 /dev/null。同样，监控 filebeat 日志以查看处理需要多长时间。如果此时它很慢，那么您可能需要检查您正在使用的过滤器。如果您有简单的过滤器或没有过滤器，那么可以检查 Logstash 是否 CPU 或内存受限。理想情况下，应该有 little/no 通过 logstash 进行减速处理，而不是将 Filebeat 重定向到 /dev/null
将 Logstash 指向 Elasticsearch，看看性能是否有变化。如果是这样，现在是调整您的 logstash 管道设置、更改批量大小、工作人员数量等的时候了。您可能还需要查看 Elasticsearch 性能，确定您是 CPU/Memory/Network 还是磁盘 I/O 绑定。

在我的具体案例中，它是 Logstash 管道配置和我的 elasticsearch 数据节点上的内存碰撞的组合来解决我的摄取问题。

如何识别缓慢 Filebeat 摄取的瓶颈

How to identify the bottleneck in slow Filebeat ingestion

logstash

filebeat