आपको Apigee Edge दस्तावेज़ दिख रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी
![](https://docs.apigee.com/static/api-platform/images/icon_policy_message-logging.jpg?hl=hi)
क्या
एपीआई रनटाइम एनवायरमेंट में समस्याओं को ट्रैक करने का सबसे अच्छा तरीका मैसेज को लॉग करना है. कस्टम मैसेज को लोकल डिस्क (सिर्फ़ प्राइवेट क्लाउड के लिए एज) या syslog में लॉग करने के लिए, अपने एपीआई पर MessageLogging नीति को अटैच और कॉन्फ़िगर किया जा सकता है.
सैंपल
सिज़लॉग
<MessageLogging name="LogToSyslog"> <Syslog> <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {request.queryparam.w}.</Message> <Host>logs-01.loggly.com</Host> <Port>514</Port> <Protocol>TCP</Protocol> <FormatMessage>true</FormatMessage> <DateFormat>yyyy-MM-dd'T'HH:mm:ss.SSSZ</DateFormat> </Syslog> <logLevel>ALERT</logLevel> </MessageLogging>
MessageLogging नीति का आम तौर पर इस्तेमाल, syslog खाते में लॉग इन करना है. syslog के लिए कॉन्फ़िगर किए जाने पर, एक एपीआई प्रॉक्सी, Apigee Edge से किसी रिमोट syslog सर्वर पर लॉग मैसेज को फ़ॉरवर्ड करेगा. आपके पास पहले से ही syslog सर्वर उपलब्ध होना चाहिए. अगर ऐसा नहीं है, तो Splunk, Sumo Logic, और Loggly जैसी सार्वजनिक लॉग मैनेजमेंट सेवाएं उपलब्ध हैं. तीसरे पक्ष की लॉग मैनेजमेंट सेवाओं को कॉन्फ़िगर करना देखें.
उदाहरण के लिए, मान लें कि आपको अनुरोध के हर उस मैसेज की जानकारी लॉग करनी होगी जो
आपके एपीआई को उपभोक्ता ऐप्लिकेशन से मिलता है. वैल्यू 3f509b58
, Loggly सेवा के लिए खास तौर पर
एक मुख्य वैल्यू दिखाती है. अगर आपके पास Loggly खाता है, तो Loggly की कुंजी बदलें. जनरेट होने वाले लॉग मैसेज की चार वैल्यू अपने-आप भर जाएंगी: संगठन, एपीआई
प्रॉक्सी, और लेन-देन से जुड़े एनवायरमेंट का नाम. साथ ही, अनुरोध के मैसेज पर
क्वेरी पैरामीटर की वैल्यू.
अगर आपके पास प्राइवेट क्लाउड डिप्लॉयमेंट के लिए Edge है, तो किसी फ़ाइल पर लॉग मैसेज भी लिखे जा सकते हैं.
TLS/एसएसएल पर Syslog
<MessageLogging name="LogToSyslog"> <Syslog> <Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {request.queryparam.w}.</Message> <Host>logs-01.loggly.com</Host> <Port>6514</Port> <Protocol>TCP</Protocol> <FormatMessage>true</FormatMessage> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <DateFormat>yyMMdd-HH:mm:ss.SSS</DateFormat> </Syslog> <logLevel>WARN</logLevel> </MessageLogging>
<SSLInfo>
ब्लॉक जोड़कर, TLS/एसएसएल से, मैसेज लॉग करने की सेवा देने वाली तीसरे पक्ष की कंपनियों को
मैसेज भेजे जा सकते हैं.
फ़ाइल रोटेशन: आकार
<MessageLogging name="LogPolicy"> <File> <Message>This is a test message. Message id : {request.header.messageid}</Message> <FileName>test.log</FileName> <FileRotationOptions rotateFileOnStartup="true"> <FileRotationType>SIZE</FileRotationType> <MaxFileSizeInMB>10</MaxFileSizeInMB> <MaxFilesToRetain>10</MaxFilesToRetain> </FileRotationOptions> </File> <logLevel>ERROR</logLevel> </MessageLogging>
फ़ाइल के साइज़ के हिसाब से फ़ाइल का रोटेशन.
फ़ाइल रोटेशन: समय
<MessageLogging name="LogPolicy"> <File> <Message>This is a test message. Message id : {request.header.messageid}</Message> <FileName>test.log</FileName> <FileRotationOptions rotateFileOnStartup="true"> <FileRotationType>TIME</FileRotationType> <RotationFrequency unit="minute">10</RotationFrequency> <MaxFilesToRetain>10</MaxFilesToRetain> </FileRotationOptions> </File> <logLevel>ERROR</logLevel> </MessageLogging>
समय के हिसाब से फ़ाइल का रोटेशन.
फ़ाइल रोटेशन: समय और साइज़
<MessageLogging name="LogPolicy"> <File> <Message>This is a test message. Message id : {request.header.messageid}</Message> <FileName>test.log</FileName> <FileRotationOptions rotateFileOnStartup="true"> <FileRotationType>TIME_SIZE</FileRotationType> <MaxFileSizeInMB>10</MaxFileSizeInMB> <MaxFilesToRetain>10</MaxFilesToRetain> <RotationFrequency unit="minute">10</RotationFrequency> </FileRotationOptions> </File> <logLevel>ERROR</logLevel> </MessageLogging>
समय और साइज़ के हिसाब से फ़ाइल का रोटेशन.
स्ट्रीम की सुविधा चालू है
<MessageLogging name="LogPolicy"> <File> .... .... </File> <BufferMessage>true</BufferMessage> </MessageLogging>
स्ट्रीम की सुविधा वाले मैसेज लॉग करने की सुविधा
एलिमेंट का रेफ़रंस
MessageLogging नीति टाइप को कॉन्फ़िगर करने के लिए, इन एलिमेंट का इस्तेमाल करें.
फ़ील्ड का नाम | फ़ील्ड का ब्यौरा | |
---|---|---|
लोकल फ़ाइल डेस्टिनेशन. (फ़ाइल लॉगिंग की सुविधा सिर्फ़ प्राइवेट क्लाउड डिप्लॉयमेंट के लिए Edge में काम करती है.) यह जानने के लिए कि फ़ाइलें कहां सेव की जाती हैं, Edge for Private Cloud में फ़ाइल की जगह की जानकारी देखें. |
Message |
अपनी ज़रूरत के हिसाब से जानकारी कैप्चर करने के लिए, टेक्स्ट को वैरिएबल के साथ जोड़कर, लॉग फ़ाइल पर भेजने के लिए मैसेज बनाएं. सैंपल देखें. |
FileName |
उस लॉग फ़ाइल का नाम जहां मैसेज लॉग किया गया है. | |
FileRotationOptions |
||
rotateFileOnStartup |
एट्रिब्यूट. मान्य वैल्यू: अगर इस नीति को 'सही है' पर सेट किया जाता है, तो मैसेज इंजन के रीस्टार्ट होने पर, लॉग फ़ाइल को हर बार घुमाया जाता है. |
|
FileRotationType |
लॉग फ़ाइल की रोटेशन नीति (size या
time ) के बारे में बताता है. |
|
MaxFileSizeInMB |
(size को रोटेशन टाइप के तौर पर चुनने पर)
उस लॉग फ़ाइल के साइज़ के बारे में बताता है जो लॉग मैसेज को
अलग फ़ाइल में ले जाने के लिए सर्वर को ट्रिगर करती है. लॉग फ़ाइल के तय साइज़ तक पहुंचने के बाद, सर्वर मौजूदा लॉग फ़ाइल का नाम बदल देता है. |
|
RotationFrequency |
(time को रोटेशन टाइप के तौर पर चुनने पर)
इससे मिनट में उस समय के बारे में पता चलता है जो लॉग मैसेज को किसी अलग फ़ाइल में ले जाने के लिए सर्वर को
ट्रिगर करता है. तय किया गया इंटरवल खत्म होने के बाद, मौजूदा लॉग फ़ाइल का नाम बदल दिया जाता है. |
|
MaxFilesToRetain |
इससे पता चलता है कि आपकी रोटेशन सेटिंग के हिसाब से, ज़्यादा से ज़्यादा कितनी फ़ाइलें सेव रखनी हैं. डिफ़ॉल्ट वैल्यू 8 है. शून्य (0) चुनने पर, लॉग फ़ाइलें हमेशा के लिए सेव रखी जाती हैं. हालांकि, यह आपकी फ़ाइल रोटेशन सेटिंग के हिसाब से होती है. हालांकि, कोई भी फ़ाइल न तो मिटाई जाती है और न ही उसका नाम बदला जाता है. इसलिए, आने वाले समय में डिस्क में भरी हुई गड़बड़ी से बचने के लिए, इसकी वैल्यू को शून्य से ज़्यादा पर सेट करें. इसके अलावा, सेव की गई पुरानी लॉग फ़ाइलों को पर्ज करने या संग्रहित करने के लिए, एक सामान्य, अपने-आप काम करने वाले सिस्टम का इस्तेमाल किया जा सकता है. |
|
BufferMessage |
अगर आपकी प्रॉक्सी के लिए एचटीटीपी स्ट्रीमिंग चालू है, तो अनुरोध/जवाब वाले मैसेज बफ़र नहीं होते. अगर आपको उस कॉन्टेंट को लॉग करना है जिसके लिए फ़्लो मैसेज को पार्स करना ज़रूरी है, तो बफ़र मैसेज को 'सही' पर सेट करें. उदाहरण के लिए, "स्ट्रीम की सुविधा वाला" सैंपल टैब देखें. डिफ़ॉल्ट: गलत |
|
एक syslog डेस्टिनेशन. Splunk, Sumo Logic या Loggly को syslog की जानकारी भेजने के लिए, तीसरे पक्ष की लॉग मैनेजमेंट सेवाओं को कॉन्फ़िगर करना देखें. |
Message |
आपको जो जानकारी चाहिए उसे कैप्चर करने के लिए, टेक्स्ट को वैरिएबल के साथ जोड़कर, syslog पर मैसेज भेजने के लिए एक मैसेज बनाएं. सैंपल देखें. ध्यान दें: गड़बड़ी का फ़्लो होने की वजह से, PostClientFlow में रिस्पॉन्स वैरिएबल उपलब्ध नहीं होंगे. गड़बड़ी और सफलता, दोनों की स्थितियों के लिए रिस्पॉन्स की जानकारी लॉग करने के लिए, मैसेज वैरिएबल का इस्तेमाल करें. इस्तेमाल से जुड़ी जानकारी भी देखें. |
Host |
उस सर्वर का होस्टनेम या आईपी पता जहां syslog भेजा जाना चाहिए. अगर इस एलिमेंट को शामिल नहीं किया जाता है, तो लोकल होस्ट डिफ़ॉल्ट तौर पर सेट हो जाता है. | |
Port |
पोर्ट वहां करें जहां syslog चल रहा है. अगर इस एलिमेंट को शामिल नहीं किया जाता है, तो 514 डिफ़ॉल्ट होता है. | |
Protocol |
टीसीपी या यूडीपी (डिफ़ॉल्ट). यूडीपी की परफ़ॉर्मेंस अच्छी होती है. हालांकि, टीसीपी प्रोटोकॉल, सिस्टम लॉग सर्वर को मैसेज लॉग डिलीवरी की गारंटी देता है. TLS/एसएसएल पर syslog मैसेज भेजने के लिए, सिर्फ़ टीसीपी काम करता है. | |
FormatMessage |
ज़रूरी नहीं है, लेकिन Loggly के साथ इस्तेमाल करने के लिए इस एलिमेंट की मदद से, मैसेज में पहले से जोड़े गए Apigee से जनरेट किए गए कॉन्टेंट के फ़ॉर्मैट को कंट्रोल किया जा सकता है. अगर नीति को 'सही है' पर सेट किया जाता है, तो syslog मैसेज को वर्णों की एक तय संख्या से पहले दिखाया जाता है. इससे, उस जानकारी को मैसेज में से फ़िल्टर किया जा सकता है. यहां तय फ़ॉर्मैट का एक उदाहरण दिया गया है:
Apigee से जनरेट की गई जानकारी में ये चीज़ें शामिल हैं:
अगर यह 'गलत' (डिफ़ॉल्ट) पर सेट है, तो मैसेज से पहले, तय किए गए वर्णों के बजाय कोई और वर्ण नहीं दिखाया जाएगा. |
|
PayloadOnly |
यह एलिमेंट, Apigee से जनरेट किए गए मैसेज के फ़ॉर्मैट को इस तरह सेट करता है कि उसमें सिर्फ़ syslog मैसेज का मुख्य हिस्सा शामिल किया जाए. इसमें FormatMessage से पहले से तय किए गए वर्ण शामिल नहीं किए जाते. अगर इस एलिमेंट को शामिल नहीं किया जाता या इसे खाली छोड़ दिया जाता है, तो डिफ़ॉल्ट वैल्यू FormatMessage देखें. |
|
DateFormat |
ज़रूरी नहीं. हर लॉग मैसेज के टाइमस्टैंप को फ़ॉर्मैट करने के लिए, फ़ॉर्मैट करने वाली टेंप्लेट स्ट्रिंग.
डिफ़ॉल्ट रूप से, Apigee, |
|
SSLInfo |
यह आपको एसएसएल/टीएलएस के ज़रिए मैसेज लॉग करने देता है. सब-एलिमेंट अगर इस एलिमेंट को शामिल नहीं किया जाता या इसे खाली छोड़ दिया जाता है, तो डिफ़ॉल्ट वैल्यू 'गलत' होती है (कोई TLS/एसएसएल नहीं). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <SSLInfo> टैग को ठीक उसी तरह कॉन्फ़िगर किया जा सकता है जिसे TargetEndpoint पर कॉन्फ़िगर किया जाता है. इसमें, दो-तरफ़ा TLS/एसएसएल चालू करना भी शामिल है, जैसा कि एपीआई प्रॉक्सी कॉन्फ़िगरेशन के रेफ़रंस में बताया गया है. इसमें सिर्फ़ टीसीपी प्रोटोकॉल काम करता है. |
|
logLevel |
ज़रूरी नहीं. मान्य वैल्यू: मैसेज लॉग में शामिल करने के लिए, जानकारी का एक खास लेवल सेट करें. अगर |
स्कीमा
ट्रैक के इस्तेमाल से जुड़ी जानकारी
किसी एपीआई प्रॉक्सी फ़्लो में MessageLogging नीति को अटैच करते समय, इसे प्रॉक्सीEndpoint रिस्पॉन्स में डालें. यह एक खास फ़्लो में होता है जिसे PostClientFlow कहते हैं. PostClientFlow, अनुरोध करने वाले क्लाइंट को जवाब भेजे जाने के बाद एक्ज़ीक्यूट करता है, जिससे यह पक्का होता है कि लॉगिंग के लिए सभी मेट्रिक उपलब्ध हैं. PostClientFlow का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, एपीआई प्रॉक्सी कॉन्फ़िगरेशन का रेफ़रंस देखें.
PostClientFlow दो तरीकों से खास है:
- इसे सिर्फ़ रिस्पॉन्स फ़्लो के हिस्से के तौर पर लागू किया जाता है.
- प्रॉक्सी के गड़बड़ी वाली स्थिति में जाने के बाद, सिर्फ़ यही फ़्लो लागू होता है.
इसलिए, प्रॉक्सी की प्रोसेस पूरी हुई है या नहीं, इस पर ध्यान दिए बिना इसे एक्ज़ीक्यूट किया जाता है. इसलिए, MessageLogging की नीतियों को PostClientFlow में रखा जा सकता है और इस बात की गारंटी दी जा सकती है कि ये हमेशा लागू होंगी.
नीचे दी गई ट्रेस इमेज में MessageLogging की नीति दिखाई गई है जिसे डिफ़ॉल्टFaultRule के लागू होने के बाद PostClientFlow के हिस्से के तौर पर लागू किया जाता है:
इस उदाहरण में, 'एपीआई पासकोड की पुष्टि करें' नीति की वजह से यह गड़बड़ी अमान्य पासकोड की वजह से हुई.
यहां प्रॉक्सीएंडपॉइंट की परिभाषा दी गई है, जिसमें PostClientFlow शामिल है:
<ProxyEndpoint name="default"> ... <PostClientFlow> <Response> <Step> <Name>Message-Logging-1</Name> </Step> </Response> </PostClientFlow> ... </ProxyEndpoint>
Edge, मैसेज को आसान टेक्स्ट के तौर पर लॉग करता है. साथ ही, वैरिएबल को शामिल करने के लिए लॉग इन को कॉन्फ़िगर किया जा सकता है. जैसे, अनुरोध या जवाब मिलने की तारीख और समय, अनुरोध पर उपयोगकर्ता की पहचान, अनुरोध करने वाले सोर्स का आईपी पता वगैरह. Edge लॉग मैसेज एसिंक्रोनस रूप से होता है. इसका मतलब है कि आपके एपीआई में, कॉलआउट को ब्लॉक करने की वजह से इंतज़ार का समय नहीं आ रहा है.
MessageLogging नीति, मेमोरी में लॉग किए गए मैसेज को बफ़र में लिखती है. मैसेज लॉगर बफ़र के मैसेज पढ़ता है और फिर कॉन्फ़िगर किए गए डेस्टिनेशन पर लिखता है. हर डेस्टिनेशन का अपना बफ़र होता है.
अगर बफ़र में लिखने की दर, पढ़ने की दर से ज़्यादा होती है, तो बफ़र ओवरफ़्लो और लॉगिंग नहीं हो पाएगी. अगर ऐसा होता है, तो आपको लॉग फ़ाइल में एक ऐसा मैसेज दिख सकता है जिसमें यह जानकारी शामिल हो:
Log message size exceeded. Increase the max message size setting
अगर आपको Edge for Private Cloud 4.15.07 और इससे पहले के वर्शन में यह समस्या मिलती है, तो
message-logging.properties
फ़ाइल ढूंढें और इसे ठीक करने के लिए यह तरीका इस्तेमाल करें:
message-logging.properties
फ़ाइल में max.log.message.size.in.kb
प्रॉपर्टी (डिफ़ॉल्ट वैल्यू = 128 केबी)
बढ़ाएं.
Edge के लिए Private Cloud 4.16.01 और इसके बाद के वर्शन के लिए, /opt/apigee/customer/application/message-processor.properties फ़ाइल में conf/message-logging.properties+max.
log.message.size.in.kb
प्रॉपर्टी को सेट करें. इसके बाद, मैसेज प्रोसेसर को रीस्टार्ट करें. कृपया ध्यान दें कि शुरुआत में इस प्रॉपर्टी पर डिफ़ॉल्ट रूप से टिप्पणी की जाती है.
ध्यान दें: Edge में रिस्पॉन्स मैसेज वैरिएबल, गड़बड़ी के फ़्लो से उपलब्ध नहीं होते. अगर पिछला फ़्लो, गड़बड़ी का फ़्लो था, तो PostClientFlow में भी ये वैरिएबल उपलब्ध नहीं होंगे. अगर आपको PostClientFlow से जवाब की जानकारी लॉग करनी है, तो message ऑब्जेक्ट का इस्तेमाल करें. इस ऑब्जेक्ट का इस्तेमाल, रिस्पॉन्स से हेडर और अन्य जानकारी पाने के लिए किया जा सकता है. भले ही, कोई गड़बड़ी हुई हो या नहीं. ज़्यादा जानकारी और उदाहरण के लिए, मैसेज वैरिएबल देखें.
प्राइवेट क्लाउड के लिए Edge में लॉग मैसेज का टाइमस्टैंप कंट्रोल करना
डिफ़ॉल्ट रूप से, सभी लॉग मैसेज के टाइमस्टैंप का फ़ॉर्मैट ऐसा होता है:
yyyy-MM-dd'T'HH:mm:ss.SSSZ
पूरे सिस्टम के लिए, इस डिफ़ॉल्ट सेटिंग को DateFormat
एलिमेंट का इस्तेमाल करके
syslog डेस्टिनेशन के लिए बदला जा सकता है. इस टेंप्लेट के व्यवहार के बारे में
Java की SimpleDateFormat क्लास के दस्तावेज़ में बताया गया है. उस परिभाषा के मुताबिक, yyyy
को चार अंकों के साल से बदल दिया जाएगा और MM
को दो अंकों वाले महीने से बदल दिया जाएगा. इसी तरह, अब और भी जारी होगा.
ऊपर दिए गए फ़ॉर्मैट का इस्तेमाल करने पर, इस फ़ॉर्म की एक स्ट्रिंग बन सकती है:
2022-09-28T22:38:11.721+0000
उस फ़ॉर्मैट को कंट्रोल करने के लिए, Edge मैसेज प्रोसेसर पर conf_system_apigee.syslogger.dateFormat का इस्तेमाल किया जा सकता है. उदाहरण के लिए, मैसेज का फ़ॉर्मैट बदलकर, यह करना:
yy/MM/dd'T'HH:mm:ss.SSSZ
..डैश को स्लैश से बदलकर, और साल को दो अंकों में छोटा करके, इस फ़ॉर्म में टाइमस्टैंप रिकॉर्ड किया जाता है:
22/09/28T22:38:11.721+0000
फ़ॉर्मैट बदलने के लिए:
- किसी एडिटर में message-processor.property फ़ाइल
खोलें. अगर फ़ाइल मौजूद नहीं है, तो इसे बनाएं:
> vi /opt/apigee/customer/application/message-processor.property - प्रॉपर्टी को अपने हिसाब से सेट करें:
conf_system_apigee.syslogger.dateFormat=yy/MM/dd'T'HH:mm:ss.SSSZ - बदलावों को सेव करें.
- पक्का करें कि प्रॉपर्टी फ़ाइल का मालिकाना हक 'apigee' उपयोगकर्ता के पास हो:
> chown apigee:apigee /opt/apigee/customer/application/message-processor.properties - Edge मैसेज प्रोसेसर को रीस्टार्ट करें:
> /opt/apigee/apigee-service/bin/apigee-service Edge-message-प्रोसेसर रीस्टार्ट
प्राइवेट क्लाउड के लिए Edge में फ़ाइल की जगह की जानकारी लॉग करें
प्राइवेट क्लाउड 4.16.01 और इसके बाद के वर्शन के लिए Edge
डिफ़ॉल्ट रूप से, निजी क्लाउड मैसेज लॉग, मैसेज प्रोसेसर नोड पर इस डायरेक्ट्री में मौजूद होते हैं:
/opt/apigee/var/log/edge-message-processor/messagelogging/org_name/environment/api_proxy_name/revision/logging_policy_name/
मैसेज प्रोसेसर पर, message-logging.property फ़ाइल में मौजूद प्रॉपर्टी में बदलाव करके, डिफ़ॉल्ट लॉग की जगह बदली जा सकती है:
- bin_setenv_data_dir -
लॉग फ़ाइल के स्टोरेज के लिए रूट पाथ सेट करता है. उदाहरण के लिए,
bin_setenv_data_dir=/opt/apigee/var/log
- conf_message-logging_log.root.dir - अगर
इसे किसी मिलते-जुलते पाथ पर सेट किया जाता है, जैसे कि
conf/message-logging.properties+log.root.dir=custom/folder/
, the path is appended to the bin_setenv_data_dir location.
अगर इसे ऐब्सलूट पाथ पर सेट किया जाता है, जैसे किconf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages
, तो मैसेज लॉग/opt/apigee/var/log/messages/messagelog/
में सेव किए जाएंगे. किसी ऐब्सलूट पाथ कोbin_setenv_data_dir
की जगह प्राथमिकता दी जाती है.
ध्यान दें कि आपको इस प्रॉपर्टी का रेफ़रंस conf/message-logging.properties+log.root.dir के तौर पर देना होगा, क्योंकि इस पर डिफ़ॉल्ट रूप से टिप्पणी की जाती है. ज़्यादा जानकारी के लिए, ऐसा टोकन सेट करना जिसके लिए फ़िलहाल टिप्पणी की गई है देखें.
अगर आपको लॉग फ़ाइलों को किसी फ़्लैट स्ट्रक्चर में सेव करना है, ताकि सभी लॉग फ़ाइलों को एक ही डायरेक्ट्री में रखा जा सके, तो message-logging.property फ़ाइल में, conf/message-logging.properties+enable.flat.directory.structured पर सेट करें. मैसेज, ऊपर दी गई प्रॉपर्टी के हिसाब से तय की गई डायरेक्ट्री में सेव किए जाते हैं. फ़ाइल के नाम {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}
का रूप लेते हैं.
इन प्रॉपर्टी को सेट करने के लिए:
- किसी एडिटर में message-processor.property फ़ाइल
खोलें. अगर फ़ाइल मौजूद नहीं है, तो इसे बनाएं:
> vi /opt/apigee/customer/application/message-processor.property - प्रॉपर्टी को अपने हिसाब से सेट करें:
conf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages - बदलावों को सेव करें.
- पक्का करें कि प्रॉपर्टी फ़ाइल का मालिकाना हक 'apigee' उपयोगकर्ता के पास हो:
> chown apigee:apigee /opt/apigee/customer/application/message-processor.properties - Edge कॉम्पोनेंट को रीस्टार्ट करें:
> /opt/apigee/apigee-service/bin/apigee-service Edge-message-प्रोसेसर रीस्टार्ट
प्राइवेट क्लाउड 4.15.07 और इससे पहले के वर्शन के लिए Edge
डिफ़ॉल्ट रूप से, मैसेज लॉग, मैसेज प्रोसेसर में नीचे दी गई जगह पर मौजूद होते हैं:
/opt/apigee4/var/log/apigee/message-processor/messagelog/{org}/{environment}/{api_proxy_name}/{revision}/{logging_policy_name}/
मैसेज प्रोसेसर पर, message-logging.properties फ़ाइल में, इन प्रॉपर्टी में बदलाव करके, डिफ़ॉल्ट लॉग की जगह बदली जा सकती है:
- data.dir - लॉग फ़ाइल के स्टोरेज के लिए रूट पाथ सेट करता है. उदाहरण के लिए, data.di=/opt/apigee4/var/log
- log.root.dir - अगर इसे किसी मिलते-जुलते पाथ पर सेट किया जाता है, जैसे कि log.root.mir=custom/फ़ोल्डर/ में, तो पाथ को data.ख़िलाफ़ की जगह से जोड़ दिया जाता है.
उदाहरण के लिए, दो प्रॉपर्टी का एक साथ इस्तेमाल होने पर, लॉगिंग डायरेक्ट्री /opt/apigee4/var/log/custom/Folder/messagelog/ पर सेट होगी (ध्यान दें कि /messagelog अपने-आप जुड़ जाएगा).
अगर इसे किसी ऐब्सलूट पाथ, जैसे कि log.root.dir=/opt/apigee4/var/log/messages पर सेट किया जाता है, तो मैसेज लॉग /opt/apigee4/var/log/messages/messagelog/ में सेव किए जाएंगे. data.dir के बजाय, Log.root.पिक्चर के ऐब्सलूट पाथ को प्राथमिकता दी जाती है.
अगर आपको लॉग फ़ाइलों को किसी फ़्लैट स्ट्रक्चर में सेव करना है, ताकि सभी लॉग फ़ाइलों को एक ही डायरेक्ट्री में रखा जा सके, तो मैसेज प्रोसेसर पर मौजूद message-logging.property फ़ाइल में enable.flat.directory.structured प्रॉपर्टी को 'सही' पर सेट करें. मैसेज, ऊपर दी गई प्रॉपर्टी के हिसाब से तय डायरेक्ट्री में सेव किए जाते हैं और फ़ाइल के नाम {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename} के तौर पर होते हैं.
मैसेज टेंप्लेट में वैरिएबल के लिए डिफ़ॉल्ट वैल्यू
मैसेज टेंप्लेट में, हर वैरिएबल के लिए अलग से डिफ़ॉल्ट वैल्यू तय की जा सकती है. उदाहरण के लिए, अगर request.header.id
वैरिएबल को हल नहीं किया जा सकता, तो उसकी वैल्यू को unknown
से बदल दिया जाता है.
<Message>This is a test message. id = {request.header.id:unknown}</Message>
Message
एलिमेंट पर
defaultVariableValue
एट्रिब्यूट सेट करके, उन सभी वैरिएबल के लिए एक सामान्य डिफ़ॉल्ट वैल्यू तय की जा सकती है जिन्हें हल नहीं किया गया है:
<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>
तीसरे पक्ष की लॉग मैनेजमेंट सेवाओं को कॉन्फ़िगर करना
MessageLogging नीति की मदद से, तीसरे पक्ष की लॉग मैनेजमेंट सेवाओं को सिस्टम लॉग भेजे जा सकते हैं. जैसे, Splunk, Sumo Logic, और Loggly. अगर आपको इनमें से किसी एक सेवा पर syslog भेजना है, तो सेवा के होस्ट, पोर्ट, और प्रोटोकॉल को कॉन्फ़िगर करने के लिए उस सेवा के दस्तावेज़ देखें. इसके बाद, इस नीति पर Syslog एलिमेंट को उसी हिसाब से सेट करें.
तीसरे पक्ष के लॉग मैनेजमेंट कॉन्फ़िगरेशन के बारे में जानने के लिए, नीचे दिया गया दस्तावेज़ देखें:
- Splunk (प्रॉडक्ट का वर्शन चुनें)
Apigee की यह कम्यूनिटी पोस्ट भी देखें: https://community.apigee.com/content/kbentry/13298/log-messages-into-splunk.html -
Sumo
लॉजिक
- यह Apigee कम्यूनिटी पोस्ट भी देखें: https://community.apigee.com/questions/5226/setting-up-logging-with-sumo-logic-that-host-shou.html
- लॉगिंग सेवा के रूप में Sumo Logic का इस्तेमाल करने के सभी उदाहरण देखने के लिए, यह Apigee कम्यूनिटी पोस्ट देखें. यह समाधान, Sumo Logic एचटीटीपी सोर्स कलेक्टर को एचटीटीपी पोस्ट अनुरोध करने के लिए, एक ही JavaScript नीति का इस्तेमाल करता है: https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html
- Loggly
Loggly का इस्तेमाल करते समय, नीति में<Syslog>
एलिमेंट के चाइल्ड के तौर पर<FormatMessage>true</FormatMessage>
का होना ज़रूरी है.
साथ ही, Loggly पर मैसेज लॉग करने के बारे में ज़्यादा जानने के लिए, Apigee कम्यूनिटी की यह पोस्ट देखें: https://community.apigee.com/content/kbentry/14798/log-messages-into-loggly.html
गड़बड़ी का रेफ़रंस
यह सेक्शन गड़बड़ी के कोड और दिखाए गए गड़बड़ी के मैसेज के बारे में बताता है. साथ ही, इस नीति के ट्रिगर होने पर Edge की मदद से सेट की गई गड़बड़ी के वैरिएबल के बारे में बताता है. यह जानकारी जानना ज़रूरी है कि क्या गड़बड़ियों को ठीक करने के लिए, गड़बड़ी से जुड़े नियम बनाए जा रहे हैं. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी और गड़बड़ियों को ठीक करने के तरीके देखें.
रनटाइम से जुड़ी गड़बड़ियां
नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.
गड़बड़ी का कोड | एचटीटीपी कोड स्थिति | वजह |
---|---|---|
steps.messagelogging.StepDefinitionExecutionFailed |
500 | गड़बड़ी वाली स्ट्रिंग देखें. |
डिप्लॉयमेंट से जुड़ी गड़बड़ियां
ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाले किसी प्रॉक्सी को डिप्लॉय किया जाता है.
गड़बड़ी का नाम | वजह | समाधान |
---|---|---|
InvalidProtocol |
अगर <Protocol> एलिमेंट में बताया गया प्रोटोकॉल मान्य नहीं है, तो MessageLogging नीति को डिप्लॉय करने पर, यह गड़बड़ी दिख सकती है. सही प्रोटोकॉल टीसीपी और यूडीपी हैं.
TLS/एसएसएल पर syslog मैसेज भेजने के लिए, सिर्फ़ टीसीपी का इस्तेमाल किया जा सकता है. |
build |
InvalidPort |
अगर <Port> एलिमेंट में पोर्ट नंबर
नहीं बताया गया है या मान्य नहीं है, तो MessageLogging नीति के डिप्लॉयमेंट को इस गड़बड़ी के साथ लागू नहीं किया जा सकता. पोर्ट नंबर,
शून्य से बड़ा पूर्णांक होना चाहिए. |
build |
गड़बड़ी वाले वैरिएबल
रनटाइम में कोई गड़बड़ी होने पर ये वैरिएबल सेट किए जाते हैं. ज़्यादा जानकारी के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी देखें.
वैरिएबल | जगह | उदाहरण |
---|---|---|
fault.name="fault_name" |
fault_name, गड़बड़ी का नाम है, जैसा कि ऊपर रनटाइम की गड़बड़ियां टेबल में दिया गया है. गड़बड़ी का नाम, गड़बड़ी के कोड का आखिरी हिस्सा होता है. | fault.name Matches "StepDefinitionExecutionFailed" |
messagelogging.policy_name.failed |
policy_name, उस नीति का उपयोगकर्ता तय किया गया नाम है जिसकी वजह से गड़बड़ी हुई है. | messagelogging.ML-LogMessages.failed = true |
गड़बड़ी के जवाब का उदाहरण
{ "fault":{ "detail":{ "errorcode":"steps.messagelogging.StepDefinitionExecutionFailed" }, "faultstring":"Execution failed" } }
गड़बड़ी के नियम का उदाहरण
<FaultRule name="MessageLogging"> <Step> <Name>ML-LogMessages</Name> <Condition>(fault.name Matches "StepDefinitionExecutionFailed") </Condition> </Step> <Condition>(messagelogging.ML-LogMessages.failed = true) </Condition> </FaultRule>
फ़्लो वैरिएबल
नीति के लागू न होने पर, ये वैरिएबल अपने-आप भर जाते हैं.
messagelogging.failed
messagelogging.{stepdefinition-name}.failed
मिलते-जुलते विषय
- एज से दिखाए गए वैरिएबल: वैरिएबल रेफ़रंस