सिसलॉग: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Infobox software | {{Infobox software | ||
| name = Syslog | | name = Syslog | ||
| Line 22: | Line 20: | ||
| license = | | license = | ||
}} | }} | ||
[[कम्प्यूटिंग]] में, सिसलॉग [[बोटा दस्तावेज|संदेश संलेखन]] के लिए मानक है। यह उस सॉफ़्टवेयर को अलग करने की अनुमति देता है जो संदेश उत्पन्न करता | [[कम्प्यूटिंग]] में, सिसलॉग [[बोटा दस्तावेज|संदेश संलेखन]] के लिए मानक है। यह उस सॉफ़्टवेयर को अलग करने की अनुमति देता है जो संदेश उत्पन्न करता है। प्रणाली जो उन्हें संग्रह ीत करता है और सॉफ़्टवेयर जो उन्हें प्रतिवेदन और विश्लेषण करता है। प्रत्येक संदेश को सुविधा संग्रह के साथ सामान्य किया जाता है, जो संदेश उत्पन्न करने वाले प्रणाली के प्रकार को दर्शाता है और गंभीरता स्तर निर्दिष्ट किया जाता है। | ||
कंप्यूटर | कंप्यूटर प्रणाली चित्रकार प्रणाली प्रबंधन और सुरक्षा अंकेक्षण के साथ-साथ सामान्य सूचनात्मक, विश्लेषण और डिबगिंग संदेशों के लिए सिसलॉग का उपयोग कर सकते हैं। उपकरणों की विस्तृत विविधता जैसे मुद्रक, अनुर्मागण और कई प्लेटफॉर्म पर संदेश प्राप्तकर्ता, सिसलॉग मानक का उपयोग करते हैं। यह केंद्रीय भंडार में विभिन्न प्रकार के प्रणाली से लॉगिंग डेटा के समेकन की अनुमति देता है। कई क्रिया संचालन प्रणाली के लिए सिसलॉग का कार्यान्वयन उपस्तिथ है। | ||
नेटवर्क पर काम करते समय, सिसलॉग [[ग्राहक सर्वर]] आर्किटेक्चर का उपयोग करता है, जहाँ सिसलॉग सर्वर | नेटवर्क पर काम करते समय, सिसलॉग [[ग्राहक सर्वर]] आर्किटेक्चर का उपयोग करता है, जहाँ सिसलॉग सर्वर ग्राहक से आने वाले संदेशों को सुनता है और लॉग करता है। | ||
== इतिहास == | == इतिहास == | ||
सिसलॉग को 1980 के दशक में [[Sendmail]] प्रोजेक्ट के हिस्से के रूप में | सिसलॉग को 1980 के दशक में [[Sendmail|मेल भेजने]] प्रोजेक्ट के हिस्से के रूप में एरिक एलमैन द्वारा विकसित किया गया था।<ref>{{cite web |url=https://www.internethalloffame.org/inductees/eric-allman |title=Eric Allman |publisher=[[Internet Hall of Fame]] |access-date=2017-10-30}}</ref> इसे अन्य अनुप्रयोगों द्वारा आसानी से अपनाया गया था और तब से यह यूनिक्स जैसी प्रणालियों पर मानक लॉगिंग समाधान बन गया है।<ref>{{Cite web|date=2021-08-06|title=3 great engineering roles to apply for this week|url=https://venturebeat.com/2021/08/06/3-great-engineering-roles-to-apply-for-this-week/|access-date=2021-08-16|website=VentureBeat|language=en-US}}</ref> अन्य क्रिया संचालन प्रणाली पर भी विभिन्न प्रकार के कार्यान्वयन उपस्तिथ हैं और यह सामान्यतः [[राउटर (कंप्यूटिंग)|अनुर्मागण (कंप्यूटिंग)]] जैसे नेटवर्क उपकरणों में पाया जाता है।<ref>{{Cite web|title=Efficient and Robust Syslog Parsing for Network Devices in Datacenter Networks|url=https://www.researchgate.net/publication/339174356|url-status=live}}</ref> | ||
सिसलॉग मूल रूप से [[वास्तविक मानक]] के रूप में कार्य करता था, बिना किसी आधिकारिक प्रकाशित विनिर्देश के, और कई कार्यान्वयन | सिसलॉग मूल रूप से [[वास्तविक मानक]] के रूप में कार्य करता था, बिना किसी आधिकारिक प्रकाशित विनिर्देश के, और कई कार्यान्वयन उपस्तिथ थे, जिनमें से कुछ असंगत थे। [[इंटरनेट इंजीनियरिंग टास्क फोर्स]] ने 2001 के अगस्त में RFC 3164 में यथास्थिति का दस्तावेजीकरण किया। इसे 2009 के मार्च में RFC 5424 द्वारा मानकीकृत किया गया था।<ref name="RFC 5425">{{Cite IETF |rfc=5424 |last=Gerhards |first=Rainer |title=The Syslog Protocol}}</ref> | ||
विभिन्न कंपनियों ने सिसलॉग कार्यान्वयन के विशिष्ट पहलुओं के लिए पेटेंट का दावा करने का प्रयास किया है।<ref>{{cite web|url=http://lxer.com/module/newswire/view/64026/index.html|title=LXer: Patent jeopardizes IETF syslog standard}}</ref><ref>{{cite web|url=http://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=724|title=IETF IPR disclosure on HUAWEI's patent claims}}</ref> प्रोटोकॉल के उपयोग और मानकीकरण पर इसका बहुत कम प्रभाव पड़ा है।{{cn|date=August 2016}} | विभिन्न कंपनियों ने सिसलॉग कार्यान्वयन के विशिष्ट पहलुओं के लिए पेटेंट का दावा करने का प्रयास किया है।<ref>{{cite web|url=http://lxer.com/module/newswire/view/64026/index.html|title=LXer: Patent jeopardizes IETF syslog standard}}</ref><ref>{{cite web|url=http://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=724|title=IETF IPR disclosure on HUAWEI's patent claims}}</ref> प्रोटोकॉल के उपयोग और मानकीकरण पर इसका बहुत कम प्रभाव पड़ा है।{{cn|date=August 2016}} | ||
== संदेश घटक == | == संदेश घटक == | ||
सिसलॉग संदेश के प्रवर्तक द्वारा प्रदान की गई जानकारी में सुविधा | सिसलॉग संदेश के प्रवर्तक द्वारा प्रदान की गई जानकारी में सुविधा संग्रह और गंभीरता स्तर शामिल हैं। सिसलॉग सॉफ्टवेयर सिसलॉग प्राप्तकर्ता में प्रवेश करने से पहले सूचना शीर्षलेख में जानकारी जोड़ता है। ऐसे घटकों में प्रवर्तक प्रक्रिया आईडी, [[TIMESTAMP]] और डिवाइस का होस्टनाम या आईपी पता शामिल है। | ||
=== सुविधा === | === सुविधा === | ||
सुविधा | सुविधा संग्रह का उपयोग प्रणाली के उस प्रकार को निर्दिष्ट करने के लिए किया जाता है जो संदेश लॉग कर रहा है. विभिन्न सुविधाओं वाले संदेशों को अलग तरीके से हैंडल किया जा सकता है।<ref>{{cite web|url=http://linux.die.net/man/3/syslog|access-date=22 November 2012|title=Syslog Facility}}</ref> उपलब्ध सुविधाओं की सूची मानक द्वारा वर्णित है:<ref name="RFC 5425"/>{{rp|9}} | ||
{| class="wikitable" | {| class="wikitable" | ||
| Line 80: | Line 78: | ||
| 16–23 || local0 – local7 || Locally used facilities | | 16–23 || local0 – local7 || Locally used facilities | ||
|} | |} | ||
अलग-अलग | अलग-अलग क्रिया संचालन प्रणाली और सिसलॉग कार्यान्वयन में सुविधा संग्रह और कीवर्ड के बीच मैपिंग समान नहीं है।<ref>{{cite web |url=http://www.sans.org/reading_room/whitepapers/logging/ins-outs-system-logging-syslog_1168 |title=The Ins and Outs of System Logging Using Syslog |publisher=[[SANS Institute]]}}</ref> | ||
| Line 106: | Line 104: | ||
| 7 || Debug || <code>debug</code> || || Debug-level messages || Messages that contain information normally of use only when debugging a program.<ref name="opengroupSyslog"/> | | 7 || Debug || <code>debug</code> || || Debug-level messages || Messages that contain information normally of use only when debugging a program.<ref name="opengroupSyslog"/> | ||
|} | |} | ||
आपातकाल और डिबग के अलावा अन्य गंभीरता स्तरों का अर्थ अनुप्रयोग के सापेक्ष है। उदाहरण के लिए, यदि | आपातकाल और डिबग के अलावा अन्य गंभीरता स्तरों का अर्थ अनुप्रयोग के सापेक्ष है। उदाहरण के लिए, यदि प्रणाली का उद्देश्य ग्राहक खाते की शेष राशि की जानकारी को अद्यतन करने के लिए लेन-देन को संसाधित करना है, तो अंतिम चरण में त्रुटि को अलर्ट स्तर निर्दिष्ट किया जाना चाहिए। हालाँकि, ग्राहक के [[ज़िप कोड|ज़िप]] संग्रह को प्रदर्शित करने के प्रयास में होने वाली त्रुटि को त्रुटि या चेतावनी स्तर भी सौंपा जा सकता है। | ||
सर्वर प्रक्रिया जो संदेशों के प्रदर्शन को संभालती है, | सर्वर प्रक्रिया जो संदेशों के प्रदर्शन को संभालती है, सामान्यतः सभी निचले (अधिक गंभीर) स्तर शामिल होते हैं जब कम गंभीर स्तरों के प्रदर्शन का अनुरोध किया जाता है। यानी, अगर संदेशों को अलग-अलग गंभीरता से अलग किया जाता है, तो सूचना, जानकारी और डीबग संदेशों के लिए फ़िल्टर करते समय चेतावनी स्तर की प्रविष्टि भी शामिल की जाएगी।<ref>{{Cite web|title=Severity Levels for Syslog Messages|url=https://docs.delphix.com/docs53/system-administration/system-monitoring/setting-syslog-preferences/severity-levels-for-syslog-messages|access-date=2021-08-16|website=docs.delphix.com}}</ref> | ||
| Line 123: | Line 121: | ||
}}</ref> MSG को RFC 3164 में CONTENT कहा जाता था। TAG अब हेडर का हिस्सा है, लेकिन फ़ील्ड के रूप में नहीं। TAG को APP-NAME, PROCID और MSGID में विभाजित किया गया है। यह पूरी तरह से TAG के उपयोग जैसा नहीं है, लेकिन अधिकांश मामलों के लिए समान कार्यक्षमता प्रदान करता है। लोकप्रिय सिसलॉग उपकरण जैसे कि रूपलॉग इस नए मानक के अनुरूप है। | }}</ref> MSG को RFC 3164 में CONTENT कहा जाता था। TAG अब हेडर का हिस्सा है, लेकिन फ़ील्ड के रूप में नहीं। TAG को APP-NAME, PROCID और MSGID में विभाजित किया गया है। यह पूरी तरह से TAG के उपयोग जैसा नहीं है, लेकिन अधिकांश मामलों के लिए समान कार्यक्षमता प्रदान करता है। लोकप्रिय सिसलॉग उपकरण जैसे कि रूपलॉग इस नए मानक के अनुरूप है। | ||
सामग्री फ़ील्ड को [[UTF-8]] वर्ण सेट में | सामग्री फ़ील्ड को [[UTF-8]] वर्ण सेट में एन्संग्रह किया जाना चाहिए और पारंपरिक ASCII#ASCII नियंत्रण वर्णों में ऑक्टेट मानों से बचना चाहिए।<ref>{{Cite web|title=Transmission of Syslog Messages over TCP|url=https://www.ipa.go.jp/security/rfc/RFC6587EN.html|access-date=2021-08-16|website=www.ipa.go.jp}}</ref><ref>{{Cite journal|title=rfc5424|url=https://datatracker.ietf.org/doc/html/rfc5424|access-date=2021-08-16|website=datatracker.ietf.org|date=March 2009|last1=Gerhards|first1=Rainer}}</ref> | ||
== लकड़हारा == | == लकड़हारा == | ||
जनरेट किए गए लॉग संदेशों को [[सिस्टम कंसोल]], फ़ाइलें, रिमोट सिसलॉग सर्वर या रिले सहित विभिन्न गंतव्यों के लिए निर्देशित किया जा सकता है। लॉग को संदेश भेजने के लिए अधिकांश कार्यान्वयन कमांड लाइन उपयोगिता प्रदान करते हैं, जिसे अक्सर लकड़हारा कहा जाता है, साथ ही [[सॉफ्टवेयर पुस्तकालय]] भी।<ref>{{Cite web|title=logger Command|url=https://www.ibm.com/docs/en/aix/7.2?topic=l-logger-command|access-date=2021-08-16|website=www.ibm.com|language=en-us}}</ref> | जनरेट किए गए लॉग संदेशों को [[सिस्टम कंसोल|प्रणाली कंसोल]], फ़ाइलें, रिमोट सिसलॉग सर्वर या रिले सहित विभिन्न गंतव्यों के लिए निर्देशित किया जा सकता है। लॉग को संदेश भेजने के लिए अधिकांश कार्यान्वयन कमांड लाइन उपयोगिता प्रदान करते हैं, जिसे अक्सर लकड़हारा कहा जाता है, साथ ही [[सॉफ्टवेयर पुस्तकालय]] भी।<ref>{{Cite web|title=logger Command|url=https://www.ibm.com/docs/en/aix/7.2?topic=l-logger-command|access-date=2021-08-16|website=www.ibm.com|language=en-us}}</ref> | ||
एकत्रित लॉग को प्रदर्शित और मॉनिटर करने के लिए | एकत्रित लॉग को प्रदर्शित और मॉनिटर करने के लिए ग्राहक एप्लिकेशन का उपयोग करने या लॉग फ़ाइल को सीधे प्रणाली पर एक्सेस करने की आवश्यकता होती है। बुनियादी कमांड लाइन उपकरण [[टेल (यूनिक्स)]] और [[पकड़]] हैं। लॉग सर्वर को नेटवर्क पर लॉग भेजने के लिए कॉन्फ़िगर किया जा सकता है (स्थानीय फ़ाइलों के अतिरिक्त)। कुछ कार्यान्वयनों में सिसलॉग संदेशों को फ़िल्टर करने और प्रदर्शित करने के लिए प्रतिवेदनिंग प्रोग्राम शामिल हैं। | ||
== नेटवर्क प्रोटोकॉल == | == नेटवर्क प्रोटोकॉल == | ||
नेटवर्क पर काम करते समय, सिसलॉग | नेटवर्क पर काम करते समय, सिसलॉग ग्राहक-सर्वर आर्किटेक्चर का उपयोग करता है जहां सर्वर ग्राहक से प्रोटोकॉल अनुरोधों के लिए प्रसिद्ध पोर्ट | प्रसिद्ध या पंजीकृत पोर्ट पर सुनता है। ऐतिहासिक रूप से नेटवर्क लॉगिंग के लिए सबसे आम ट्रांसपोर्ट लेयर प्रोटोकॉल [[डेटाग्राम प्रोटेकॉलका उपयोग करें]] (UDP) रहा है, जिसमें सर्वर पोर्ट 514 पर सुनता है।<ref>{{Cite web|title=Syslog Server|url=https://www.howtonetwork.com/technical/security-technical/syslog-server/|url-status=live|access-date=2021-08-16|website=www.howtonetwork.com}}</ref> क्योंकि यूडीपी में कंजेशन कंट्रोल मैकेनिज्म का अभाव है, [[प्रसारण नियंत्रण प्रोटोकॉल]] (टीसीपी) पोर्ट 6514 का उपयोग किया जाता है; [[परिवहन परत सुरक्षा]] कार्यान्वयन में भी आवश्यक है और सामान्य उपयोग के लिए अनुशंसित है।<ref>{{cite journal|url=https://tools.ietf.org/html/rfc5424#section-8.6|title=RFC 5424 - The Syslog Protocol|date=March 2009|last1=Gerhards|first1=Rainer|doi=10.17487/RFC5424 }}</ref><ref>{{cite journal|url=https://tools.ietf.org/html/rfc5425#section-7.1|title=RFC 5425 - TLS Transport Mapping for Syslog|date=March 2009|last1=Fuyou|first1=Miao|last2=Yuzhi|first2=Ma|last3=Salowey|first3=Joseph A.|editor-first1=F |editor-first2=Y |editor-first3=J |editor-last1=Miao |editor-last2=Ma |editor-last3=Salowey |doi=10.17487/RFC5425 }}</ref> | ||
== सीमाएं == | == सीमाएं == | ||
चूंकि प्रत्येक प्रक्रिया, एप्लिकेशन और | चूंकि प्रत्येक प्रक्रिया, एप्लिकेशन और क्रिया संचालन प्रणाली को स्वतंत्र रूप से लिखा गया था, इसलिए लॉग संदेश के पेलोड में थोड़ी एकरूपता है। इस कारण इसके स्वरूपण या सामग्री के बारे में कोई अनुमान नहीं लगाया जाता है। सिसलॉग संदेश स्वरूपित है (RFC 5424 ऑगमेंटेड बैकस-नौर फॉर्म (ABNF) परिभाषा देता है), लेकिन इसका MSG फ़ील्ड नहीं है। | ||
नेटवर्क प्रोटोकॉल सरल संचार है, जिसमें प्रवर्तक को वितरण को स्वीकार करने का कोई साधन नहीं है। | नेटवर्क प्रोटोकॉल सरल संचार है, जिसमें प्रवर्तक को वितरण को स्वीकार करने का कोई साधन नहीं है। | ||
| Line 141: | Line 139: | ||
== आउटलुक == | == आउटलुक == | ||
विभिन्न समूह ड्राफ्ट मानकों पर काम कर रहे हैं, जो कि केवल नेटवर्क और सुरक्षा इवेंट लॉगिंग से अधिक के लिए सिसलॉग के उपयोग का विवरण देते हैं, जैसे स्वास्थ्य देखभाल वातावरण में इसका प्रस्तावित अनुप्रयोग।<ref>{{cite web |url=https://healthcaresecprivacy.blogspot.com/2011/12/atna-syslog-is-good-enough.html |title=ATNA + SYSLOG is good enough |date=2 January 2012 |publisher=[[Healthcare Exchange Standards]] |access-date=2018-06-06}}</ref> | विभिन्न समूह ड्राफ्ट मानकों पर काम कर रहे हैं, जो कि केवल नेटवर्क और सुरक्षा इवेंट लॉगिंग से अधिक के लिए सिसलॉग के उपयोग का विवरण देते हैं, जैसे स्वास्थ्य देखभाल वातावरण में इसका प्रस्तावित अनुप्रयोग।<ref>{{cite web |url=https://healthcaresecprivacy.blogspot.com/2011/12/atna-syslog-is-good-enough.html |title=ATNA + SYSLOG is good enough |date=2 January 2012 |publisher=[[Healthcare Exchange Standards]] |access-date=2018-06-06}}</ref> | ||
सरबेंस-ऑक्सले अधिनियम, [[पीसीआई डीएसएस]], एचआईपीएए और कई अन्य जैसे विनियमों के लिए संगठनों को व्यापक सुरक्षा उपायों को लागू करने की आवश्यकता होती है, जिसमें अक्सर कई अलग-अलग स्रोतों से लॉग एकत्र करना और उनका विश्लेषण करना शामिल होता है। लॉग को समेकित करने में सिसलॉग प्रारूप प्रभावी साबित हुआ है, क्योंकि इन लॉग की | सरबेंस-ऑक्सले अधिनियम, [[पीसीआई डीएसएस]], एचआईपीएए और कई अन्य जैसे विनियमों के लिए संगठनों को व्यापक सुरक्षा उपायों को लागू करने की आवश्यकता होती है, जिसमें अक्सर कई अलग-अलग स्रोतों से लॉग एकत्र करना और उनका विश्लेषण करना शामिल होता है। लॉग को समेकित करने में सिसलॉग प्रारूप प्रभावी साबित हुआ है, क्योंकि इन लॉग की प्रतिवेदनिंग और विश्लेषण के लिए कई ओपन-सोर्स और मालिकाना उपकरण हैं। [[विंडोज इवेंट लॉग]] और अन्य लॉग प्रारूपों से सिसलॉग में रूपांतरण के लिए उपयोगिताएँ उपस्तिथ हैं। | ||
[[प्रबंधित सुरक्षा सेवा प्रदाता]] पैटर्न का पता लगाने और ग्राहकों को समस्याओं के प्रति सचेत करने के लिए विश्लेषणात्मक तकनीकों और कृत्रिम बुद्धिमत्ता एल्गोरिदम को लागू करने का प्रयास करते हैं।<ref>{{Cite journal|last1=Yamanishi|first1=Kenji|last2=Maruyama|first2=Yuko|date=2005-08-21|title=Dynamic syslog mining for network failure monitoring|url=https://doi.org/10.1145/1081870.1081927|journal=Proceedings of the Eleventh ACM SIGKDD International Conference on Knowledge Discovery in Data Mining|series=KDD '05|location=Chicago, Illinois, USA|publisher=Association for Computing Machinery|pages=499–508|doi=10.1145/1081870.1081927|isbn=978-1-59593-135-1|s2cid=5051532}}</ref> | [[प्रबंधित सुरक्षा सेवा प्रदाता]] पैटर्न का पता लगाने और ग्राहकों को समस्याओं के प्रति सचेत करने के लिए विश्लेषणात्मक तकनीकों और कृत्रिम बुद्धिमत्ता एल्गोरिदम को लागू करने का प्रयास करते हैं।<ref>{{Cite journal|last1=Yamanishi|first1=Kenji|last2=Maruyama|first2=Yuko|date=2005-08-21|title=Dynamic syslog mining for network failure monitoring|url=https://doi.org/10.1145/1081870.1081927|journal=Proceedings of the Eleventh ACM SIGKDD International Conference on Knowledge Discovery in Data Mining|series=KDD '05|location=Chicago, Illinois, USA|publisher=Association for Computing Machinery|pages=499–508|doi=10.1145/1081870.1081927|isbn=978-1-59593-135-1|s2cid=5051532}}</ref> | ||
Revision as of 12:52, 26 February 2023
| Original author(s) | Eric Allman |
|---|---|
| Initial release | 1980s |
| Operating system | Unix-like |
| Type | System logging |
कम्प्यूटिंग में, सिसलॉग संदेश संलेखन के लिए मानक है। यह उस सॉफ़्टवेयर को अलग करने की अनुमति देता है जो संदेश उत्पन्न करता है। प्रणाली जो उन्हें संग्रह ीत करता है और सॉफ़्टवेयर जो उन्हें प्रतिवेदन और विश्लेषण करता है। प्रत्येक संदेश को सुविधा संग्रह के साथ सामान्य किया जाता है, जो संदेश उत्पन्न करने वाले प्रणाली के प्रकार को दर्शाता है और गंभीरता स्तर निर्दिष्ट किया जाता है।
कंप्यूटर प्रणाली चित्रकार प्रणाली प्रबंधन और सुरक्षा अंकेक्षण के साथ-साथ सामान्य सूचनात्मक, विश्लेषण और डिबगिंग संदेशों के लिए सिसलॉग का उपयोग कर सकते हैं। उपकरणों की विस्तृत विविधता जैसे मुद्रक, अनुर्मागण और कई प्लेटफॉर्म पर संदेश प्राप्तकर्ता, सिसलॉग मानक का उपयोग करते हैं। यह केंद्रीय भंडार में विभिन्न प्रकार के प्रणाली से लॉगिंग डेटा के समेकन की अनुमति देता है। कई क्रिया संचालन प्रणाली के लिए सिसलॉग का कार्यान्वयन उपस्तिथ है।
नेटवर्क पर काम करते समय, सिसलॉग ग्राहक सर्वर आर्किटेक्चर का उपयोग करता है, जहाँ सिसलॉग सर्वर ग्राहक से आने वाले संदेशों को सुनता है और लॉग करता है।
इतिहास
सिसलॉग को 1980 के दशक में मेल भेजने प्रोजेक्ट के हिस्से के रूप में एरिक एलमैन द्वारा विकसित किया गया था।[1] इसे अन्य अनुप्रयोगों द्वारा आसानी से अपनाया गया था और तब से यह यूनिक्स जैसी प्रणालियों पर मानक लॉगिंग समाधान बन गया है।[2] अन्य क्रिया संचालन प्रणाली पर भी विभिन्न प्रकार के कार्यान्वयन उपस्तिथ हैं और यह सामान्यतः अनुर्मागण (कंप्यूटिंग) जैसे नेटवर्क उपकरणों में पाया जाता है।[3] सिसलॉग मूल रूप से वास्तविक मानक के रूप में कार्य करता था, बिना किसी आधिकारिक प्रकाशित विनिर्देश के, और कई कार्यान्वयन उपस्तिथ थे, जिनमें से कुछ असंगत थे। इंटरनेट इंजीनियरिंग टास्क फोर्स ने 2001 के अगस्त में RFC 3164 में यथास्थिति का दस्तावेजीकरण किया। इसे 2009 के मार्च में RFC 5424 द्वारा मानकीकृत किया गया था।[4] विभिन्न कंपनियों ने सिसलॉग कार्यान्वयन के विशिष्ट पहलुओं के लिए पेटेंट का दावा करने का प्रयास किया है।[5][6] प्रोटोकॉल के उपयोग और मानकीकरण पर इसका बहुत कम प्रभाव पड़ा है।[citation needed]
संदेश घटक
सिसलॉग संदेश के प्रवर्तक द्वारा प्रदान की गई जानकारी में सुविधा संग्रह और गंभीरता स्तर शामिल हैं। सिसलॉग सॉफ्टवेयर सिसलॉग प्राप्तकर्ता में प्रवेश करने से पहले सूचना शीर्षलेख में जानकारी जोड़ता है। ऐसे घटकों में प्रवर्तक प्रक्रिया आईडी, TIMESTAMP और डिवाइस का होस्टनाम या आईपी पता शामिल है।
सुविधा
सुविधा संग्रह का उपयोग प्रणाली के उस प्रकार को निर्दिष्ट करने के लिए किया जाता है जो संदेश लॉग कर रहा है. विभिन्न सुविधाओं वाले संदेशों को अलग तरीके से हैंडल किया जा सकता है।[7] उपलब्ध सुविधाओं की सूची मानक द्वारा वर्णित है:[4]: 9
| Facility code | Keyword | Description |
|---|---|---|
| 0 | kern | Kernel messages |
| 1 | user | User-level messages |
| 2 | Mail system | |
| 3 | daemon | System daemons |
| 4 | auth | Security/authentication messages |
| 5 | syslog | Messages generated internally by syslogd |
| 6 | lpr | Line printer subsystem |
| 7 | news | Network news subsystem |
| 8 | uucp | UUCP subsystem |
| 9 | cron | Cron subsystem |
| 10 | authpriv | Security/authentication messages |
| 11 | ftp | FTP daemon |
| 12 | ntp | NTP subsystem |
| 13 | security | Log audit |
| 14 | console | Log alert |
| 15 | solaris-cron | Scheduling daemon |
| 16–23 | local0 – local7 | Locally used facilities |
अलग-अलग क्रिया संचालन प्रणाली और सिसलॉग कार्यान्वयन में सुविधा संग्रह और कीवर्ड के बीच मैपिंग समान नहीं है।[8]
गंभीरता स्तर
गंभीरता की सूची भी मानक द्वारा वर्णित है:[4]: 10
| Value | Severity | Keyword | Deprecated keywords | Description | Condition |
|---|---|---|---|---|---|
| 0 | Emergency | emerg |
panic[9] |
System is unusable | A panic condition.[10] |
| 1 | Alert | alert |
Action must be taken immediately | A condition that should be corrected immediately, such as a corrupted system database.[10] | |
| 2 | Critical | crit |
Critical conditions | Hard device errors.[10] | |
| 3 | Error | err |
error[9] |
Error conditions | |
| 4 | Warning | warning |
warn[9] |
Warning conditions | |
| 5 | Notice | notice |
Normal but significant conditions | Conditions that are not error conditions, but that may require special handling.[10] | |
| 6 | Informational | info |
Informational messages | Confirmation that the program is working as expected. | |
| 7 | Debug | debug |
Debug-level messages | Messages that contain information normally of use only when debugging a program.[10] |
आपातकाल और डिबग के अलावा अन्य गंभीरता स्तरों का अर्थ अनुप्रयोग के सापेक्ष है। उदाहरण के लिए, यदि प्रणाली का उद्देश्य ग्राहक खाते की शेष राशि की जानकारी को अद्यतन करने के लिए लेन-देन को संसाधित करना है, तो अंतिम चरण में त्रुटि को अलर्ट स्तर निर्दिष्ट किया जाना चाहिए। हालाँकि, ग्राहक के ज़िप संग्रह को प्रदर्शित करने के प्रयास में होने वाली त्रुटि को त्रुटि या चेतावनी स्तर भी सौंपा जा सकता है।
सर्वर प्रक्रिया जो संदेशों के प्रदर्शन को संभालती है, सामान्यतः सभी निचले (अधिक गंभीर) स्तर शामिल होते हैं जब कम गंभीर स्तरों के प्रदर्शन का अनुरोध किया जाता है। यानी, अगर संदेशों को अलग-अलग गंभीरता से अलग किया जाता है, तो सूचना, जानकारी और डीबग संदेशों के लिए फ़िल्टर करते समय चेतावनी स्तर की प्रविष्टि भी शामिल की जाएगी।[11]
संदेश
RFC 3164 में, संदेश घटक (जिसे MSG के रूप में जाना जाता है) को इन क्षेत्रों के रूप में निर्दिष्ट किया गया था: TAG, जो उस प्रोग्राम या प्रक्रिया का नाम होना चाहिए जो संदेश उत्पन्न करता है, और सामग्री जिसमें संदेश का विवरण होता है।
आरएफसी 5424 में वर्णित,[12] MSG को RFC 3164 में CONTENT कहा जाता था। TAG अब हेडर का हिस्सा है, लेकिन फ़ील्ड के रूप में नहीं। TAG को APP-NAME, PROCID और MSGID में विभाजित किया गया है। यह पूरी तरह से TAG के उपयोग जैसा नहीं है, लेकिन अधिकांश मामलों के लिए समान कार्यक्षमता प्रदान करता है। लोकप्रिय सिसलॉग उपकरण जैसे कि रूपलॉग इस नए मानक के अनुरूप है।
सामग्री फ़ील्ड को UTF-8 वर्ण सेट में एन्संग्रह किया जाना चाहिए और पारंपरिक ASCII#ASCII नियंत्रण वर्णों में ऑक्टेट मानों से बचना चाहिए।[13][14]
लकड़हारा
जनरेट किए गए लॉग संदेशों को प्रणाली कंसोल, फ़ाइलें, रिमोट सिसलॉग सर्वर या रिले सहित विभिन्न गंतव्यों के लिए निर्देशित किया जा सकता है। लॉग को संदेश भेजने के लिए अधिकांश कार्यान्वयन कमांड लाइन उपयोगिता प्रदान करते हैं, जिसे अक्सर लकड़हारा कहा जाता है, साथ ही सॉफ्टवेयर पुस्तकालय भी।[15] एकत्रित लॉग को प्रदर्शित और मॉनिटर करने के लिए ग्राहक एप्लिकेशन का उपयोग करने या लॉग फ़ाइल को सीधे प्रणाली पर एक्सेस करने की आवश्यकता होती है। बुनियादी कमांड लाइन उपकरण टेल (यूनिक्स) और पकड़ हैं। लॉग सर्वर को नेटवर्क पर लॉग भेजने के लिए कॉन्फ़िगर किया जा सकता है (स्थानीय फ़ाइलों के अतिरिक्त)। कुछ कार्यान्वयनों में सिसलॉग संदेशों को फ़िल्टर करने और प्रदर्शित करने के लिए प्रतिवेदनिंग प्रोग्राम शामिल हैं।
नेटवर्क प्रोटोकॉल
नेटवर्क पर काम करते समय, सिसलॉग ग्राहक-सर्वर आर्किटेक्चर का उपयोग करता है जहां सर्वर ग्राहक से प्रोटोकॉल अनुरोधों के लिए प्रसिद्ध पोर्ट | प्रसिद्ध या पंजीकृत पोर्ट पर सुनता है। ऐतिहासिक रूप से नेटवर्क लॉगिंग के लिए सबसे आम ट्रांसपोर्ट लेयर प्रोटोकॉल डेटाग्राम प्रोटेकॉलका उपयोग करें (UDP) रहा है, जिसमें सर्वर पोर्ट 514 पर सुनता है।[16] क्योंकि यूडीपी में कंजेशन कंट्रोल मैकेनिज्म का अभाव है, प्रसारण नियंत्रण प्रोटोकॉल (टीसीपी) पोर्ट 6514 का उपयोग किया जाता है; परिवहन परत सुरक्षा कार्यान्वयन में भी आवश्यक है और सामान्य उपयोग के लिए अनुशंसित है।[17][18]
सीमाएं
चूंकि प्रत्येक प्रक्रिया, एप्लिकेशन और क्रिया संचालन प्रणाली को स्वतंत्र रूप से लिखा गया था, इसलिए लॉग संदेश के पेलोड में थोड़ी एकरूपता है। इस कारण इसके स्वरूपण या सामग्री के बारे में कोई अनुमान नहीं लगाया जाता है। सिसलॉग संदेश स्वरूपित है (RFC 5424 ऑगमेंटेड बैकस-नौर फॉर्म (ABNF) परिभाषा देता है), लेकिन इसका MSG फ़ील्ड नहीं है।
नेटवर्क प्रोटोकॉल सरल संचार है, जिसमें प्रवर्तक को वितरण को स्वीकार करने का कोई साधन नहीं है।
आउटलुक
विभिन्न समूह ड्राफ्ट मानकों पर काम कर रहे हैं, जो कि केवल नेटवर्क और सुरक्षा इवेंट लॉगिंग से अधिक के लिए सिसलॉग के उपयोग का विवरण देते हैं, जैसे स्वास्थ्य देखभाल वातावरण में इसका प्रस्तावित अनुप्रयोग।[19] सरबेंस-ऑक्सले अधिनियम, पीसीआई डीएसएस, एचआईपीएए और कई अन्य जैसे विनियमों के लिए संगठनों को व्यापक सुरक्षा उपायों को लागू करने की आवश्यकता होती है, जिसमें अक्सर कई अलग-अलग स्रोतों से लॉग एकत्र करना और उनका विश्लेषण करना शामिल होता है। लॉग को समेकित करने में सिसलॉग प्रारूप प्रभावी साबित हुआ है, क्योंकि इन लॉग की प्रतिवेदनिंग और विश्लेषण के लिए कई ओपन-सोर्स और मालिकाना उपकरण हैं। विंडोज इवेंट लॉग और अन्य लॉग प्रारूपों से सिसलॉग में रूपांतरण के लिए उपयोगिताएँ उपस्तिथ हैं।
प्रबंधित सुरक्षा सेवा प्रदाता पैटर्न का पता लगाने और ग्राहकों को समस्याओं के प्रति सचेत करने के लिए विश्लेषणात्मक तकनीकों और कृत्रिम बुद्धिमत्ता एल्गोरिदम को लागू करने का प्रयास करते हैं।[20]
इंटरनेट मानक दस्तावेज़
सिसलॉग प्रोटोकॉल को इंटरनेट इंजीनियरिंग टास्क फोर्स (इंटरनेट मानकों) द्वारा प्रकाशित टिप्पणियों के लिए अनुरोध (RFC) दस्तावेजों द्वारा परिभाषित किया गया है। निम्नलिखित RFC की सूची है जो सिसलॉग प्रोटोकॉल को परिभाषित करती है:[21]