はじめに
Azure Monitor Agent (AMA) を使用すると、さまざまな環境のログを Log Analytics ワークスペースや Microsoft Sentinel に統合できます。特に大規模な企業ネットワークやシステムではプロキシやファイアウォール、syslog 転送サーバから AMA をインストールした Linux サーバに syslog データを転送するケースがあります。
しかし、単一のサーバに負荷が集中すると、ログの遅延や欠損のリスクが発生します。そのため、可用性を高め、スケーラブルなログ収集を実現するために負荷分散を検討する必要があります。
しかしながら、syslog 通信における負荷分散には課題があるため、実現方式を確認していきます。
なお負荷分散の参考となる AMA のパフォーマンス ベンチマークおよびベスト プラクティスは以下に記載があります。
課題
syslog 通信の負荷分散にはいくつかの課題があります。
- TCP の場合、1 コネクションで継続して syslog を転送し続けるため、コネクションレベルで負荷分散する Azure Load Balancer などの L4 ロード バランサでは要件が満たせない
- UDP の場合、代表的な rsyslog は UDP ソケットを使い続ける仕様と思われるため送信元ポートが同一となり、5 タプル(※)が一致し負荷分散ができない
※ 5 タプルを含む Azure Load Balancer 分散モードは以下の解説は以下に記載
課題を確認
まずは課題の挙動を確認していきます。今回は UDP のケースです。構成は以下です。
以下を vmcusubuntu02 の rsyslog.conf に追加します。
*.* @10.0.0.24:514
vmcusubuntu01/03 は以下で UDP/514、TCP/514 のログ受信を有効化します。
※ LB からの正常性プローブのため TCP も有効化
# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")
vmcusubuntu02 で以下のスクリプトでログを流します。
#!/bin/bash
end=$((SECONDS+3600))
while [ $SECONDS -lt $end ]; do
for i in {1..10}; do
logger -p syslog.info "This is test message $i"
sleep 0.1
done
done
以下の通り、vmcusubuntu02の ソース ポートが一緒のため、5 タプルによるハッシュ値が一致してしまい、すべて vmcusubuntu01 に振り分けられます。
vmcusubuntu03 には syslog が来ていません。
コネクションを切断 / ソース ポートをランダム化
TCP のコネクション切断、UDP のソース ポートのランダム化ともに対処は同一で以下になります。
上記の記事に従って、 RebindInterval を設定し、rsyslog サービスを再起動します。下記は RebindInterval="1" に設定しているため、UDP パケットごとにソース ポートが変わる想定です。
*.* action(type="omfwd" target="10.0.0.24" port="514" protocol="udp" RebindInterval="1")
ログ送信のスクリプトを再度実行します。以下の通り、ソース ポートが 1 パケットごとに変更されていることが分かります。
またログのナンバーが連番になっておらず、負荷分散されていることが分かります。
考慮点
ファイアウォールなどでログ送信元の設定をカスタマイズできない場合、ロードバランサーとの間に RebindInterval を利用してコネクション切断/ソースポートのランダム化をする中継サーバを準備する必要があります。
この中継サーバの負荷は、AMA のログ送信処理を行うよりは軽いですが、1台で処理することになるため、継続して負荷状況をチェックする必要があります。
またこのサーバの冗長化も考慮する場合、以下のイメージで新たにロード バランサーを導入し、Active / Standby 構成とする必要があります。
Discussion