【问题标题】:Losing messages between logstash and elasticsearch在 logstash 和 elasticsearch 之间丢失消息
【发布时间】:2017-02-14 04:38:24
【问题描述】:

在我们测试 ESK 堆栈并了解这一切的工作原理时,我的设置如下:

  • 运行 filebeat 的客户端服务器 (CS) 将输出发送到在站点聚合器节点 (AN) 上运行的 logstash。

  • AN 使用一些过滤器运行 logstash,然后转发到我们的 Elasticsearch/Kibana 节点 (ESK) 上的 rabbitmq。

  • ESK 运行 rabbitmq,logstash 从 rabbitmq 中提取消息,然后将输出发送到 elasticsearch(不进行过滤)。 Kibana 是我们的可视化工具(显然),而且我们对 elasticsearch 还很陌生,所以我们没有直接用它做太多事情。

问题来了:

CS 生成一条消息。它肯定会被发送到 AN,logstash 将其过滤并转发(在将其回显到 logstash.stdout 之后)。 ESK 上的 logstash 实例也会看到它(并将其写入 logstash.stdout)。我可以在两个 logstash 实例中看到消息。它们匹配并被适当地标记。但它们在 Kibana 中不可见。

我们的配置和来自两个日志的示例消息都在此处的要点形式:https://gist.github.com/wortmanb/ebd37b8bea278d06ffa058c1513ef940

这些消息会去哪里?它们没有出现在 Kibana 中——如果我过滤带有标签的消息:“puppet”,在我知道这些消息正在流动的时间范围内,我基本上什么也得不到。

有什么调试建议吗?

【问题讨论】:

  • 您在 Elasticsearch 中看到您的日志了吗?您可以将手放在 Elasticsearch 中未索引的日志上吗?
  • 是的 - puppetserver 日志消息没有进入那里。好吧,更重要的是,那些被标记为“_grokparsefailure”的正在进入。我成功解析的那些不是。我们偶尔会遇到无法解析的多行堆栈转储——我还没有处理过这些。我通过在 Kibana 中搜索来源:“/var/log/puppetlabs/puppetserver/puppetserver.log”找到了这些。
  • 就你的架构,你真的需要rabbitmq吗?您可以直接将您的日志从聚合器节点 (AN) 的 logstash 传输到 Elasticsearch/Kibana 节点 (ESK) 的 ES。或者,可能存在此处未详细说明的约束强制此架构。

标签: elasticsearch logstash kibana


【解决方案1】:

问题是您正在使用日期过滤器解析日志的日期,默认情况下,替换用于根据日期进行过滤的@timestamp 字段。

当我知道这些消息正在流动时,我基本上什么也没得到。

因此,消息不在它们流动的时间范围内,而是在它们被写入的时间范围内。

您可以看到“_grokparsefailure”日志,因为它们的日期没有被解析,那么@timestamp是Logstash中的接收日期。

因此,您需要将时间范围更改为包括日志日期在内的时间范围。

【讨论】:

  • 我已将时间范围设置为包含这些时间戳,但仍然看不到它们。我使用了“过去 2 周”的时间范围,但没有看到任何内容。我并不是说你错了——有没有办法转储我所有的数据并基本上重新开始,这样我的所有实验都不会妨碍我?幸运的是,这是一个测试环境,所以我可以肆无忌惮地肆虐。
  • @Bret 太糟糕了,它不起作用,我确定是这个问题,因为我已经遇到过它并且非常相似。我有另一个想法,在您的日期过滤器中,您正在使用此模式yyyy-dd-mm ...,我认为应该是yyyy-mm-dd,从您的示例中查看此日期:2016-10-05 15:32:18,038
  • @Bret 如果不是这样,要删除所有数据,您可以使用 kopf 之类的 ES 插件并删除所有索引。或者您可以使用 curl 并执行 curl -XDELETE [url to your ES]/_all。它将删除您的所有数据,包括任何 Kibana 配置。您可以使用curl -XDELETE [url to your ES]/[index name] 逐个删除索引;要检索索引名称,您可以使用curl -XGET [url to your ES]/_cat/indices
  • @Bret 最后一个想法:从这个日期开始:2016-10-05 15:32:18,0382016-10-05T20:32:18.038Z,显然时间已从本地 (UTC -5) 转换为 UTC 时间。因此,由于这种转换,您可能无法在时间范围内找到您的日志。
  • 你说得对——我在模式中确实犯了错误。我昨天在发帖后发现了它并修复了它。事实上,它需要是 yyyy-MM-dd,否则你得到的是几分钟而不是几个月!在清除我的数据之前,我会先查看时区,看看是否涉及到这一点。非常感谢您的帮助!
猜你喜欢
  • 2016-01-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-06-14
  • 2014-08-03
  • 1970-01-01
  • 2021-04-21
  • 1970-01-01
相关资源
最近更新 更多