LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

syslogは、サーバーやネットワーク機器、アプリケーションが出すログを決まった形式で書き、別の機械へ送るための取り決めです。障害の調査でも不正アクセスの点検でも、syslogで集めたログを読むところから始まる現場は少なくありません。一方で、仕組みが古いぶん、既定のままではログが欠けたり時刻が揃わなかったりする弱点もあります。

本記事では、RFCとrsyslog・Python・systemdの公式ドキュメントをもとに、ファシリティと重大度、メッセージの形式、転送の仕組みを整理し、PythonでPRIを計算して手元で送受信した結果と、つまずきやすい点を見ていきます。

syslogとは

syslogという語は、場面によって2つのものを指します。1つは、ログのメッセージをどう書き、どう運ぶかを定めた通信の取り決め（プロトコル）です。もう1つは、その取り決めに沿ってログを受け取り、ファイルに書いたり別の機械へ送ったりする常駐プログラム（デーモン）で、Linuxではrsyslogがその代表です。

取り決めの文書は2世代あります。RFC 3164は、BSD系のUNIXで使われてきたsyslogの観察された振る舞いを書き留めた文書で、インターネット標準を定めるものではない情報提供のRFCです。^*2 その後、2009年3月に標準化の道筋（Standards Track）に乗ったRFC 5424が出て、RFC 3164を廃止しました。RFC 5424はメッセージの形式だけを定め、運び方は別の文書に分けています。^*1

RFC 5424は、ログを作る側を発信者（originator）、集める側を収集者（collector）、受け取ったメッセージを先へ送る側を中継（relay）と呼びます。1台のサーバーのデーモンが、発信者と中継を兼ねることも珍しくありません。

ファシリティと重大度

syslogのメッセージには、どの仕組みが出したかを表すファシリティと、どのくらい重い出来事かを表す重大度（severity、レベルとも呼ばれます）の2つの番号が付きます。RFC 5424は、ファシリティを0〜23、重大度を0〜7の範囲に定めています。ただし、番号の意味を並べた表は規範ではなく、参考として載せたものだと断っています。^*1 下の表の右の列は、PythonのSysLogHandlerが番号に付けている名前です。

4と10、9と15は、それぞれ同じ説明の番号が2つずつあります。Linuxでは9をcron、10をauthprivとして使うのが一般的です。業務アプリケーションのログは、16〜23のlocal0〜local7のどれかに割り当てます。

番号は小さいほど重い出来事です。2つの番号は、メッセージの先頭で1つの数にまとめて運ばれます。ファシリティの番号に8を掛けて重大度の番号を足した値で、PRI（Priority value）と呼ばれます。^*1

RFC 3164とRFC 5424の違い

RFC 3164のメッセージは、PRI、HEADER、MSGの3つの部分からなり、全体で1024バイト以下と決められています。^*2 HEADERの時刻は「Mmm dd hh:mm:ss」の形の現地時刻で、年もタイムゾーンも入りません。日付が1桁の日は、前に空白を1つ入れて「Aug 7」のように書きます。MSGは、プログラム名などを入れるTAGと、本文のCONTENTに分かれます。

RFC 5424では、HEADERの後ろにSTRUCTURED-DATAとMSGが続きます。HEADERには、PRIのほかに版の番号（VERSION、この文書では1）、時刻、ホスト名、アプリケーション名（APP-NAME）、プロセスID（PROCID）、メッセージの種類（MSGID）が並び、値の無い欄には「-」を置きます。時刻はRFC 3339をもとにした形で、年とUTCからの時差まで書けます。^*1

図の先頭はどちらも「<34>」で、34は4×8＋2なので、ファシリティ4（認可）の重大度2（Critical）だと読めます。RFC 5424の例では、時刻に年とUTCを表す「Z」が付き、ホスト名もドメイン名まで含んでいます。

