「新しく入れたスイッチのログだけ、ログサーバーに届きません」
「障害で一番ログが欲しい時間帯に限って、ログが抜けています」
ログが届かない原因は、送信側・経路・受信側のどこにでもあり得ます。やみくもに設定を見直すより、1か所で見て、範囲を半分に絞るほうが早く着きます。
第10回では、第1回〜第9回の知識を使って、syslogのトラブルの切り分けをまとめます。最後に連載の早見表も載せます。
切り分けの手順
| 段階 | 確認すること | Linux | Windows |
|---|---|---|---|
| 0 症状を固める | どの送信元が・全部か一部か・常にか時々か・いつから | 受信側のファイルを送信元で grep | 送信元のイベントを Get-WinEvent で確認 |
| 1 送信側で出ているか | ログの生成、転送の設定、送信側のファイアウォール、レート制限 | logger -n サーバー -P 514 -T “test”、rsyslogd -N1、journalctl -u rsyslog | eventcreate でテストのイベント、wecutil gr 購読名（WEF） |
| 2 経路で届いているか | 受信側の NIC にパケットが来るか、途中の FW・NAT・送信元 IP | 受信側で tcpdump -i any -nn port 514 | Test-NetConnection サーバー -Port 6514（TCP のみ）、pktmon |
| 3 受信側で受け取っているか | 待ち受け、firewalld、SELinux、UDP の受信エラー | ss -ulnp、firewall-cmd –list-all、nstat -az UdpRcvbufErrors | Get-NetUDPEndpoint -LocalPort 514、netstat -s -p udp |
| 4 保存され、見つかるか | 振り分け先、ホスト名、時刻、文字コード、ディスク | df -h /var/log、受信時刻と機器の時刻の比較 | Get-WinEvent -ListLog ForwardedEvents |
まず受信側でtcpdumpを取り、届いていれば受信側（段階3・4）、届いていなければ送信側か経路（段階1・2）と、真ん中から二分すると早く絞り込めます。調べるときは、送信元のIPアドレスと時刻（UTC）を必ず控えます。
ポイント
受信側のNICで1回見るだけで、疑う範囲が「送信側・経路」か「受信側」かに絞れる。
送信側と経路を確かめる：loggerとtcpdump
# 受信側（192.0.2.10）で先に起動しておく
$ sudo tcpdump -i any -nn port 514
# 送信側（192.0.2.31）からテストのメッセージを送る
$ logger -n 192.0.2.10 -P 514 -d -t test "syslog test via UDP" # UDP
$ logger -n 192.0.2.10 -P 514 -T -t test "syslog test via TCP" # TCP
logger: failed to connect to 192.0.2.10 port 514 # TCP は失敗が分かる
# 受信側の表示（UDP が届き、待ち受けがない場合）
10:23:45.123456 ens192 In IP 192.0.2.31.51234 > 192.0.2.10.514: SYSLOG user.notice, length: 51
10:23:45.123506 ens192 Out IP 192.0.2.10 > 192.0.2.31: ICMP 192.0.2.10 udp port 514 unreachable, length 87
- UDPは送りっぱなし。
logger -dは相手がいなくても成功で終わるため、届いたかは受信側のtcpdumpで確かめる。-d・-Tを付けないとUDPを先に試すので、方式は明示する -Tだけではポートがsyslog-conn（601）になるため、-P 514を付ける（第3回）。TLS（6514）はloggerでは試せないので、openssl s_client -connect サーバー:6514で証明書まで確かめる- Inの行があれば経路は通っている。続けて
ICMP … port 514 unreachableが返るなら、届いているのに受信側が待ち受けていない（後の節）。中身は-A、FacilityとSeverityは-vで見られる
Windowsから確かめる
PS> Test-NetConnection logsv01.corp.example.jp -Port 6514
ComputerName : logsv01.corp.example.jp
RemoteAddress : 192.0.2.10
RemotePort : 6514
InterfaceAlias : Ethernet
SourceAddress : 192.0.2.41
TcpTestSucceeded : True
PS> $u = [System.Net.Sockets.UdpClient]::new() # UDP は「送るだけ」なら標準でできる
PS> $b = [Text.Encoding]::UTF8.GetBytes('<14>1 - pc01 test - - - syslog test from Windows')
PS> $u.Send($b, $b.Length, 'logsv01.corp.example.jp', 514); $u.Close()
48
PS> eventcreate /T INFORMATION /ID 999 /L APPLICATION /SO SyslogTest /D "forward test"
- つながらないときは、先頭に「警告: TCP connect to 192.0.2.10:6514 failed」と出て、
TcpTestSucceededがFalseになる。このときは ping も試され、PingSucceeded（ICMPの結果で、TCPの可否とは別）が加わる。Windows Server 2016 では、つながったときもPingSucceededが表示される Test-NetConnection -PortはTCPの接続だけを試す。TCP 514・6514の接続の可否は分かるが、UDP 514が届くかは確かめられず、TLSの証明書の検証もしない- UdpClientの
Sendの戻り値は送ったバイト数だけで、届いたかは受信側のtcpdumpで確かめる eventcreate（管理者）はイベントログに書くので、WEFやNXLog経由の転送を試せる（第6回）- Windowsでパケットを見るなら、標準のpktmon（
filter add -p 514→start -c→stop→etl2txt PktMon.etl）を使う
受信側を確かめる：待ち受け・ファイアウォール・SELinux
冒頭の「新しいスイッチのログだけ届かない」で、tcpdumpには見えるのにファイルに無い場合は、ここを疑います。
| 確認すること | Linux（RHEL） | Windows（受信側の場合） | 見るところ |
|---|---|---|---|
| 待ち受けているか | ss -ulnp ‘sport = :514’、ss -tlnp | Get-NetUDPEndpoint -LocalPort 514 | rsyslogd が 0.0.0.0 か、特定の IP だけか |
| 設定が読めているか | rsyslogd -N1、journalctl -u rsyslog | サービスとアプリのイベントログ | imudp・imtcp の読み込み、TLS 用のパッケージ（rsyslog-gnutls 等） |
| ファイアウォール | firewall-cmd –list-all、–add-service=syslog（UDP 514）、–add-service=syslog-tls（6514）、–add-port=514/tcp | Get-NetFirewallPortFilter -Protocol UDP | Where-Object LocalPort -eq 514 | Get-NetFirewallRule | 許可したポートと実際の受信の方式が合っているか |
| SELinux | semanage port -l | grep syslog、ausearch -m AVC -ts recent、semanage port -a -t syslogd_port_t -p tcp 30514 | — | 既定にないポートで受けるときは追加が必要 |
| 受け取った後 | ルールセット・フィルター・$AllowedSender、振り分け先のファイル | wecutil gr 購読名（WEF） | 送信元 IP やホスト名の条件で捨てていないか |
tcpdumpは、ファイアウォールより手前でパケットを見ます。tcpdumpに見えるのにrsyslogに届かないときは、受信側のファイアウォール・SELinux・待ち受けを疑います（第4回の3つの関門）。UbuntuはrsyslogをAppArmorで制限しており、既定外の保存先には/etc/apparmor.d/rsyslog.d/で許可が要ります。
ときどき抜ける：UDPの欠損とレート制限
冒頭の「一番欲しい時間帯に限って抜ける」の、2つの原因です。
$ nstat -az UdpInErrors UdpRcvbufErrors # 受信側：増え続けるならバッファーのあふれ
UdpInErrors 211657 0.0
UdpRcvbufErrors 211657 0.0
$ ss -uanm 'sport = :514' # d がこのソケットで捨てた数
UNCONN 0 0 0.0.0.0:514 0.0.0.0:*
skmem:(r0,rb212992,t0,tb212992,f0,w0,o0,bl0,d1532)
$ grep 'rate-limiting' /var/log/messages # 送信元（RHEL）
... imjournal: 11538 messages lost due to rate-limiting (20000 allowed within 600 seconds)
$ journalctl -b | grep Suppressed
... systemd-journald[612]: Suppressed 4210 messages from myapp.service
PS> netstat -s -p udp # Windows：UDP の受信エラーの増え方を見る
- UDPの欠損：受信側の処理が追いつかないと、カーネルの受信バッファーがあふれ、パケットは黙って捨てられる。送信側にも受信側のrsyslogにもエラーは出ない。カウンターで確かめ、imudpの
RcvBufSize、受信の分散、重要なログはTCPとキューへの切り替えで対処する - レート制限：送信元のサーバーの中でも捨てられる。journaldは既定でサービスごとに30秒に10000件、RHELのrsyslogが使うimjournalは600秒に20000件を超えた分を捨て、件数だけを記録する（第5回）
障害や攻撃の最中はログが急増するので、一番欲しい時間帯ほど抜けやすいのです。
時刻・文字化け・ディスク
| 症状 | 主な原因 | 確認 | 対処 |
|---|---|---|---|
| 時刻が数分〜9時間ずれる、探しても見つからない | 送信元の時計のずれ、JST と UTC の混在、年やタイムゾーンのない RFC 3164 の時刻 | 受信時刻 %timegenerated% と機器の時刻 %timereported% を並べて出力、chronyc tracking、w32tm /query /status | 全台を NTP で同期（連載「NTP入門」第7回）、オフセット付きの RFC 3339 で記録 |
| 日本語が化ける | Shift_JIS（CP932）で送る機器やアプリ。syslog には Shift_JIS などの文字コードを伝える仕組みがない（RFC 5424 の BOM は UTF-8 の印だけ） | iconv -f CP932 -t UTF-8 ファイル、Get-Content ファイル -Encoding Default（日本語版の Windows PowerShell 5.1 は CP932） | 送信側を UTF-8 に。できなければ受信後に変換 |
| タブが #011 になる | 受信時の制御文字のエスケープ（既定で有効） | ログの中の #011 | 必要なら parser.escapeControlCharacterTab=”off” |
| 書き込みが止まる | ディスクの枯渇 | df -h /var/log、du -sh /var/log/remote/*、Get-Volume | logrotate と容量の監視、保存先を分ける（第7回） |
| 消しても空かない | ローテーション後も古いファイルを開いたまま | lsof +L1（df と du の差） | postrotate で rsyslog に HUP を送る |
| 送信側のディスクが減る | 転送先の停止でディスクキューが溜まる | du -sh /var/lib/rsyslog（Ubuntu は /var/spool/rsyslog） | queue.maxDiskSpace で上限を決め、転送先を監視 |
Windowsで集める側（WEC）は、Get-WinEvent -ListLog ForwardedEvents | Select-Object LogMode, MaximumSizeInBytes, FileSize, IsLogFullで、ログが満杯になり上書きや停止をしていないかを見ます。
原因と確認コマンドの対応表
| 原因 | 見える症状 | Linux | Windows |
|---|---|---|---|
| 送信側の設定・送信側の FW | 1台だけまったく届かない | logger -n サーバー -P 514 -T “test”、rsyslogd -N1、ESXi は esxcli network firewall ruleset list -r syslog | eventcreate、wecutil gr 購読名 |
| 経路の FW・送信元 IP の変化 | 拠点や機器の種類ごとに届かない | 受信側で tcpdump -i any -nn port 514 | Test-NetConnection -Port（TCP のみ）、pktmon |
| 待ち受けていない | ICMP の port unreachable が返る | ss -ulnp、ss -tlnp | Get-NetUDPEndpoint、Get-NetTCPConnection -State Listen |
| firewalld・SELinux | tcpdump に見えるのに保存されない | firewall-cmd –list-all、semanage port -l、ausearch -m AVC | Get-NetFirewallPortFilter から Get-NetFirewallRule |
| UDP の受信バッファーのあふれ | 混雑する時間だけ抜ける | nstat -az UdpRcvbufErrors、ss -uanm | netstat -s -p udp |
| レート制限・配信の遅れ | 大量に出た日だけ抜ける、遅れて届く | grep rate-limiting /var/log/messages、journalctl -b | grep Suppressed | wecutil gs 購読名（配信の最適化） |
| 時刻・タイムゾーン | 時刻がずれる、見つからない | chronyc tracking、%timegenerated% と %timereported% | w32tm /query /status、Get-TimeZone |
| 文字化け・ディスク | 化ける、書き込みが止まる | iconv -f CP932 -t UTF-8、df -h、lsof +L1 | Get-Content -Encoding Default、Get-WinEvent -ListLog ForwardedEvents |
連載の早見表
困ったときに戻る場所を、連載全体でまとめておきます。
| 回 | テーマ | 押さえること | 使う場面 |
|---|---|---|---|
| 第1回 | ログの目的 | 障害調査・セキュリティ・監査、壊れる・消される前に集める、規制と保存期間 | 要件の整理（第11回の問2） |
| 第2回 | syslog の基本 | Facility と Severity（PRI）、RFC 3164 と 5424、UDP・TCP・TLS（6514）・RELP の違い | 方式の選択（問1・問2） |
| 第3回 | Linux のログ | journald と rsyslog の関係、logger、logrotate | 送信側の確認（問4） |
| 第4回〜第5回 | rsyslog の実践 | RainerScript、omfwd とディスクキュー、フィルター、TLS、RELP、レート制限 | 転送の設計（問1・問2） |
| 第6回 | Windows・機器 | イベントログと WEF、監査ポリシー、NW 機器・ESXi の syslog | 収集の方式（問1） |
| 第7回 | 集約基盤の設計 | 中継と冗長、容量（EPS × 大きさ × 日数）、保存期間、改ざん防止、UTC、構造化ログ | 容量と保存（問1・問2） |
| 第8回〜第9回 | 分析・SIEM、クラウド | 検索基盤と監視・アラート、CloudWatch Logs・CloudTrail・S3 | 一元的な検索（問3） |
| 第10回 | トラブルシュート | 送信側 → 経路 → 受信側の順、tcpdump・logger、UDP の欠損、レート制限 | 障害対応（問4） |
どの回も、「このログは、誰が、何で運び、どこに、いつまで残るか」を意識すると理解しやすくなります。
振り返りと持ち帰り
- ログは「届いたか確かめられる形」で運ぶ。UDPは抜ける前提で、重要なログはTCPとディスクキュー、暗号化はTLS、受け取りの確認まで要るならRELP。届かないときは送信側 → 経路 → 受信側の順に確かめる
- 時刻・形式・文字コードをそろえてから集める。全台をNTPで同期し、オフセット付きのRFC 3339（できればUTC）とUTF-8で記録し、送信元の名前もそろえる
- 容量・保存期間・改ざん防止を最初に設計する。EPS × 1件の大きさ × 日数で見積もり、検索用と保管用を分け、WORMとハッシュで証跡を守る
参考資料
- RFC：3164（BSD syslog、Informational）、5424（syslogプロトコル）、5425（TLS）、5426（UDP）、5427（Facility・SeverityのMIB定義）、5848（署名）、6012（DTLS）、6587（TCP、Historic）、9662（TLS・DTLSの暗号スイートの更新）、3339（日時の書式）
- 公式ドキュメント：rsyslogのドキュメント（docs.rsyslog.com）、Red Hat「Configuring a remote logging solution」（RHEL 9・10）、journald.conf(5)・logger(1)のman、Microsoft Learn（Windowsイベント転送、Test-NetConnection、Pktmon）、Broadcom TechDocs（ESXiのsyslog）、AWS（CloudWatch Logs、CloudTrail、S3 Object Lock）、PCI SSC（PCI DSS v4.0.1）
考えてみよう
- 新しく入れたネットワーク機器のログだけが届きません。最初にどこで何を実行しますか。その結果で、次に調べる場所はどう変わりますか。
- 受信側のtcpdumpには届いているのに、/var/log/remote/にファイルができません。何をどの順に確かめますか。
- 毎朝9時台だけ、ログの件数が少なく見えます。どんな原因が考えられ、どのカウンターを見ますか。
ヒント：この記事の切り分けの図、受信側の関所の図、UDPの欠損とレート制限の図が手がかりです。まずは自分のサーバーでlogger -n 集約サーバー -P 514 -T "test"を送り、受信側のtcpdumpとファイルで到着を確かめてみてください。
まとめ
- 切り分けは受信側のtcpdumpで二分する。見えなければ送信側・経路、見えれば受信側
logger -d（UDP）は届かなくても成功。TCPは-T -P 514、TLSはopenssl s_client- Windowsの
Test-NetConnectionはTCPだけ。UDPは受信側で、パケットはpktmonで - tcpdumpに見えるのに保存されないなら、firewalld・SELinux・待ち受け・フィルター
- ときどき抜けるのはUDPの受信バッファーとレート制限。どちらもカウンターを見る
- 「届いているのに見つからない」は時刻・文字コード・ディスク
次回はいよいよ最終回。これまでの知識を使って、ログ管理を要件から設計する演習に取り組みます。
連載「syslog入門」全11回
全回の目次と、読む順番・目的別の読み方は、syslog入門の入口のページにまとめています。
- ログとは・なぜ集めるか
- syslogの基本
- Linuxのログの仕組み
- rsyslog 前編
- rsyslog 後編
- Windows・ネットワーク機器のログ
- ログ集約基盤の設計
- 分析と監視・SIEM
- クラウドのログ
- syslogのトラブルシュート（この記事）
- ログ管理の設計演習
コメント