Wazuh-Filebeat-Elasticsearch非零度量



你能帮我解决这个Filebeat错误吗?

它的Wazuh管理服务器。一切都正常,我可以连接到Kibana网络,进入Wazuh应用程序,我可以在那里看到我的三个Wazuh代理连接并激活。

我想要FIM监控,如果我更改代理服务器上的文件,则会创建警报,并且我可以在manager服务器上的alert.log中看到该警报。问题是,Filebeat不会将此警报发送到弹性搜索,所以我在Kibana网站上看不到该警报。

Wazuh经理>Wazuh 4.2.5文件节拍7.14.2Elasticsearch 7.14.2Kibana 7.14.2

Wazuh警报日志-/var/ossec/logs/alers/2022年2月/和/var/ossec.logs/alers

systemctl状态filebeat处于活动状态,但我可以看到以下行:

WARN [elasticsearch] elasticsearch/client.go:405 Cannot>

这是来自>filebeat-e

2022-02-03T12:46:20.386+0100 INFO [monitoring] log/log.go:153 Total non-zero metrics {"monitoring": {"metrics": {"beat":{"cgroup":{"memory":{"id":"session-248447.scope","mem":{"limit":{"bytes":9223372036854771712},"usage":{"bytes":622415872}}}},"cpu":{"system":{"ticks":70,"time":{"ms":72}},"total":{"ticks":300,"time":{"ms":311},"value":300},"user":{"ticks":230,"time":{"ms":239}}},"handles":{"limit":{"hard":262144,"soft":1024},"open":9},"info":{"ephemeral_id":"641d7fdd-47a0-4b10-bda9-36f29c29fdef","uptime":{"ms":98413},"version":"7.14.2"},"memstats":{"gc_next":18917616,"memory_alloc":14197072,"memory_sys":75383816,"memory_total":71337840,"rss":115638272},"runtime":{"goroutines":11}},"filebeat":{"harvester":{"open_files":0,"running":0}},"libbeat":{"config":{"module":{"running":2,"starts":2},"reloads":1,"scans":1},"output":{"events":{"active":0},"type":"elasticsearch"},"

这是在/var/log/messages 中发现的错误

Feb 3 10:27:54 filebeat[2531915]: 2022-02-03T10:27:54.707+0100#011WARN#011[elasticsearch]#011elasticsearch/client.go:405#011Cannot index event publisher.Event{Content:beat.Event{Timestamp:time.Time{wall:0xc07705e669760167, ext:958857091513, loc:(*time.Location)(0x5620964fb2a0)}, Meta:{"pipeline":"filebeat-7.14.0-wazuh-alerts-pipeline"}, Fields:{"agent":{"ephemeral_id":"33cb9baa-af71-4b44-99a6-1379c747722f","hostname":"xlc","id":"03fb57ca-9940-4886-9e6e-a3b3e635cd35","name":"xlc","type":"filebeat","version":"7.14.0"},"ecs":{"version":"1.10.0"},"event":{"dataset":"wazuh.alerts","module":"wazuh"},"fields":{"index_prefix":"wazuh-monitoring-"},"fileset":{"name":"alerts"},"host":{"name":"xlc"},"input":{"type":"log"},"log":{"file":{"path":"/var/ossec/logs/alerts/alerts.json"},"offset":122695554},"message":"{"timestamp":"2022-02-03T10:27:52.438+0100","rule":{"level":5,"description":"Registry Value Integrity Checksum Changed","id":"750","mitre":{"id":["T1492"],"tactic":["Impact"],"technique":["Stored Data Manipulation"]},"firedtimes":7,"mail":false,"groups":["ossec","syscheck","syscheck_entry_modified","syscheck_registry"],"pci_dss":["11.5"],"gpg13":["4.13"],"gdpr":["II_5.1.f"],"hipaa":["164.312.c.1","164.312.c.2"],"nist_800_53":["SI.7"],"tsc":["PI1.4","PI1.5","CC6.1","CC6.8","CC7.2","CC7.3"]},"agent":{"id":"006","name":"CPP","ip":"10.74.37.3"},"manager":{"name":"xlc"},"id":"1643880472.68132386","full_log":"Registry Value '[x32] HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\W32Time\\Config\\LastKnownGoodTime' modified\nMode: scheduled\nChanged attributes: md5,sha1,sha256\nOld md5sum was: '5df5b1598b729d98734105148103abf2'\nNew md5sum is : '361334bf60bdd83e30894c4f313d16ec'\nOld sha1sum was: 'c233c8ccb56fbd363c44b51a9d51c7fa32512474'\nNew sha1sum is : '7163cffa48f1a7c0bcb4a3ddff6278ae9a4895a6'\nOld sha256sum was: '3aad3da22f2d53e8ac33c46c73f40c3e8f5db07188d166e24957d8a20b62b5f1'\nNew sha256sum is : 'bee8072335d870a1624a541cb13ca5085ba85646a8417d4d894deff71c3f4a92'\n","syscheck":{"path":"HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\W32Time\\Config","mode":"scheduled","arch":"[x32]","value_name":"LastKnownGoodTime","size_after":"8","md5_before":"5df5b1598b729d98734105148103abf2","md5_after":"361334bf60bdd83e30894c4f313d16ec","sha1_before":"c233c8ccb56fbd363c44b51a9d51c7fa32512474","sha1_after":"7163cffa48f1a7c0bcb4a3ddff6278ae9a4895a6","sha256_before":"3aad3da22f2d53e8ac33c46c73f40c3e8f5db07188d166e24957d8a20b62b5f1","sha256_after":"bee8072335d870a1624a541cb13ca5085ba85646a8417d4d894deff71c3f4a92","changed_attributes":["md5","sha1","sha256"],"event":"modified"},"decoder":{"name":"syscheck_registry_value_modified"},"location":"syscheck"}","service":{"type":"wazuh"}}, Private:file.State{Id:"native::1049-64776", PrevId:"", Finished:false, Fileinfo:(*os.fileStat)(0xc000fc9380), Source:"/var/ossec/logs/alerts/alerts.json", Offset:122697450, Timestamp:time.Time{wall:0xc07704f6d4cb3764, ext:510354422, loc:(*time.Location)(0x5620964fb2a0)}, TTL:-1, Type:"log", Meta:map[string]string(nil), FileStateOS:file.StateOS{Inode:0x419, Device:0xfd08}, IdentifierName:"native"}, TimeSeries:false}, Flags:0x1, Cache:publisher.EventCache{m:common.MapStr(nil)}} (status=400): {"type":"illegal_argument_exception","reason":"data_stream [<wazuh-monitoring-{2022.02.03||/d{yyyy.MM.dd|UTC}}>] must not contain the following characters [ , ", *, \, <, |, ,, >, /, ?]"}

你能帮忙吗?我试过谷歌,但没有成功。非常感谢。

Filebeat从alerts.json读取,您可以检查此文件以查看是否正在生成警报。从您提供的日志来看,filebeat似乎无法将一些日志发送到elasticsearch(Cannot index event publisher.Event),但我们需要更多关于完整错误和导致该错误的源日志的详细信息。在这种情况下,命令# journalctl -f -u filebeat的输出将有助于提供进一步的帮助。

基于以往的经验。问题可能是您已经达到了打开碎片的最大限制,默认情况下,这个数字设置为1000。如果是这种情况,您将看到如下错误:{"type":"validation_exception","reason":"Validation Failed: 1: this action would add [2] total shards, but this cluster currently has [1000]/[1000] maximum shards open;"}

如果是这样的话,你可以减少碎片的数量,也可以增加限制来解决现在的问题。如果你只有1个Elasticsearch节点,我推荐第一种方法,在这种情况下,拥有1000个碎片对环境来说是不健康的。

为了减少CCD_ 8中碎片的数量;1〃;,然后重新启动filebeat。从现在起,这些操作将影响索引,但查看本指南可以帮助您处理此类情况。

此外,您可以尝试删除旧索引。我会先检查一下你存储的索引是什么。我想其中一些与统计数据或其他东西有关,所以我会首先尝试在实际数据(wazuh alerts-(之前删除这些

您可以使用:

GET /_cat/indices

由于默认情况下每天存储索引,因此您可以删除,例如,那些超过1个月的索引,而我们只保留一个月的这些索引

为了防止将来发生这种情况,您可以在解决手头的问题后尝试实施索引管理策略。

相关内容

  • 没有找到相关文章

最新更新