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

问题描述

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

我的问题是日志行显然被遗漏了（Kibana 显示没有来自该日志的数据的时段，即使我可以看到系统中的活动）并且当前数据也需要很长时间才能出现在 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

我还可以看到，即使我只监视这个文件，也经常有许多“打开的文件”和正在运行的收割机：

{
    "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 中看到一波又一波的活动，表明它经历了一波又一波的发送事件，然后是长时间的无所事事：

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

在试图弄清楚发生了什么时，我读到了这个：

Filebeat 在将数据发送到 Logstash 或 Elasticsearch 时使用背压敏感协议来处理大量数据。如果 Logstash 忙于处理数据，它会让 Filebeat 知道减慢其读取速度。一旦拥塞得到解决，Filebeat 将恢复到原来的速度并继续发货。

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

标签： logstashfilebeat

在撰写本文时，Filebeat 或 Logstash 中没有具体的日志记录，这清楚地表明存在“背压”或它来自何处。正如一些讨论论坛所建议的那样，您需要做的是单独运行每个组件以对性能进行基准测试。

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

在我的具体情况下，它是 Logstash 管道配置和弹性搜索数据节点上内存碰撞的混合，以解决我的摄取问题。

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

问题描述

解决方案

推荐阅读