コンピューティングにおいて、syslog（/ ˈ s ɪ s l ɒ ɡ / ）はメッセージログの標準規格です。syslogは、メッセージを生成するソフトウェア、メッセージを保存するシステム、そしてメッセージを報告・分析するソフトウェアを分離することを可能にします。各メッセージには、メッセージを生成したシステムの種類を示すファシリティコードが付与され、重大度レベルが割り当てられます。
コンピュータシステム設計者は、システム管理やセキュリティ監査、そして一般的な情報、分析、デバッグメッセージにsyslogを使用できます。プリンタ、ルーター、メッセージレシーバーなど、様々なプラットフォームのデバイスがsyslog標準を使用しています。これにより、異なる種類のシステムからのログデータを中央リポジトリに統合できます。syslogの実装は、多くのオペレーティングシステムに存在します。
ネットワーク上で動作する場合、syslog はクライアント サーバーアーキテクチャを使用し、 syslog サーバーがクライアントからのメッセージをリッスンして記録します。
Syslogは、1980年代にEric AllmanによってSendmailプロジェクトの一環として開発されました。[ 1 ]他のアプリケーションにも容易に採用され、それ以来Unix系システムの標準的なログソリューションとなっています。[ 2 ]他のオペレーティングシステムにもさまざまな実装が存在し、ルーターなどのネットワークデバイスによく見られます。[ 3 ]
Syslogは当初、公式な仕様が公開されていないまま事実上の標準として機能し、多くの実装が存在し、その中には互換性のないものもありました。インターネット技術タスクフォースは、 2001年8月にRFC 3164で現状を文書化しました。その後、2009年3月にRFC 5424で標準化されました。[ 4 ]
様々な企業がsyslog実装の特定の側面について特許を主張しようと試みてきました。[ 5 ] [ 6 ]これはプロトコルの使用と標準化にほとんど影響を与えませんでした。
Syslogメッセージの発信元から提供される情報には、ファシリティコードと重大度レベルが含まれます。Syslogソフトウェアは、エントリをSyslog受信者に渡す前に、情報ヘッダーに情報を追加します。これらのコンポーネントには、発信元のプロセスID、タイムスタンプ、デバイスの ホスト名またはIPアドレスが含まれます。
ファシリティコードは、メッセージを記録しているシステムの種類を指定するために使用されます。異なるファシリティを持つメッセージは、異なる方法で処理される場合があります。[ 7 ]利用可能なファシリティのリストは、標準で次のように説明されています。[ 4 ] : 9
ファシリティコードとキーワードのマッピングは、オペレーティングシステムやSyslogの実装によって異なる場合があります。[ 8 ]
問題の重大度リストも規格に記載されています: [ 4 ] : 10
緊急とデバッグ以外の重大度レベルの意味は、アプリケーションによって異なります。例えば、システムの目的が顧客の口座残高情報を更新するためのトランザクション処理である場合、最終ステップで発生したエラーにはアラートレベルを割り当てる必要があります。一方、顧客の郵便番号を表示しようとする際に発生したエラーには、エラーレベル、あるいは警告レベルを割り当てることができます。
メッセージの表示を処理するサーバープロセスは、通常、より重大度の低いレベルの表示が要求された場合、より重大度の高いレベルのメッセージもすべて表示します。つまり、メッセージが個々の重大度で区切られている場合、Notice、Info、およびDebugメッセージをフィルタリングする際に、 Warningレベルのエントリも含まれることになります。[ 12 ]
RFC 3164では、メッセージコンポーネント（MSGと呼ばれる）は、メッセージを生成したプログラムまたはプロセスの名前であるTAGフィールドと、メッセージの詳細を含む CONTENTフィールドを持つと規定されています
RFC 5424では、[ 4 ]「MSGはRFC 3164でCONTENTと呼ばれていたものです。TAGは現在ヘッダーの一部ですが、単一のフィールドではありません。TAGはAPP-NAME、PROCID、およびMSGIDに分割されています。これはTAGの使用法と完全に似ているわけではありませんが、ほとんどの場合同じ機能を提供します。」NXLog、Rsyslogなどの一般的なsyslogツールはこの新しい標準に準拠しています。
コンテンツフィールドはUTF-8文字セットでエンコードする必要があり、従来のASCII制御文字範囲内のオクテット値は避けるべきである。[ 13 ] [ 4 ]
生成されたログメッセージは、コンソール、ファイル、リモートsyslogサーバー、リレーなど、さまざまな宛先に送信される場合があります。ほとんどの実装では、ログにメッセージを送信するためのコマンドラインユーティリティ（多くの場合、ロガーと呼ばれます）とソフトウェアライブラリが提供されています。 [ 14 ]
収集されたログを表示および監視するには、クライアントアプリケーションを使用するか、システム上のログファイルに直接アクセスする必要があります。基本的なコマンドラインツールはtailとgrepです。ログサーバーは、ログをローカルファイルに加えてネットワーク経由で送信するように設定できます。一部の実装では、syslogメッセージをフィルタリングおよび表示するためのレポートプログラムが組み込まれています。
ネットワーク上で動作する場合、Syslogはクライアント・サーバー・アーキテクチャを採用しており、サーバーはクライアントからのプロトコル要求を既知のポートまたは登録済みポートで待ち受けます。歴史的に、ネットワークログ記録における最も一般的なトランスポート層プロトコルはユーザーデータグラムプロトコル（UDP）であり、サーバーはポート514で待ち受けていました。[ 15 ] UDPには輻輳制御メカニズムがないため、伝送制御プロトコル（TCP）のポート6514が使用されます。また、実装にはトランスポート層セキュリティ（TLS）も必須であり、一般的な使用にも推奨されています。[ 16 ] [ 17 ]
各プロセス、アプリケーション、オペレーティングシステムはそれぞれ独立して記述されているため、ログメッセージのペイロードにはほとんど統一性がありません。そのため、そのフォーマットや内容については想定されていません。syslogメッセージはフォーマットされています（RFC 5424では拡張バッカス・ナウア記法（ABNF）の定義が示されています）が、MSGフィールドはフォーマットされていません
ネットワーク プロトコルは単純通信であり、送信元に配信を確認する手段はありません。
様々なグループが、ネットワークやセキュリティイベントのログ記録だけでなく、医療環境における提案されたアプリケーションなど、Syslogの使用を詳述した標準草案の作成に取り組んでいます。[ 18 ]
サーベンス・オクスリー法、PCI DSS、HIPAAなど、多くの規制により、組織は包括的なセキュリティ対策を実施することが求められており、これには多くの場合、様々なソースからのログの収集と分析が含まれます。Syslog形式は、ログのレポート作成と分析のためのオープンソースおよび独自ツールが多数存在するため、ログの統合に効果的であることが実証されています。Windowsイベントログやその他のログ形式をSyslogに変換するユーティリティも存在します。
マネージドセキュリティサービスプロバイダーは、分析技術と人工知能アルゴリズムを適用してパターンを検出し、顧客に問題を警告しようとします。[ 19 ]
Syslogプロトコルは、インターネット技術タスクフォース（インターネット標準）が発行するRequest for Comments（RFC）文書によって定義されています。以下は、Syslogプロトコルを定義するRFCのリストです。[ 20 ]
キーワードerror、warn、panicは非推奨であり、今後は使用しないでください。
エラー状態ではないが、特別な処理が必要になる可能性がある状態。
このメッセージは、正常だが重要なイベントについて説明しています。