STRUCTURED-DATAは、角かっこの中に「名前=”値”」の組を並べ、本文とは別にイベントの属性を持たせる欄です。アプリケーションのログを項目に分けて設計する考え方は「構造化ログ基盤の導入を外注で進める」で扱っています。

転送の仕組み：UDP・TCP・TLS

RFC 5424は、実装はTLSによる転送（RFC 5425）に対応しなければならず、UDPによる転送（RFC 5426）にも対応すべきで、運用ではTLSを推奨する、と定めています。

UDPによる転送では、1つのデータグラムに1つのメッセージを入れ、受け手は既定のUDPポート514で受け付けます。RFC 5426は、この方式にはデータグラムの消失を見つけて直す仕組みが無く、確認応答も再送も無いと書いています。^*3 送る側は、相手に届いたかどうかを知らないまま送り続けることになります。

TCPによる転送は、標準化されないまま広く使われてきた方式で、その使われ方を記録したRFC 6587は歴史的な文書（Historic）の扱いです。メッセージの区切り方には、先頭に長さを書く方式と、改行（LF）を末尾に置く方式があり、後者は本文に改行が入ると1件が複数件に分かれます。IESGは、素のTCPを勧めず、TLSによる転送を勧めています。^*5

TLSによる転送（RFC 5425）は、TCPのポート6514を既定とし、中身の秘匿、改ざんの検出、サーバーまたは双方の認証を担います。ただし守られるのは機械と機械の間の1区間ごとです。^*4 中継のサーバーの中ではメッセージが平文に戻るので、中継の権限管理も含めて考えます。複数のサーバーからログを集める仕組みは「Fluentd/Fluent Bitのログ収集を外注」で扱っています。

具体例：PRIの計算と送受信

まず、RFC 5424の表に沿ってPRIを計算する関数をPythonで書きました。この記事のために、Python 3.12.10で実行しています。末尾のコメントが、実行した出力です。

FAC = {"kern": 0, "user": 1, "auth": 4, "local0": 16}
SEV = {"emerg": 0, "err": 3, "warning": 4, "info": 6}

def pri(facility, severity):
    return FAC[facility] * 8 + SEV[severity]

def split(prival):
    return divmod(prival, 8)  # (ファシリティ, 重大度)

for f, s in [("local0", "err"), ("auth", "warning"), ("kern", "emerg")]:
    print(f"{f}.{s} -> <{pri(f, s)}>")
print(split(134))
# local0.err -> <131>
# auth.warning -> <36>
# kern.emerg -> <0>
# (16, 6)

local0.errは16×8＋3で131、auth.warningは4×8＋4で36、kern.emergは0です。逆に、PRIを8で割った商がファシリティ、余りが重大度なので、134はlocal0のinfoだと分かります。ログの先頭の数字から、出どころと重さを読み解けます。

次に、127.0.0.1の空いているUDPポートで小さな受け手を立て、Python標準のlogging.handlers.SysLogHandlerから2件を送りました。外部の機械には何も送っていません。受け取った後は、ハンドラと受け手のソケットを閉じています。

import logging, logging.handlers, socket
rx = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
rx.bind(("127.0.0.1", 0))  # 空いているポートを借りる
rx.settimeout(2)
h = logging.handlers.SysLogHandler(
    address=rx.getsockname(),
    facility=logging.handlers.SysLogHandler.LOG_LOCAL0)
h.ident = "orderapp: "
log = logging.getLogger("demo")
log.addHandler(h)
log.propagate = False
log.error("在庫の引き当てに失敗 order=1042")
log.warning("応答が遅い api=/stock 2.4s")
for _ in range(2):
    print(repr(rx.recv(2048).decode()))
h.close()
rx.close()
# '<131>orderapp: 在庫の引き当てに失敗 order=1042\x00'
# '<132>orderapp: 応答が遅い api=/stock 2.4s\x00'

届いたメッセージは、どちらも先頭に「<PRI>」が付いています。ERRORの記録はlocal0のerrで131、WARNINGの記録はlocal0のwarningで132です。PRIの後ろにはidentの文字列と本文だけが続き、時刻やホスト名の欄はありません。末尾には区切りのNULバイト（\x00）が付きます。^*9 受け手のデーモンがこれをどう解釈するかは、実装と設定によります。

