どうも、みむらです。
某所の監視に Wazuh ( https://wazuh.com/ )をよく使っているのですが
内部的に ElasticSearch OSS 7.10.2 を使っているため、新しすぎる OS 上で動かそうとすると filebeat が下記のように落ちてしまうことがあります
もちろん、この問題は新しいバージョンの Beats では解決されているのですが
他方で 7.13 以降の Beats は OpenSearch 1.x や Elasticsearch OSS などで使えないという問題があります。
この問題については、下記のコメントにあるように elasticsearch 側もアップデートすることが推奨されていますので、公式に解決される可能性は低そうです。
https://github.com/elastic/beats/pull/26305#issuecomment-863472649
枯れたものを使え、公式でサポートしていないディストリビューションを使うな、というのは一理あるのですが、その方法で回避するのは面白くないですので、修正含めてやってみました。
（wazuh のサポートで解決している例が見当たらなかったこともあり、最初だけ英語で併記します。）
注意：
修正は自己責任でお願いします。本番用環境に対して独自ビルドを行ったものを適用したことにより問題が発生しても当方では責任を負えません。
落ちる原因 (Cause)：
“clone3” のシステムコールが seccomp の許可リストに登録されていないため。
en : The systemcall “clone3” is not allowed by seccomp.
glibc 2.34 以降において、 pthread_create() を呼び出す際に clone3 システムコールが用いられるようになったことが原因となっています。
修正方法 (Solution):
libbeat/common/seccomp 以下の “policy_linux_386.go” と “policy_linux_amd64.go” に “clone3” を追記する
en: Add “clone3” to policy_linux_386.go and policy_linux_amd64.go under libbeat/common/seccomp.
具体的な追加内容については、まさしく当該する patch がありますのでこれに従います。
https://github.com/elastic/beats/commit/82507fda20bee46cee4808d388a0c809dd01ff13
また glibc 2.35 以降では “rseq” システムコールも用いるそうですので
こちらも併せて対応しておくとよいと思います。
en: It is a recommend to also add “rseq” to policy_linux_386.go and policy_linux_amd64.go under libbeat/common/seccomp, due to the syscall is used glibc >= 2.35.
https://github.com/elastic/beats/commit/f02fa32e0a37d6529983e2181b80bf62e4a16b41
実際にやってみる
実際に上記のパッチを当てて問題が解決するか確認してみました。
確認環境 : Fedora 36 x86_64
続きを読む