NLB + rsyslog で構築する マルチポート対応 Syslog サーバーを設定してみた
2025.04.25こんにちは、岩城です。
先日、マルチポートでログを受信する Syslog サーバーの構成を検討する機会がありました。
検討段階では Syslog サーバー 1 台構成ですが、いずれ複数台で運用することが想定できますので、Syslog サーバーの前段に NLB を配置することを考えました。
このとき、NLB のターゲットグループを 1 つにまとめられるのか、ポートごとにターゲットグループを分けた方が良いのか分かりませんでした。
ターゲットグループを 1 つにまとめる場合の構成図
ターゲットグループをポートごとに分ける場合の構成図
ターゲットグループの数を 1 つにできればそれに越したことはないですよね。
ということで本エントリでは、NLB + rsyslog で構築する マルチポート対応 Syslog サーバーを設定しつつ、ターゲットグループをまとめられるのか、分けたほうが良いのかを検証して確認してみました。
結論
結論です。
実際に検証してみたところ、ポートごとにターゲットグループを分ける必要がありました。
514/udpで待ち受けている rsyslog に10514/udpで送信したログが受信されてしまうことがあったり、ログ送信とログ受信する件数が一致しませんでした。
これはもしかすると、私が NLB、udp、rsyslog を十分に理解していないことによるものかもしれませんが、ポートごとにターゲットグループを分けた場合、このような事象は発生しませんでした。
以降より検証環境の説明と検証結果を記載します。
検証環境の設定
NLB 周辺の設定と EC2 の設定以外については、特別な設定をしていないので説明を省略します。
Syslog サーバー の設定
rsyslog を使用したかったので Amazon Linux 2 を選択しました。Amazon Linux 2023 では rsyslog が標準インストールされていません。
Amazon Linux 2023 に rsyslog をインストールしてみた | DevelopersIO
ポートごとにログの出力先を変更するため、以下のような conf ファイルを各ポート分、/etc/rsyslog.d/配下に作成しました。今回/etc/rsyslog.confの設定変更はしません。
$ActionQueueFileName port514
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionQueueType LinkedList
$ActionResumeRetryCount -1
$ModLoad imudp.so
$template tmpl_remote514, "/var/log/port514.log"
$RuleSet Remote514
$RulesetCreateMainQueue on
*.* -?tmpl_remote514
$InputUDPServerBindRuleset Remote514
$UDPServerRun 514
rsyslog に詳しくないため、こちらの内容を参考にしました。
conf ファイルの準備ができたので rsyslog を再起動します。
# systemctl restart rsyslog.service
netstat -lnuで設定したポートで待ち受けていることを確認できます。
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:68 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:674 0.0.0.0:*
udp 0 0 0.0.0.0:14514 0.0.0.0:*
udp 0 0 0.0.0.0:13514 0.0.0.0:*
udp 0 0 0.0.0.0:12514 0.0.0.0:*
udp 0 0 0.0.0.0:11514 0.0.0.0:*
udp 0 0 0.0.0.0:10514 0.0.0.0:*
udp 0 0 127.0.0.1:323 0.0.0.0:*
udp 0 0 0.0.0.0:514 0.0.0.0:*
udp6 0 0 fe80::4e3:2ff:feb2::546 :::*
udp6 0 0 :::111 :::*
udp6 0 0 :::674 :::*
udp6 0 0 :::14514 :::*
udp6 0 0 :::13514 :::*
udp6 0 0 :::12514 :::*
udp6 0 0 :::11514 :::*
udp6 0 0 :::10514 :::*
udp6 0 0 ::1:323 :::*
udp6 0 0 :::514 :::*
次に、NLB からのヘルスチェックで利用する Nginx をインストールして起動しておきます。
# yum -y install nginx
# systemctl enable nginx
# systemctl start nginx.service
NLB は UDP でのヘルスチェックをサポートしていないので、HTTP で/のパスにアクセスできるようにしています。
UDP サービスの場合、ターゲットの可用性は、ターゲットグループの非 UDP ヘルスチェックを使用して、テストされます。使用可能なヘルスチェック（TCP、HTTP、または HTTPS）およびターゲット上の任意のポートを使用して、UDP サービスの可用性を確認できます。ヘルスチェックを受信しているサービスが失敗した場合、ターゲットは使用不可とみなされます。UDP サービスのヘルスチェックの精度を向上させるには、ヘルスチェックポートをリッスンして UDP サービスのステータスを追跡し、サービスが使用できない場合はヘルスチェックが失敗するようにサービスを設定します。
Network Load Balancer ターゲットグループのヘルスチェック - エラスティックロードバランシング
NLB の設定
Syslog サーバーの設定が完了したので NLB を設定していきます。
オンプレミスから NLB を経由して Syslog サーバーにログ送信することを考えていたので Internal NLB にしました。
NLB の設定
リスナーとターゲットグループはポートごとに設定し、ターゲットグループのヘルスチェックは以下のように設定しました。
- プロコトル:
HTTP - パス:
/ - ポート:
80 - 成功コード:
200
ヘルスチェックの設定
マネジメントコンソールにはリソースマップという便利な機能があります。
リソースマップからリスナー、ターゲットグループ、ターゲット、ヘルスチェックステータスを一発で確認できます。
ここまでの設定が済んでいれば以下のようリソースマップになります。
ポートごとにターゲットグループを設定し、それぞれのターゲットが 1 台の Syslog サーバーであることが分かると思います。
ターゲットグループをポートごとに分ける場合
すべてのターゲットに対するヘルスチェックが成功しているので検証できる状態になりました。
検証結果
検証環境が整ったので、いざ検証です。
ログを送信するサーバーから logger を使用し、NLB を経由して Syslog サーバーへログを送信してみます。
$ logger -n <NLB の DNS 名> -P 514 "Test514"
$ logger -n <NLB の DNS 名> -P 10514 "Test10514"
$ logger -n <NLB の DNS 名> -P 11514 "Test11514"
すると、以下のように Syslog サーバー側でポートごとに作成したログファイルに各ログが記録されることを確認できました。
Apr 25 01:27:08 ip-10-0-0-196.ap-northeast-1.compute.internal ec2-user Test514
Apr 25 01:27:08 ip-10-0-0-196.ap-northeast-1.compute.internal ec2-user Test10514
Apr 25 01:27:08 ip-10-0-0-196.ap-northeast-1.compute.internal ec2-user Test11514
おまけ
おまけとして以下のようにターゲットグループをまとめた場合の検証結果も共有します。
ターゲットグループを 1 つにまとめる場合
先ほどと同様に、ログを送信するサーバーからloggerを使用して、NLB を経由して Syslog サーバーへログ送信してみます。
$ logger -n <NLB の DNS 名> -P 514 "Test514"
$ logger -n <NLB の DNS 名> -P 10514 "Test10514"
$ logger -n <NLB の DNS 名> -P 11514 "Test115
先ほどはポートごとにそれぞれのログファイルにログ記録されていましたが、同じログに記録されてしまいました。
Apr 25 03:10:08 ip-10-0-0-196.ap-northeast-1.compute.internal ec2-user Test514
Apr 25 03:13:08 ip-10-0-0-196.ap-northeast-1.compute.internal ec2-user Test10514
Apr 25 03:20:08 ip-10-0-0-196.ap-northeast-1.compute.internal ec2-user Test10514
Apr 25 03:22:08 ip-10-0-0-196.ap-northeast-1.compute.internal ec2-user Test514
それだけではなく、loggerでログ送信件数とログ受信件数が一致しないことも確認しています。
この状態では期待している動作ではないので、今回はターゲットグループを 1 つにまとめるのではなく、分ける方向で考えています。
おわりに
NLB と rsyslog を組み合わせた構成の紹介でした。
私が NLB、udp、rsyslog を十分に理解していないだけで、実はターゲットグループを 1 つにまとめながらも、きちんとポートごとにログを出し分ける方法があるのかも知れません。
解決方法をご存じの方が居れば是非教えてください。
本エントリが、どなたかのお役に立てれば幸いです。