rsyslogの設定の基本

rsyslogの基本の書き方は、セレクタと送り先を1行に並べる形です。セレクタはファシリティと重大度をピリオドでつないだもので、重大度を書くとそれより重いものも対象になります。「*」はすべて、「none」はそのファシリティを対象にしないことを表し、カンマで複数のファシリティを、セミコロンで複数のセレクタをつなげます。重大度の前の「=」はその重大度だけ、「!」は除外です。^*6

# /etc/rsyslog.d/ に置く設定の断片
*.info;mail.none;authpriv.none    /var/log/messages
authpriv.*                        /var/log/secure
local0.=err                       /var/log/orderapp-error.log

# local0 の warning 以上を、収集サーバーへ TCP で送る
local0.warning action(type="omfwd" target="logs.example.com"
               port="514" protocol="tcp"
               queue.type="linkedList")

# TLS で送るなら（RFC 5425・既定のポートは 6514）
# action(type="omfwd" target="logs.example.com" port="6514"
#        protocol="tcp" StreamDriver="ossl" StreamDriverMode="1"
#        StreamDriverAuthMode="x509/name"
#        StreamDriverPermittedPeers="logs.example.com")

上の断片は公式ドキュメントの書式に合わせた例で、実行はしていません。最初の設定の行はメールとauthpriv以外のinfo以上を1つのファイルに書き、3つ目の行はlocal0のerrだけを分けます。後半はomfwdでlocal0のwarning以上をTCPで送る書き方です。omfwdはprotocolを書かなければUDP、portを書かなければ514を使い、TCPで送るときは送り先が止まっても詰まらないようキューを定義するよう勧めています。^*7

systemdで動くLinuxでは、ログはまずsystemd-journaldが受け取ります。ForwardToSyslog=は、そのログをソケット経由でsyslogデーモンへ渡す設定です。ただしmanは、syslogデーモンの多くはjournalのファイルを直接読むので、関係するのはStorage=のほうだと書いています。^*8

つまずきやすい点

現場でよく問題になるのは次の5つです。

• UDPでは届かなくても気づけない：消失を見つける仕組みも再送も無く、途中で捨てられても送り手には分かりません
• 時刻とタイムゾーンの表記が揃わない：RFC 3164の時刻は年もタイムゾーンも持たず、RFC 5424の形式と混ざると、集めた側で並べたときに前後がずれます
• メッセージの長さに上限がある：RFC 5424では、受け手が受け付けるべき長さは480オクテット以上、できれば2048オクテットまでで、長すぎるものは末尾から切り詰めるか捨ててよいとされています^*1
• 平文のまま送ると中身が見える：RFC 3164のsyslogには転送中の中身を秘匿する仕組みが無く、パスワードや個人情報をログに出さないことと、TLSで送ることの両方が要ります
• 重大度の付け方が人によってばらばら：番号の意味は参考の扱いで、どの出来事をerrにするかは書いた人の判断に任されています

UDPで大きなメッセージを送ると、IPの断片化が起き、断片を1つ失っただけでメッセージ全体が失われます。RFC 5426は、経路のMTUが分からないときは、IPv4で480オクテット、IPv6で1180オクテットに収めるのが無難だとしています。^*3 スタックトレースのような長い記録は、途中で切れる前提で出し方を考えます。

名前の揺れにも気をつけます。rsyslogのドキュメントではsecurityはauthと同じ扱いですが、PythonのSysLogHandlerではsecurityは13番です。またSysLogHandlerは、標準の5つ以外のレベル名をすべてwarningとして送ります。重大度は、チームで出来事との対応表を作り、レビューで見るのが確実です。

外部に委託するときに確認しておきたい点

