はじめに

KCS 部の島崎です。 KCS部は、KADOKAWAグループ向けプライベートクラウド(以下KCS)を提供しており、主な利用者は株式会社ドワンゴがサービスを提供している『niconico』です。

今回は Auditbeat の導入とその時のつまづきおよび解決策について投稿します。

Auditbeat とは何か

Auditbeat とは Elastic の Beats 系に含まれる監査ログ取得に特化したミドルウェアです。 Linux にはシステムの監査機能として auditd がありますが、以下の理由により Auditbeat を採用しています。

Elasticsearch に送ってログの集約化ができる
Kibana を利用して可視化することができる
Auditbeat は auditd のルールと互換性がある

Elasticsearch を送ってログ集約及び Kibana による可視化については Elasticsearch as a Service のドッグフーディングを兼ねています。

f:id:kdx_writer:20201013134637p:plain

Auditbeat の導入と設定

Auditbeat 自体の導入は各種 OS のバイナリをインストールすることで可能なため詳細は公式ドキュメントに譲ります。また auditbeat setup を実行することにより Auditbeat で事前に定義されたインデックスとダッシュボードをそれぞれ Elasticsearch/Kibana に設定するところまで自動的に行われ、利用することが可能です（事前に Elasticsearch/Kibana との疎通及び認証ができていることが前提です）。

Auditbeat の設定は audit_rule を含めて auditbeat.reference.yml を踏襲したものを採用していますが、送信するイベントのフィルタリングのためプロセッサを追加で設定しています。プロセッサについては「auditbeat の socket の consul が大量にデータを消費する問題と対策」の部分で述べます。

Auditbeat を導入するにあたってのつまづき

Auditbeat を導入するにあたって以下５つのつまづきに直面しました。それぞれ何があったかとその解決策を記載します。

auditd と Auditbeat の干渉

Auditbeat の導入により各種モジュールの記録はみることができましたが auditd のダッシュボードだけデータが存在しない状態でした。Auditbeat のランディングページを確認したところ「お好みであれば、auditdとAuditbeatの両方を使用することもできます」と表記されていたため auditd を一回停止したところ Kibana のダッシュボードで表示されるようになったため結果として auditd が干渉していることが原因として判断しました。

DBaaS for MySQL のインスタンスはすべて CentOS7 (7.3.1611) を利用しています。また CentOS7 では auditd が導入されています。一方で auditd と Auditbeat の併存は「最新のカーネルが必要」とランディングページに明記されていますが、少なくとも DBaaS for MySQL のインスタンスに導入されている CentOS ではできなかったため auditd を止めることにしました。

auditd の停止後 Auditbeat による監査ログの記録が行われ、Kibana のダッシュボードからも確認できるようになりました。

プロセッサ式を間違えると auditbeat が停止する

Auditbeat のプロセッサはイベント処理を制御するには必要な機構です。一方で間違ったプロセッサ式が入った状態でも立ち上げることができてしまうため間違ったプロセッサ式が当たったことが原因で Auditbeat が停止する問題がありました。

対策は後述の auditbeat test config を利用することで、事前に間違いを指摘してくれるため間違った式の設定投入を予防することができます。ただしこれは別の問題に直面しました。

auditbeat test config の問題

Auditbeat には設定が正しいかどうかを確認する auditbeat test config があります。前述のようにプロセッサ式を利用する場合は間違った式が原因で Auditbeat 停止が発生するため特に重要です。しかし、Auditbeat のプロセスが稼働しているところで、 auditbeat test config コマンドを実行すると、コマンドがいつまでも終了せず、稼働していた Auditbeat もハングしてしまう問題がわかりました。

実際に遭遇したケースとして、ansible には validate の機能があり、そこで auditbeat test config 使用していました。しかし、上記の問題のため validate パラメータを削除して事前に設定ファイルを検証する形で対応しています。

Auditbeat の socket 監視で consul が大量にデータを消費する問題と対策

Auditbeat を開発環境にある DBaaS for MySQL の全インスタンスに導入後、1日のログで数十ギガバイト以上を消費する問題がありました。この問題を Kibana のダッシュボードで調査をしたところ Consul の通信が約9割のログ消費をしていることが発覚しました。

DBaaS for MySQL では個々のインスタンスに構成管理目的で Consul を導入しています。Consul はサービスディスカバリのために個々のノードと相互に通信することからインスタンス数に応じて増え、結果として Auditbeat で記録されるソケット通信のトップが Consul になっていました。 Auditbeat の仕様としてどこからどこに通信したかをソケットによる通信単位で記録するため莫大な量のログによるディスクが消費される結果になりました。

Consul 内部の相互通信は記録する必要はなく、むしろ検索に時間がかかる要因になるため記録対象から外すことにしました。記録対象の除外は Auditbeat のプロセッサ機能のひとつである drop_event を使うことでイベント送信する前に破棄する（＝記録しない）かどうかを制御できます。

# ソケット通信のユーザ ID が consul である場合は記録を除外する
processors:
  - drop_event:
      when:
        - equals:
            system.audit.socket.uid: {{ consul_user_uid }}

最終的には socket モニタリングは諦めた話

Auditbeat のソケットイベントを制御して Production 環境に投入しましたが一部ホストでスワップが発生したため巻き戻しを行い Elastic 社の技術サポート経由で問い合わせのやり取りを実施しました。結果として Auditbeat にかけているメモリリソース制限を上回る量の処理量が必要なことがわかりました。

DBaaS for MySQL が管理するインスタンスでは監視ミドルウェアが必要以上にリソースを消費しないように systemd を利用したリソース制限を行っています。一方でプロセッサはフィルタリングする前に一回ログイベントの中身をチェックする必要があり、ソケットの疎通が頻繁に行われるホストでは大量のイベントをメモリ上に配置しなければなりません。その結果リソース制限 (Auditbeat に対して上限 200MB のリソース制限をかけています) 以上のメモリ量が必要となり Auditbeat によるスラッシングが発生する事態となりました。

最終的にはチーム内で検討した上で、リスクと天秤にかけてソケットモジュールを無効化する設定を Production 環境に投入しスワップの発生を抑制しました。こちらは今後も対策と検討を続けていきたいと思っています。