我几次在邮件列表上看到过这个问题，但没有得到满意的答案。
如何最好地监控pipe道是否卡住？ 客户端 – > logstash – > elasticsearch。
Logstash尤其是弹性search容易导致资源匮乏。 当他们离开的时候，他们都是非常棒的，但是看到观察者的人究竟是怎么样的呢？
意见欢迎。
就我个人而言，我实际上检查redis仍然在LS + ES上游的中央日志logging主机上出队。
即： redis-cli llen logstash小于某个固定的数字。
虽然这可能不表示日志显示在redis中，但是也可以检查。
就像检查redis-cli info | grep total_commands_processed redis-cli info | grep total_commands_processed不断增加，也许？
我在我的环境中使用zabbix，但我想这种方法也可以在其他设置中工作。 我configuration了zabbix允许使用的以下命令：
UserParameter=elasticsearch.commits,/usr/bin/curl -s 'localhost:9200/_cat/count?v' | /bin/sed -n '2p' | /bin/awk '{print $3}'
这将返回总共提交的elasticsearchlogging的数量。 所以我把这个数值除以我自上次抽样（我每分钟检查一次）以来的秒数，如果这个数字低于任意的限制，我可以提醒它。 我还使用zabbix来检查logstash PID是否已经死亡，并警告，并运行以下命令：
UserParameter=elasticsearch.health,/usr/bin/curl -s 'http://localhost:9200/_cluster/health?pretty=true' | /bin/sed -n '3p' | /bin/awk -F'\"' '{print $4}' | /bin/sed s/yellow/0/ | /bin/sed s/green/0/ | /bin/sed s/red/1/
如果集群健康已经变红（黄色和绿色都可以），这将返回1，我也可以提醒。
检查您的最terminal点（例如elasticsearch）每秒的日志是否高于某个基线。
也就是说，做一个端到端的检查，如果你的最终结果是正确的，你知道pipe道中的所有步骤都能正常工作。
如果你经常遇到问题，或者需要更好的自省，那么就像上面提到的那样，开始像Redis一样testing每条pipe道。
我们使用几种方法：