Questions tagged «logstash»

logstash是用于收集和分发日志事件的工具。

4
tls握手失败。不包含任何IP SAN
我正在尝试设置logstash转发器,但是在建立适当的安全通道时遇到了问题。尝试使用在virtualbox中运行的两台ubuntu(服务器14.04)计算机进行配置。它们是100%干净的(用于logstash的主机文件不受影响或未安装任何其他软件包,除了必需的Java,ngix,elastisearch等) 我不认为这是logstash问题,但证书的处理不当或在logstash ubuntu或转发器计算机上未正确设置的问题。 我生成了密钥: sudo openssl req -x509 -batch -nodes -newkey rsa:2048 -keyout private/logstash-forwarder.key -out certs/logstash-forwarder.crt 我在logstash服务器上的输入conf: input { lumberjack { port => 5000 type => "logs" ssl_certificate => "/etc/pki/tls/certs/logstash-forwarder.crt" ssl_key => "/etc/pki/tls/private/logstash-forwarder.key" } } 密钥已复制到具有以下配置的转发器主机。 { "network": { "servers": [ "192.168.2.107:5000" ], "timeout": 15, "ssl ca": "/etc/pki/tls/certs/logstash-forwarder.crt" "ssl key": …

2
如何杀死一个永不消亡的进程?
问题 我的Java进程不会因SIGTERM或SIGKILL而死。 logstash 2591 1 99 13:22 ? 00:01:46 /usr/bin/java -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC -Djava.awt.headless=true -Dfile.encoding=UTF-8 -XX:+HeapDumpOnOutOfMemoryError -Xmx1g -Xms256m -Xss2048k -Djffi.boot.library.path=/usr/share/logstash/vendor/jruby/lib/jni -Xbootclasspath/a:/usr/share/logstash/vendor/jruby/lib/jruby.jar -classpath : -Djruby.home=/usr/share/logstash/vendor/jruby -Djruby.lib=/usr/share/logstash/vendor/jruby/lib -Djruby.script=jruby -Djruby.shell=/bin/sh org.jruby.Main --1.9 /usr/share/logstash/lib/bootstrap/environment.rb logstash/runner.rb --path.settings /etc/logstash 每当收到信号时都会重生。 Sep 15 13:22:17 test init: logstash main process (2546) killed by KILL signal Sep …

1
扩展Logstash(使用redis / elasticsearch)
在超过12个centos 5.8服务器的群集上,我使用本机logstash托运人部署了logstash,后者将发/var/log/*/*.log回中央Logstash服务器。 我们尝试使用rsyslogd作为托运人,但是由于rsyslogd的ImFile模块中存在错误,如果远程端不响应,则日志会堆积在内存中。 当前,我们使用Redis作为传输机制,因此logstash01已在本地运行redis,这些日志绑定到VLAN的IP。 因此,logstash-shipper在logstash01上发送到redis。logstash01发送给在单独进程中运行的Elasticsearch。 这就是我们所看到的。Elasticsearch有141个被阻止的线程。跟踪elasticsearch父级显示: futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL 这是来自Elasticsearch的Jstack 这是logstash的jstack 因此,..昨晚,某些Web服务器(日志被logstash拖尾)发疯了,平均负载超过500。 在logstash01上,有这个 Dec 19 00:44:45 logstash01 kernel: [736965.925863] Killed process 23429 (redis-server) total-vm:5493112kB, anon-rss:4248840kB, file-rss:108kB 所以OOM杀手杀死了Redis的服务器,然后指原木堆放在内存里面是已上市的东西..而服务器上莫名其妙意味着阿帕奇获取其短裤的扭曲。(坦率地说,我不确定如何,我只是假设它在拖尾日志)。 这是我关于事件如何发生的理论: 我们的流量高峰。 生成了大量日志。 这些存储在Redis中,因为logstash / elasticsearch似乎每秒只能处理300-400个新事件。 Redis已完全填满,OOM杀手无意识地宰了它。 Redis停止接受新项目。 现在,项目开始在远程主机端堆积。 一切都疯了。Apache停止接受请求。(为什么?)。 问题是: 如果只有日志拖尾,为什么apache会发疯。是因为拖尾的东西阻碍了Apache的写作? 有没有使弹性搜索更快/更好/具有弹性的明智方法? 是否有一种明智的方法可以使Redis具有弹性并且不会因为OOM而死亡 我设置的方式是否存在根本缺陷,还是每个人都有此问题? -编辑- @lusis的一些规格。 admin@log01:/etc/init$ free -m total used …

2
作为服务安装时配置Logstash [关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,以使其成为服务器故障的主题。 5年前关闭。 我已经在Ubuntu 13.10上使用logstash APT存储库将Logstash安装为服务。 现在,我可以运行: dpkg -s logstash 它输出: Package: logstash Status: install ok installed Priority: extra Section: default Installed-Size: 93362 Maintainer: <jls@ds4172> Architecture: all Version: 1.4.0-1-c82dc09 Depends: java7-runtime-headless | java6-runtime-headless | j2re1.7 Conffiles: /etc/default/logstash 399f19c4d762840a36f6bc056c3739b8 /etc/default/logstash-web d94db9f8dc1d4ced449175a96e8df09d /etc/logrotate.d/logstash 9bb11b4b058868bb41c658c9c3152a83 Description: An extensible logging pipeline License: Apache …
12 logstash 

1
logstash(或graylog?)vs nxLog收集事件日志和csv日志
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,以使其成为服务器故障的主题。 5年前关闭。 我目前正在研究使用Logstash(或graylog2)合并来自多个服务器的日志的可能性。 我仍然对logstash和graylog的区别感到困惑。到目前为止,我很欣赏logstash的易用性,但是我想听听其他人的经验。 此外,logstash似乎可以获取Windows事件日志。是否有动机代替使用nxLog或圈套器?许多人报告使用nxlog将事件转发到远程logstash实例。是推荐的方式吗? 目前,我们想从多个方框中进行合并: Windows事件日志 第三方csv文件 预先感谢您的任何反馈。

8
获取logstash版本
如何获得Logstash的版本? root@elk:/usr/share/elasticsearch# bin/logstash --help bash: bin/logstash: No such file or directory 我的系统上正在运行Logstash。也。 root@elk:/# logstash -V bash: logstash: command not found 也。 root@elk:/# ps aux | grep logstash logstash 1725 45.3 8.5 1942860 175936 ? SNl 22:03 0:35 /usr/bin/java -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Djava.awt.headless=true -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -Djava.io.tmpdir=/opt/logstash -Xmx500m -Xss2048k -Djffi.boot.library.path=/opt/logstash/vendor/jruby/lib/jni -XX:+UseParNewGC -XX:+UseConcMarkSweepGC …

2
Logstash无法读取它也应该具有访问权限的文件
我已经使用命令将用户添加logstash到组中。adm$ usermod -a -G adm logstash logstash代理尝试读取的文件之一是/var/log/nginx/foo-access.log,它具有以下权限: -rw-r----- 1 www-data adm 0 Jul 25 07:52 /var/log/nginx/foo-access.log 当我sudo su logstash可以读取文件BUT时,当我$ sudo service logstash_agent restart(init脚本以logstash用户身份运行)时,它将用以下内容填充logstash日志: {:timestamp=>"2013-07-31T17:05:17.287000+0000", :message=>"failed to open /var/log/nginx/foo-access.log: Permission denied - /var/log/nginx/foo-access.log", :level=>:warn} 我可以确认Logstash用户位于adm组中: $ groups logstash logstash : logstash adm 此文件绝对具有正确的文件访问权限: $ getfacl /var/log/nginx/foo-access.log getfacl: Removing leading '/' from …

1
当Logstash尝试写入数据时,Elasticsearch死亡
我有一个Raspberry Pi 2(截至2015年4月的最新Raspbian)安装程序,上周在测试网络上同时运行ElasticSearch和Logstash(不是简单的安装程序,但稳定了一个星期!)。我今天重新启动了机器,在让事情重新运行方面一直非常困难。ES和LS都将独立运行,但是当我尝试将LS输出推入ES时,ES实例死掉了,没有任何解释。我的目标是通过标准输出插件将运行数据和LS数据都泵入ES。 ElasticSearch [v1.5.0] 我相信这是核心问题所在。ES可以通过启动service elasticsearch start并保持运行状态,可以通过HTTP请求访问端口9200进行访问,并且一切正常的迹象似乎很正常。只要某种东西(据我所知,什么都可以)试图将数据写入索引,该进程就会死亡,并且调试日志@ / var / log / elasticsearch / *不包含任何与服务失败相关的信息。我试图通过logstash(请参见下文)以及curl插入,这两者都终止了ES进程。我正在运行的curl命令是curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ \"type\" : \"specialRecord\" }"。 Logstash [v1.4.2] 我目前正在使用此简单配置运行: input { stdin { } } output { stdout { codec => rubydebug } elasticsearch { host => '127.0.0.1' cluster => 'elasticsearch' } …

1
ELK Stack(Logstash,Elasticsearch和Kibana)与并发远程syslog服务器?
我正在构建一个日志分析器服务,以开始主要监视我们的pfSense防火墙,XenServer系统管理程序,FreeBSD / Linux服务器和Windows服务器。 互联网上有很多关于ELK堆栈以及如何使其良好工作的文档。但是我想以其他方式使用它,但是我不知道这是一个好的解决方案还是浪费时间/磁盘空间。 我已经有一台充当远程syslog服务器的FreeBSD 10.2机器,我的想法是将所有日志简单地集中在这台机器上,然后syslog服务器将它们转发logstash-forwarder给ELK服务器。 对我来说很明显,这种方法将提高此设置的磁盘要求,但另一方面,我将只logstash-forwarder安装一台装有守护程序的计算机,这对我来说似乎很好。 但是谈论问题。该logstash分析器匹配[host]与服务器的主机名发送日志消息,并在这种方法只存在对ELK,远程系统日志服务器“服务器”节目的。 我知道我可以自定义logstash配置文件上的设置,但是我不知道(我没有经验),这是否只是解析器上的简单设置,是否会损害整个ELK经验。 最后,我只想对我的日志记录体系结构以及它是否可以工作或者是否应该没有其他选择提供一些建议。 提前致谢,

2
如何配置日志聚合器以认证数据?
背景:远程日志聚合被认为是提高安全性的一种方法。通常,这解决了危害系统的攻击者可以编辑或删除日志以破坏取证分析的风险。我一直在研究通用日志工具中的安全性选项。 但是有些不对劲。我看不到如何配置任何常见的远程记录器(例如rsyslog,syslog-ng,logstash)以验证传入消息确实是来自所声称的主机的。在没有某种策略约束的情况下,一个日志创建者可以代表另一个日志创建者伪造消息。 rsyslog的作者似乎警告要验证日志数据: 最后一个警告:transport-tls保护发送方和接收方之间的连接。它不一定能防御消息本身中存在的攻击。特别是在中继环境中,该消息可能源自恶意系统,该恶意系统将无效的主机名和/或其他内容放入其中。如果没有针对此类情况的配置,则这些记录可能会显示在接收者的存储库中。-transport-tls不能防止这种情况的发生(但是如果正确使用它可能会有所帮助)。请记住,syslog-transport-tls提供了逐跳安全性。它不提供端到端的安全性,并且不对消息本身(仅是最后一个发送者)进行身份验证。 因此,后续问题是:什么是可以提供一定程度真实性的良好/实用配置(在您选择的任何常用日志工具中-rsyslog,syslog-ng,logstash等)? 或者...如果没有人对日志数据进行身份验证,那为什么不呢? - (此外:在讨论/比较中,使用RFC 5424中的某些图表或术语可能会有所帮助:第4.1节:示例部署方案 -例如,“发起者” vs“中继” vs“收集器”)

2
Logstash解析包含多个日志条目的xml文档
我目前正在评估logstash和elasticsearch是否对我们的用例有用。我所拥有的是一个包含多个条目的日志文件,其格式为 <root> <entry> <fieldx>...</fieldx> <fieldy>...</fieldy> <fieldz>...</fieldz> ... <fieldarray> <fielda>...</fielda> <fielda>...</fielda> ... </fieldarray> </entry> <entry> ... </entry> ... <root> 每个entry元素将包含一个日志事件。(如果您有兴趣,该文件实际上是Tempo时间表(Atlassian JIRA插件)工作日志导出。) 是否可以在不编写自己的编解码器的情况下将此类文件转换为多个日志事件?
8 xml  logstash 

4
如何最好地监控logstash?
我已经在邮件列表上看到过几次这个问题,但是没有令人满意的答案。 如何最好地监视管道是否阻塞?客户端-> logstash-> elasticsearch。 Logstash尤其是elasticsearch容易出现资源匮乏的情况。他们俩都擅长从上次停站的地方接站,但是人们究竟是如何观看他们的观看者的呢? 欢迎意见。

1
logstash字段名称中@前缀的含义是什么?
以下logstash配置用于通过TCP连接将Windows事件日志作为json接受,然后经过一些过滤将结果转发到Elastic搜索(源:https : //gist.github.com/robinsmidsrod/4215337): input { tcp { type => "syslog" host => "127.0.0.1" port => 3514 } tcp { type => "eventlog" host => "10.1.1.2" port => 3515 format => 'json' } } # Details at http://cookbook.logstash.net/recipes/syslog-pri/ filter { # Incoming data from rsyslog grok { type => "syslog" pattern …
8 logstash 
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.