syslog
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/11/14 15:24 UTC 版)
| 作者 | エリック・オールマン |
|---|---|
| 初版 | 1980年代 |
| 対応OS | Unix系 |
| 種別 | システムログ記録 |
| 公式サイト |
datatracker |
システム管理やセキュリティ監査の目的だけでなく、一般的な情報提供、分析、デバッグ用にも用いられる。多くのプラットフォームで、プリンタ、ルータ、メッセージレシーバなど、様々なデバイスがsyslog規格を使用している。これにより、異なるタイプのシステムからのログデータを1つの集中リポジトリで一括して管理することができる。syslogの実装は、多くのオペレーティングシステムで行われている。 ネットワーク上で動作する場合、syslogはクライアントサーバモデルを採用している。受信側（サーバ）は一般に"syslogd"、"syslogデーモン"、"syslogサーバ" などと呼ばれる。クライアントは1024バイト以下の短いテキストメッセージをサーバに送信する。syslogメッセージはUDPまたはTCP上で送信される。送信されるデータは一般にクリアテキストであるが、Stunnel、sslio、sslwrap といった SSL ラッパーを使って SSL/TLS による暗号化が可能である。
歴史
syslogは、1980年代にエリック・オールマンによってsendmailプロジェクトの一環として開発された[1]。以降、他のアプリケーションでも採用されるようになり、現在ではUnix系システムの標準的なログ記録方式となっている[2]。その他のOSでも実装されており、ルータなどのネットワーク機器にもよく搭載されている[3]。
長らくデファクトスタンダードであって、何らかの規格があるわけではなく、個々の実装には非互換も存在していた。セキュリティ強化のため、IETFはsyslogワーキンググループを結成した。2001年、syslogの現状をまとめて文書化したRFC 3164が発表された。その後、2009年にRFC 5424で標準化された[4]。
様々な企業が、syslogの実装について特許を主張しようとしたが[5][6]、プロトコルの利用と標準化にはあまり影響を及ぼさなかった。
syslogメッセージの構成要素
syslogメッセージの発信者から提供される情報には、ファシリティコードと重大度レベルが含まれる。syslogソフトウェアは、エントリを受信側に渡す前に、情報ヘッダに情報を追加する。情報ヘッダには、元の送信者のプロセスID、タイムスタンプ、デバイスのホスト名またはIPアドレスが含まれる。
ファシリティコード
ファシリティコード(facility code)は、メッセージを記録するシステムの種類を指定するために使用される。ファシリティコードにより、受信側で処理方法が変わる可能性がある[7]。規格で定義された利用可能なファシリティコードは、以下の通りである[4]:9。
| ファシリティコード | キーワード | 説明 |
|---|---|---|
| 0 | kern | カーネルメッセージ |
| 1 | user | ユーザレベルメッセージ |
| 2 | メールシステム | |
| 3 | daemon | システムデーモン |
| 4 | auth | セキュリティ/認証メッセージ |
| 5 | syslog | syslogdが内部で生成したメッセージ |
| 6 | lpr | ラインプリンタ・サブシステム |
| 7 | news | ネットニューズ・サブシステム |
| 8 | uucp | UUCPサブシステム |
| 9 | cron | Cronサブシステム |
| 10 | authpriv | セキュリティ/認証メッセージ |
| 11 | ftp | FTPデーモン |
| 12 | ntp | NTPサブシステム |
| 13 | security | ログ監査 |
| 14 | console | ログ警告 |
| 15 | solaris-cron | スケジューラ・デーモン |
| 16–23 | local0 – local7 | ローカル使用のファシリティコード |
ファシリティコードとキーワードの対応は、OSやsyslogの実装によっては異なる場合がある[8]。
重大度レベル
規格で定義された重大度レベル(severity level)は以下の通りである[4]:10。
| 値 | 重大度 | キーワード | 非推奨 キーワード |
説明 | 状態 |
|---|---|---|---|---|---|
| 0 | Emergency | emerg |
panic[9] |
システム使用不可 | パニック状態[10]。 |
| 1 | Alert | alert |
早急な対処が必要 | システムのデータベースが破損しているなど、すぐに修正すべき状態[10]。 | |
| 2 | Critical | crit |
致命的な状態 | ハードデバイスのエラー[10]。 | |
| 3 | Error | err |
error[9] |
エラー状態 | |
| 4 | Warning | warning |
warn[9] |
警告状態 | |
| 5 | Notice | notice |
正常だが注意が必要な状態 | エラー状態ではないが、特別な処理を必要とする可能性のある状態[10]。 | |
| 6 | Informational | info |
通知メッセージ | プログラムが期待通りに動作していることの確認。 | |
| 7 | Debug | debug |
デバッグメッセージ | 通常、プログラムのデバッグ時にのみ使用される情報を含むメッセージ[10]。 |
EmergencyとDebug以外の重大度レベルの意味は、アプリケーションにより異なる。例えば、顧客の口座残高情報を更新するためのトランザクションを処理するシステムであれば、最終段階でのエラーにはAlertレベルを割り当てるべきである。しかし、顧客の郵便番号を表示しようとした際に発生したエラーならば、ErrorやWarningレベルで十分である。
通常、サーバ側でメッセージの表示を行うときにある重大度レベルでフィルタリングを行う場合、それより重大な重大度レベルのエントリも含めて表示する。例えば、Notice、Info、Debugのメッセージをフィルタリングする際にはWarningレベルのエントリも含まれる[11]。
メッセージ
RFC 3164では、メッセージ・コンポーネント（measge component、MSGと略称される）は、メッセージを生成したプログラムやプロセスの名前であるTAGと、メッセージの詳細を含むCONTENTの2つのフィールドで構成されると規定されている。
RFC 5424[12]には、「MSGは、RFC 3164でCONTENTと呼ばれていたものである。TAGはヘッダの一部になったが、単一のフィールドではない。TAGはAPP-NAME、PROCID、MSGIDに分割されている。これはTAGの使い方と完全には似ていないが、ほとんどの場合同じ機能を提供する」と書かれている。rsyslogなどの一般的なシスログツールは、この新規格に準拠している。
コンテンツフィールドは、UTF-8の文字セットでエンコードし、ASCIIにおける制御文字の範囲のオクテット値は避けるべきである[13][14]。
- ^ “Eric Allman”. Internet Hall of Fame. 2017年10月30日閲覧。
- ^ “3 great engineering roles to apply for this week” (英語). VentureBeat (2021年8月6日). 2021年8月16日閲覧。
- ^ “Efficient and Robust Syslog Parsing for Network Devices in Datacenter Networks”. 2021年11月17日閲覧。
- ^ a b c Gerhards, Rainer. The Syslog Protocol (英語). doi:10.17487/RFC5424. RFC 5424。
- ^ “LXer: Patent jeopardizes IETF syslog standard”. 2021年11月17日閲覧。
- ^ “IETF IPR disclosure on HUAWEI's patent claims”. 2021年11月17日閲覧。
- ^ “Syslog Facility”. 2012年11月22日閲覧。
- ^ “The Ins and Outs of System Logging Using Syslog”. SANS Institute. 2010年4月15日時点のオリジナルよりアーカイブ。2021年11月17日閲覧。
- ^ a b c “syslog.conf(5) - Linux man page”. 2017年3月29日閲覧。
- ^ a b c d e “closelog, openlog, setlogmask, syslog - control system log”. 2017年3月29日閲覧。
- ^ “Severity Levels for Syslog Messages”. docs.delphix.com. 2021年8月16日閲覧。
- ^ Gerhards, Rainer (2009年3月). “RFC [https://datatracker.ietf.org/doc/html/rfc5424 5424 - The Syslog Protocol]”. 2021年11月17日閲覧。 “This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer.”
- ^ Transmission of Syslog Messages over TCP (英語). RFC 6587。
{{citation}}:|access-date=を指定する場合、|url=も指定してください。 (説明) - ^ “rfc5424”. datatracker.ietf.org. 2021年8月16日閲覧。
- ^ “logger Command” (英語). www.ibm.com. 2021年8月16日閲覧。
- ^ “Syslog Server”. www.howtonetwork.com. 2021年8月16日閲覧。
- ^ “RFC 5424 - The Syslog Protocol”. 2021年11月17日閲覧。
- ^ “RFC 5425 - TLS Transport Mapping for Syslog”. 2021年11月17日閲覧。
- ^ “ATNA + SYSLOG is good enough”. Healthcare Exchange Standards (2012年1月2日). 2018年6月6日閲覧。
- ^ Yamanishi, Kenji; Maruyama, Yuko (2005-08-21). “Dynamic syslog mining for network failure monitoring”. Proceedings of the eleventh ACM SIGKDD international conference on Knowledge discovery in data mining. KDD '05 (Chicago, Illinois, USA: Association for Computing Machinery): 499–508. doi:10.1145/1081870.1081927. ISBN 978-1-59593-135-1.
- ^ “Security Issues in Network Event Logging (syslog)”. IETF. 2021年11月17日閲覧。
- 1 syslogとは
- 2 syslogの概要
- 3 ロガー
- 4 規格文書
- 5 外部リンク
固有名詞の分類
- syslogのページへのリンク
