「ログを取りこぼしたくないので、UDPをやめてTLSにしました。これで安心ですよね？」
「ネットワーク機器のログだけ、時刻が9時間ずれて記録されています」
どちらも、syslogの形式と運び方を知っていれば、原因と対策が見えてくる話です。
第1回（ログとは・なぜ集めるか）では、なぜログを集めるのかを見ました。第2回では、ログを集める共通の仕組みであるsyslogの、メッセージの形式と転送方式を扱います。
syslogの歴史
syslogは、1980年代にBSD UNIXの開発の中で、Eric Allmanがメール配送ソフトのsendmailのために作ったログの仕組みが始まりです。やがてUNIX系のOS全般とネットワーク機器へ広がりました。
- 長い間、仕様書のない「事実上の標準」で、実装ごとに少しずつ違っていた
- 2001年のRFC 3164は、既存の実装の動きを観察して記録したもので、標準ではなくInformational（情報提供）という位置づけ
- 2009年に、形式を定めるRFC 5424と、運び方を定めるRFC 5425（TLS）・5426（UDP）などが標準として公開され、RFC 3164は廃止（Obsolete）された
それでも、今も多くの機器が3164に近い形式で送るため、集める側は両方の形式を読めなければなりません。
syslogに関するRFC
| RFC | 年 | 状態 | 内容 |
|---|---|---|---|
| 3164 | 2001 | Informational（5424 で廃止） | BSD syslog の形式の記録。パケットは1024バイト以下、UDP 514 |
| 5424 | 2009 | Proposed Standard | syslog のメッセージの形式（ヘッダー・構造化データ・MSG）。TLS での転送の実装は必須 |
| 5425 | 2009 | Proposed Standard（9662 で更新） | TLS での転送。TCP 6514。証明書で相手を認証 |
| 5426 | 2009 | Proposed Standard | UDP での転送。受信できるべき長さ（480・1180・2048） |
| 5427 | 2009 | Proposed Standard | Facility と Severity を SNMP の MIB で表すための定義 |
| 5848 | 2010 | Proposed Standard | 署名付きメッセージ。改ざん・欠落・再送を検知できる |
| 6012 | 2010 | Proposed Standard（8996・9662 で更新） | DTLS での転送。UDP 6514 |
| 6587 | 2012 | Historic | 平文の TCP での転送（既存の実装の記録）。IESG は実装・展開を推奨しない |
RFC 9662（2024年10月）で、TLS・DTLSの必須の暗号スイートに、前方秘匿性のあるTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256が加わり、DTLSは1.2が必須になりました（前方秘匿性は連載「証明書入門」第2回）。
Facility：どこから来たログか
syslogのメッセージには、「どこから来たか」を表すFacilityと、「どれくらい重要か」を表すSeverityが付きます。
| 値 | 名前（rsyslog） | RFC 5424 の説明 | 主な使われ方 |
|---|---|---|---|
| 0・1・2・3 | kern・user・mail・daemon | カーネル、ユーザーレベル、メール、システムデーモン | カーネル、logger の既定（user）、Postfix、一般のデーモン |
| 4・10 | auth・authpriv | セキュリティ・認可 | ログイン、su・sudo。authpriv は閲覧を制限したファイルへ |
| 5 | syslog | syslogd 自身 | rsyslogd の起動・停止など |
| 6・7・8 | lpr・news・uucp | プリンター、ネットニュース、UUCP | 現在はほとんど使われない |
| 9・15 | cron・clock | 時刻デーモン（clock daemon） | 9 は cron。15 は実装により名前が異なる |
| 11・12 | ftp・ntp | FTP デーモン、NTP | vsftpd、ntpd |
| 13・14 | audit・alert | log audit、log alert | 監査用・警報用。auth・authpriv とは別物。使う実装は一部 |
| 16〜23 | local0〜local7 | ローカル用 | 機器やアプリに自由に割り当てる（Cisco の既定は local7） |
名前はOSや実装によって異なり、上の表はrsyslog 8.2512で表示を確かめたものです。local0〜7は「local4はファイアウォール、local5はESXi」のように、組織内で割り当てを決めて台帳に残すと、振り分け（第5回）が楽になります。
Severity：どれくらい重要か
| 値 | 名前 | 意味 | 例 |
|---|---|---|---|
| 0 | emerg | システムが使えない | カーネルパニック |
| 1 | alert | ただちに対処が必要 | データベースの破損 |
| 2 | crit | 危機的な状態 | ハードウェアの故障 |
| 3 | err | エラー | サービスの起動失敗 |
| 4 | warning | 警告 | ディスクの使用率が高い |
| 5 | notice | 正常だが重要 | 設定の変更（logger の既定） |
| 6 | info | 情報 | ログインの成功、接続の記録 |
| 7 | debug | デバッグ用 | 開発・調査用の詳細 |
- 値が小さいほど重要。
journalctl -p（第3回）や、rsyslogの比較（$syslogseverity <= 4、第5回）もこの値を使う - WindowsのイベントのLevelは1＝重大〜5＝詳細で、並びが違うため、変換に注意する（第6回）
- どのSeverityを付けるかは作者が決めるので、一律に切らない（第1回）
PRIの計算
syslogのメッセージの先頭にある<132>のような数字がPRI（Priority value）で、FacilityとSeverityを1つにまとめたものです。
- 計算式は「Facility × 8 ＋ Severity」。Severityは0〜7の8通りなので重ならない。例えばlocal0（16）のwarning（4）は16 × 8 ＋ 4 ＝ 132
- 戻すには8で割る。
<134>なら134 ÷ 8 ＝ 16 余り 6で、local0.info - PRIはパケットの先頭にあるので、tcpdumpで見れば、どのFacility・Severityで届いたかが分かる（第10回）。一方、ファイルに書かれたログにはPRIが残らないのが普通で、確かめるにはテンプレートで出力させる（第5回）
RFC 3164（BSD形式）の形式
<132>Sep 26 17:41:43 web01 myapp: disk usage 91%
<86>Jul 6 08:05:12 web01 sshd[1234]: Accepted publickey for alice from 192.0.2.21 port 50522 ssh2
- 3つの部分からなる：PRI（
<132>）、HEADER（TIMESTAMPとHOSTNAME）、MSG（TAGとCONTENT）。1行目はlogger --rfc3164で送り、受信側で見た実物 - TIMESTAMPは
Mmm dd hh:mm:ssの現地時刻で、年とタイムゾーンが無い。日が1桁なら0ではなく空白で埋める（Jul 6、空白2つ） - HOSTNAMEはドメインを付けない名前かIPアドレス。TAGはプログラム名で32文字以内、慣例で
[PID]を付け、:の後にCONTENTが続く - パケット全体は1024バイト以下（RFC 3164 4.1）。ただし実際の機器はこの形式から少しずつ外れることが多く、受信側は推測しながら解釈している
RFC 5424の形式
<132>1 2026-09-26T17:41:43.895957+09:00 web01 myapp - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="124747"] disk usage 91%| 項目 | 例 | 決まり |
|---|---|---|
| PRI・VERSION | <132>1 | VERSION は現在 1 |
| TIMESTAMP | 2026-09-26T17:41:43.895957+09:00 | RFC 3339 の形式。T と Z は大文字、時は2桁、秒の小数は6桁まで、うるう秒は使わない |
| HOSTNAME | web01 | FQDN を推奨。255文字まで |
| APP-NAME | myapp | 送信したアプリの名前。48文字まで |
| PROCID | – | プロセスIDなど。128文字まで |
| MSGID | – | メッセージの種類。32文字まで |
| STRUCTURED-DATA | [timeQuality …] | キーと値の組。無ければ – |
| MSG | disk usage 91% | 本文。UTF-8 なら先頭に BOM |
値の無い項目は-（NILVALUE）で埋めるため、項目の数と順番は常に同じです。TIMESTAMPの時は2桁で、2020-07-16T8:17:45Zではなく2020-07-16T08:17:45Zが正しい形です。上の例はlogger --rfc5424で送り、受信側で見た実物です。
構造化データとMSG
<37>1 2026-09-26T17:41:43.899752+09:00 web01 myapp - LOGIN [timeQuality tzKnown="1" isSynced="1" syncAccuracy="124747"][auth@32473 user="alice"] login ok
2026-09-18T08:08:07.478788+09:00 web01 rsyslogd: [origin software="rsyslogd" swVersion="8.2512.0" x-pid="1445" x-info="https://www.rsyslog.com"] start- 構造化データは
[SD-ID 名前="値" …]の形で、機械が読みやすいキーと値を載せる。いくつも並べられ、無ければ- - SD-IDは、IANA登録の名前（timeQuality・originなど）か、
名前@企業番号（auth@32473。32473は文書用）。1つ目は、loggerの--msgid・--sd-id・--sd-paramで付けた例 - timeQualityは時刻の品質（
isSynced="1"は同期済み、syncAccuracyは誤差の上限でマイクロ秒）で、loggerが自動で付ける。2つ目は、rsyslogd自身の起動メッセージ - MSGはUTF-8なら先頭にBOM（EF BB BF）を付けると定めるが、付けない実装が多い（loggerも付けない）。受信側はどちらにも備える
RFC 3164とRFC 5424の比較
| 観点 | RFC 3164（BSD 形式） | RFC 5424（IETF 形式） |
|---|---|---|
| 位置づけ | Informational（既存の動きの記録） | Proposed Standard |
| 時刻 | Sep 26 17:41:43。年・タイムゾーン・秒未満なし | 2026-09-26T17:41:43.895957+09:00。すべてあり |
| 送信元の表し方 | HOSTNAME と TAG（myapp[1234]:） | HOSTNAME・APP-NAME・PROCID・MSGID に分かれる |
| 構造化データ | なし | あり（キーと値） |
| 文字コード | 決まりなし（ASCII が前提） | UTF-8 を推奨（SHOULD）。UTF-8 なら先頭に BOM（MUST） |
| 長さ | パケット全体で1024バイト以下 | 上限の定めなし。受信側は480以上、2048以上を推奨 |
| 主な使われ方 | 多くのネットワーク機器、rsyslog の転送の既定 | logger でリモートに送るときの既定（util-linux 2.26 以降） |
- 3164しか解釈できない受信側に5424形式を送っても、PRIで振り分けられ、残りは文字列として保存される（日付の前にVERSIONの
1が紛れ込む） - 逆に3164形式には年とタイムゾーンが無く、受信側が自分の年とタイムゾーンで補うため、両者のタイムゾーンが違うと時刻がずれる（第7回、連載「NTP入門」第2回）
冒頭の「ネットワーク機器のログだけ9時間ずれる」は、この典型です。機器がUTCの時刻を3164形式で送り、JSTのログサーバーが「JSTの時刻」として補っているのです。
メッセージ長
| 決まり | 値 | 出典 |
|---|---|---|
| 受信側が必ず扱える長さ（IPv4） | 480オクテット以上 | RFC 5424 6.1、RFC 5426 3.2 |
| 受信側が必ず扱える長さ（IPv6） | 1180オクテット以上 | RFC 5426 3.2 |
| 受信側が扱えるべき長さ | 2048オクテット以上（推奨） | RFC 5424 6.1、RFC 5426 3.2 |
| TLS での受信 | 2048以上は必須、8192以上を推奨 | RFC 5425 |
| BSD 形式のパケット全体 | 1024バイト以下 | RFC 3164 4.1 |
| 長すぎるときの扱い | 切り詰めを推奨。切るなら末尾から。捨ててもよい | RFC 5424 6.1 |
480と1180は、IPv4の576・IPv6の1280オクテットという最小のMTUをもとに、断片化せずに届く大きさとして決めたと、RFC 5426に明記されています。実際の上限は実装と設定で決まります（rsyslogの既定は8k。global(maxMessageSize="64k")などで変更）。長いログは途中で切れるため、送受信の設定をそろえます。
転送方式
| 方式 | ポート | 特徴 | 注意 |
|---|---|---|---|
| UDP | 514/udp（IANA 登録） | 最も単純。ほぼすべての機器が対応 | 欠損に気付けない。送信元を偽装しやすい。平文 |
| TCP（平文） | 514/tcp が慣例（IANA では shell に割り当て） | 接続が切れれば分かり、つなぎ直せる | 相手の OS に渡したことしか分からない。平文。RFC 6587 は Historic |
| TLS | 6514/tcp（RFC 5425） | 暗号化と、証明書による相手の認証 | 証明書の管理が必要。届いたことの保証は TCP と同じ |
| DTLS | 6514/udp（RFC 6012） | UDP のまま暗号化 | 対応する製品が少ない |
| RELP | 決まった番号なし（rsyslog の文書の例は 2514/tcp、この連載の設定例は SELinux で許可済みの 20514/tcp） | 受信側が処理したことをアプリの層で応答。切断時に送り直す | rsyslog 系どうしが中心。暗号化には TLS を併用 |
logger -T（TCP）は、ポートを指定しないと601/tcp（syslog-conn、RFC 3195）に送ろうとします。手元のUbuntu 26.04では、この名前を解決できずにエラーになりました。TCPで試すときは、-P 514のようにポートを必ず指定します（第3回）。
到達保証と暗号化は別のもの
冒頭の「TLSにしたから取りこぼさない」への答えです。
- 転送方式は、「届いたことを保証したい（到達保証）」と「盗み見・改ざんを防ぎたい（暗号化）」を分けて考える
- よくある誤解が「TCPやTLSにすればログは失われない」。TCPの確認応答は、相手のOSが受け取ったことを示すだけで、ログサーバーが処理してディスクに書いたことは示さない。接続が切れた瞬間に送信側のOSに残っていた未確認のデータは、アプリケーションに知らされないまま失われる
- TLSはこれに暗号化と相手の認証を加えるだけで、到達についてはTCPと同じ（RFC 5425も、TLSが守るのは区間ごとの通信だとしている）
- アプリケーションの層で「処理しました」と応答し、切断時に未確認の分を送り直すのがRELP
ポイント
到達保証はRELP、暗号化はTLS。両方ほしければRELP over TLS。送り先の停止に備え、ディスクのキュー（第4回）と組み合わせる。
考えてみよう
<86>と<190>は、それぞれどのFacility・Severityですか。自分の担当機器のログが、どのFacilityで送られているか説明できますか。- ネットワーク機器からRFC 3164形式で届いたログを、別のタイムゾーンで動いているログサーバーで受けると、時刻はどう記録されますか。
- 「ログの欠損を防ぎたいのでTLSにしたい」と相談されたら、何と答えますか。
ヒント：この記事のPRIの計算、RFC 3164と5424の比較表の「時刻」の行、「到達保証と暗号化は別のもの」の図が手がかりです。
まとめ
- syslogは1980年代生まれ。RFC 3164は既存の記録、RFC 5424が標準。今も3164形式の機器は多い
- Facilityは「どこから」、Severityは「どれくらい重要か」（小さいほど重要）
- PRI＝Facility×8＋Severity。ファイルには残らないので、パケットかテンプレートで確かめる
- 3164は年・タイムゾーンが無く、受信側が補う。5424は項目の数と順番が決まっている
- 長いログは切れる。送受信の長さの設定をそろえる
- UDPは欠損に気付けない。到達保証はRELP、暗号化はTLS
次回は、Linuxの中でログがどのように集められ、ファイルや転送に渡るのか（journaldとrsyslog）を扱います。
連載「syslog入門」全11回
全回の目次と、読む順番・目的別の読み方は、syslog入門の入口のページにまとめています。
- ログとは・なぜ集めるか
- syslogの基本（この記事）
- Linuxのログの仕組み
- rsyslog 前編
- rsyslog 後編
- Windows・ネットワーク機器のログ
- ログ集約基盤の設計
- 分析と監視・SIEM
- クラウドのログ
- syslogのトラブルシュート
- ログ管理の設計演習
コメント