syslogの見直しを外部に頼むときは、ログを出す機械とアプリケーション、ファシリティと重大度の割り当て、送り先までの経路と方式（UDP・TCP・TLS）を先に書き出しておきます。委託先には、届かなかったログの見つけ方（送った件数と届いた件数の照合、キューの滞留の監視など）、時刻とタイムゾーンの揃え方、TLSの証明書の更新、設定の変更を検証用の環境で確かめる手順を、提案の段階で説明してもらいます。

集めたログをどれだけ残すかは「保存期間とローテーション運用」、不正の検知は「WazuhでOSS SIEM監視基盤を外注構築」、操作の証跡は「監査ログとは」で扱っています。

まとめ：syslogで確かめておきたい3つの点

syslogで確かめておきたい点は3つです。第一に、ファシリティと重大度の割り当てで、番号の意味は参考の扱いなので、どの出来事にどの番号を付けるかをチームで決めます。第二に、メッセージの形式で、年もタイムゾーンも持たないRFC 3164から、UTCからの時差を含むRFC 5424に揃えられるかを確かめます。第三に、転送の方式で、UDPの514番は届かなくても気づけず中身も平文なので、経路ごとにTCPやTLSの6514番とキューを検討します。

よくある質問

出典

1. *1　参考：IETF「RFC 5424 The Syslog Protocol」（https://www.rfc-editor.org/rfc/rfc5424）。出典：ファシリティ（0〜23）と重大度（0〜7）の表、PRIの計算、メッセージの形式（HEADER・STRUCTURED-DATA・MSG）、メッセージの長さ、例のメッセージを参照（2026年10月確認）
2. *2　参考：IETF「RFC 3164 The BSD syslog Protocol」（https://www.rfc-editor.org/rfc/rfc3164）。出典：情報提供の文書である旨、PRI・HEADER・MSGの3部構成と1024バイトの上限、時刻の形式、例のメッセージを参照（2026年10月確認）
3. *3　参考：IETF「RFC 5426 Transmission of Syslog Messages over UDP」（https://www.rfc-editor.org/rfc/rfc5426）。出典：1データグラム1メッセージ、UDPポート514、消失の検出と再送の仕組みが無いこと、メッセージの長さと断片化を参照（2026年10月確認）
4. *4　参考：IETF「RFC 5425 Transport Layer Security (TLS) Transport Mapping for Syslog」（https://www.rfc-editor.org/rfc/rfc5425）。出典：TCPポート6514、TLSが担う秘匿・改ざんの検出・認証と、区間ごとの保護であることを参照（2026年10月確認）
5. *5　参考：IETF「RFC 6587 Transmission of Syslog Messages over TCP」（https://www.rfc-editor.org/rfc/rfc6587）。出典：Historicの扱い、2つのフレーミングの方式、素のTCPを勧めないIESGの注記を参照（2026年10月確認）
6. *6　参考：rsyslog documentation「Filter Conditions」（https://www.rsyslog.com/doc/configuration/filters.html）。出典：セレクタ（facility.priority）の書き方、*・none・カンマ・セミコロン・=・!の意味、securityとauthの扱いを参照（2026年10月確認）
7. *7　参考：rsyslog documentation「omfwd: syslog Forwarding Output Module」（https://www.rsyslog.com/doc/configuration/modules/omfwd.html）。出典：TCPとTLSによる転送の例、キューの定義の勧め、protocolとportの既定値（同ドキュメントのBasic Parameters）を参照（2026年10月確認）
8. *8　参考：systemd「journald.conf(5)」（man7.orgの転載版）（https://man7.org/linux/man-pages/man5/journald.conf.5.html）。出典：ForwardToSyslog=の説明と、従来のsyslogデーモンへの2つの受け渡し方を参照（2026年10月確認）
9. *9　参考：Python 3 documentation「logging.handlers — Logging handlers」（https://docs.python.org/3/library/logging.handlers.html）。出典：SysLogHandlerの既定の送り先、NULバイトの付加、mapPriorityの変換を参照（2026年10月確認）

Tweet