شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

چی
یکی از بهترین راهها برای ردیابی مشکلات در محیط اجرای API، ثبت پیامها است. میتوانید یک خطمشی MessageLogging را در API خود پیوست و پیکربندی کنید تا پیامهای سفارشی را در یک دیسک محلی (فقط Edge برای Private Cloud) یا در syslog ثبت کنید.
نمونه ها
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>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 پیکربندی میشود، یک پراکسی API پیامهای گزارش را از Apigee Edge به یک سرور syslog از راه دور ارسال میکند. شما باید از قبل یک سرور syslog در دسترس داشته باشید. در غیر این صورت، خدمات مدیریت لاگ عمومی، مانند Splunk، Sumo Logic و Loggly در دسترس هستند. به پیکربندی خدمات مدیریت گزارش شخص ثالث مراجعه کنید.
به عنوان مثال، تصور کنید که باید اطلاعات مربوط به هر پیام درخواستی را که API شما از برنامه های مصرف کننده دریافت می کند، ثبت کنید. مقدار 3f509b58
یک مقدار کلیدی مخصوص سرویس لاگ را نشان می دهد. اگر حساب لاگ دارید، کلید لاگ خود را جایگزین کنید. پیام گزارشی که تولید میشود با چهار مقدار پر میشود: سازمان، پروکسی API، و نام محیط مرتبط با تراکنش، همراه با مقدار پارامتر پرس و جو در پیام درخواست.
اگر یک Edge برای استقرار Private Cloud دارید، میتوانید پیامهای گزارش را نیز در یک فایل بنویسید.
Syslog از طریق TLS/SSL
<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/SSL به ارائه دهندگان ثبت پیام شخص ثالث پیام ارسال کنید.
چرخش فایل: اندازه
<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 برای استقرار Private Cloud پشتیبانی میشود.) برای اطلاعات در مورد مکان ذخیره فایلها، به محل فایل گزارش در Edge برای Private Cloud مراجعه کنید. | Message | پیامی را بسازید که باید به فایل گزارش ارسال شود، متن را با متغیرها ترکیب کنید تا اطلاعاتی را که می خواهید دریافت کنید. نمونه ها را ببینید. |
FileName | نام پایه فایل لاگ. مسیر فایل را مشخص نکنید. به عنوان مثال، این عنصر FileName یک مسیر فایل را مشخص می کند و نامعتبر است:<FileName>/opt/apigee/var/log/messages/mylog.log</FileName> این کد فقط یک نام فایل را مشخص می کند و معتبر است: <FileName>mylog.log</FileName> برای اطلاعات در مورد محل ذخیره فایل، به محل فایل گزارش در Edge for Private Cloud مراجعه کنید. | |
FileRotationOptions | ||
rotateFileOnStartup | صفت. مقادیر معتبر: اگر روی true تنظیم شود، هر بار که موتور پیامرسان دوباره راهاندازی میشود، فایل log چرخانده میشود. | |
FileRotationType | خط مشی چرخش ( size یا time ) یک فایل گزارش را مشخص می کند. | |
MaxFileSizeInMB | (در انتخاب size به عنوان نوع چرخش) اندازه یک فایل گزارش را مشخص می کند که سرور را تحریک می کند تا پیام های گزارش را به یک فایل جداگانه منتقل کند. پس از اینکه فایل گزارش به اندازه مشخص شده رسید، سرور نام فایل لاگ فعلی را تغییر می دهد. | |
RotationFrequency | (در انتخاب time به عنوان نوع چرخش) زمانی را بر حسب دقیقه مشخص می کند که سرور را تحریک می کند تا پیام های گزارش را به یک فایل جداگانه منتقل کند. پس از سپری شدن فاصله زمانی مشخص شده، نام فایل گزارش فعلی تغییر می کند. | |
MaxFilesToRetain | حداکثر تعداد فایل هایی را که باید در زمینه تنظیمات چرخش شما حفظ شوند را مشخص می کند. مقدار پیش فرض 8 است. اگر صفر (0) را مشخص کنید، فایل های گزارش به طور نامحدود حفظ می شوند، اما منوط به تنظیمات چرخش فایل شما هستند، اگرچه هیچ یک از فایل ها حذف یا تغییر نام نمی دهند. بنابراین، برای جلوگیری از خطاهای پر دیسک در آینده، این مقدار را روی مقداری بزرگتر از صفر تنظیم کنید، یا یک سیستم منظم و خودکار برای پاکسازی یا بایگانی فایل های گزارش نگهداری شده قدیمی تر اجرا کنید. | |
BufferMessage | اگر پخش HTTP برای پراکسی شما فعال باشد ، پیامهای درخواست/پاسخ بافر نمیشوند. اگر میخواهید محتوایی را ثبت کنید که نیاز به تجزیه پیام جریان دارد، BufferMessage را روی true تنظیم کنید. برای مثال به برگه نمونه «فعال جریان» مراجعه کنید. پیش فرض: نادرست | |
مقصد syslog. برای ارسال syslog به Splunk، Sumo Logic یا Loggly، به پیکربندی خدمات مدیریت گزارش شخص ثالث مراجعه کنید. | Message | پیامی را بسازید که باید به syslog ارسال شود، متن را با متغیرها ترکیب کنید تا اطلاعاتی را که می خواهید دریافت کنید. نمونه ها را ببینید. توجه: متغیرهای پاسخ در PostClientFlow به دنبال یک جریان خطا در دسترس نخواهند بود. از متغیرهای پیام برای ثبت اطلاعات پاسخ برای هر دو موقعیت خطا و موفقیت استفاده کنید. همچنین به یادداشت های استفاده مراجعه کنید. |
Host | نام میزبان یا آدرس IP سروری که syslog باید در آن ارسال شود. اگر این عنصر را وارد نکنید، پیش فرض لوکال هاست است. | |
Port | پورتی که syslog در آن اجرا می شود. اگر این عنصر را وارد نکنید، پیشفرض 514 است. | |
Protocol | TCP یا UDP (پیشفرض). در حالی که UDP کارایی بیشتری دارد، پروتکل TCP تحویل گزارش پیام به سرور syslog را تضمین می کند. برای ارسال پیام های syslog از طریق TLS/SSL، فقط TCP پشتیبانی می شود. | |
FormatMessage | اختیاری است، اما این عنصر به شما امکان می دهد قالب محتوای تولید شده توسط Apigee که به پیام اضافه شده است را کنترل کنید. اگر روی درست تنظیم شود، پیام syslog با تعداد ثابتی از نویسهها اضافه میشود که به شما امکان میدهد آن اطلاعات را از پیامها فیلتر کنید. در اینجا یک مثال برای فرمت ثابت آورده شده است: اطلاعات تولید شده توسط Apigee شامل:
اگر روی false (پیشفرض) تنظیم شود، پیام با آن کاراکترهای ثابت اضافه نمیشود. | |
PayloadOnly | این عنصر قالب پیامهای تولید شده توسط Apigee را طوری تنظیم میکند که فقط حاوی متن پیام syslog باشد، بدون نویسههای از پیش تعیینشده توسط FormatMessage . اگر این عنصر را وارد نکنید یا آن را خالی بگذارید، مقدار پیشفرض به FormatMessage مراجعه کنید. | |
DateFormat | اختیاری. یک رشته قالب قالببندی برای قالببندی مهر زمانی برای هر پیام گزارش. به طور پیش فرض، Apigee از | |
SSLInfo | به شما امکان می دهد پیام ها را از طریق SSL/TLS ثبت کنید. با عنصر فرعی اگر این عنصر را وارد نکنید یا آن را خالی بگذارید، مقدار پیشفرض نادرست است (بدون TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> میتوانید تگ <SSLInfo> را همانند آنچه در TargetEndpoint میتوانید پیکربندی کنید، از جمله فعال کردن TLS/SSL دو طرفه، همانطور که در مرجع پیکربندی پروکسی API توضیح داده شده است. فقط پروتکل TCP پشتیبانی می شود. | |
logLevel | اختیاری. مقادیر معتبر: سطح خاصی از اطلاعات را برای درج در گزارش پیام تنظیم کنید. اگر از عنصر |
طرحواره ها
نکات استفاده
هنگام پیوست کردن یک خط مشی MessageLogging به یک جریان پروکسی API، در نظر داشته باشید که آن را در پاسخ ProxyEndpoint، در یک جریان ویژه به نام PostClientFlow قرار دهید. PostClientFlow پس از ارسال پاسخ به مشتری درخواست کننده اجرا می شود، که تضمین می کند که تمام معیارها برای ورود به سیستم در دسترس هستند. برای جزئیات در مورد استفاده از PostClientFlow، به مرجع پیکربندی پروکسی API مراجعه کنید.
PostClientFlow از دو جهت خاص است:
- فقط به عنوان بخشی از جریان پاسخ اجرا می شود.
- این تنها جریانی است که پس از ورود پراکسی به حالت خطا اجرا می شود.
از آنجایی که بدون توجه به موفقیت یا عدم موفقیت پروکسی اجرا می شود، می توانید سیاست های MessageLogging را در PostClientFlow قرار دهید و تضمین کنید که همیشه اجرا می شوند.
تصویر Trace زیر یک سیاست MessageLogging را نشان می دهد که به عنوان بخشی از PostClientFlow، پس از اجرای DefaultFaultRule اجرا می شود:
در این مثال، خط مشی Verify API Key به دلیل یک کلید نامعتبر باعث خطا شده است.
در زیر، تعریف ProxyEndpoint نشان داده شده است که شامل PostClientFlow است:
<ProxyEndpoint name="default"> ... <PostClientFlow> <Response> <Step> <Name>Message-Logging-1</Name> </Step> </Response> </PostClientFlow> ... </ProxyEndpoint>
Edge پیامها را به صورت متن ساده ثبت میکند و میتوانید گزارشگیری را به گونهای پیکربندی کنید که شامل متغیرهایی مانند تاریخ و ساعت دریافت درخواست یا پاسخ، هویت کاربر در درخواست، آدرس IP منبعی که درخواست از آن ارسال شده است، و غیره باشد. Edge پیام را به صورت ناهمزمان ثبت می کند، به این معنی که هیچ تاخیری که ممکن است در اثر مسدود کردن فراخوان ها ایجاد شود، به API شما وارد نمی شود.
خط مشی MessageLogging پیام های ثبت شده را در حافظه در بافر می نویسد. ثبت کننده پیام پیام ها را از بافر می خواند و سپس به مقصدی که پیکربندی می کنید می نویسد. هر مقصدی بافر مخصوص به خود را دارد.
اگر نرخ نوشتن در بافر فراتر از نرخ خواندن افزایش یابد، بافر سرریز میشود و ثبت نام با شکست مواجه میشود. اگر این اتفاق بیفتد، ممکن است پیامی حاوی موارد زیر را در فایل گزارش پیدا کنید:
Log message size exceeded. Increase the max message size setting
اگر در Edge for Private Cloud 4.15.07 و نسخه های قبلی با این مشکل مواجه شدید، فایل message-logging.properties
را پیدا کرده و از این راه حل استفاده کنید:
ویژگی max.log.message.size.in.kb
(مقدار پیش فرض = 128 کیلوبایت) را در فایل message-logging.properties
افزایش دهید.
برای Edge for Private Cloud 4.16.01 و جدیدتر، conf/message-logging.properties+max. log.message.size.in.kb
ویژگی conf/message-logging.properties+max. log.message.size.in.kb
در /opt/apigee/customer/application/message-processor.properties فایل و Message Processor را مجددا راه اندازی کنید. لطفاً توجه داشته باشید که این ویژگی در ابتدا به صورت پیش فرض اظهار نظر می شود.
توجه: متغیرهای پیام پاسخ در Edge از Error Flow در دسترس نیستند. اگر جریان قبلی Error Flow بود، این متغیرها در PostClientFlow نیز موجود نیستند. اگر میخواهید اطلاعات پاسخ را از PostClientFlow ثبت کنید، از شی پیام استفاده کنید. میتوانید از این شی برای دریافت سرصفحهها و سایر اطلاعات از پاسخ استفاده کنید که آیا خطایی وجود دارد یا خیر. برای اطلاعات بیشتر و یک مثال به متغیرهای پیام مراجعه کنید.
کنترل مهر زمانی پیام گزارش در Edge for Private Cloud
به طور پیشفرض، مُهر زمانی در همه پیامهای گزارش دارای قالب زیر است:
yyyy-MM-dd'T'HH:mm:ss.SSSZ
این پیشفرض در سراسر سیستم را میتوان برای مقاصد syslog با استفاده از عنصر DateFormat
لغو کرد. رفتار این الگو در مستندات کلاس SimpleDateFormat جاوا توضیح داده شده است. با توجه به آن تعریف، yyyy
با یک سال 4 رقمی، MM
با یک ماه 2 رقمی جایگزین می شود و غیره. فرمت فوق ممکن است منجر به رشته ای از این فرم شود:
2022-09-28T22:38:11.721+0000
برای کنترل آن فرمت می توانید از ویژگی conf_system_apigee.syslogger.dateFormat در Edge Message Processor استفاده کنید. به عنوان مثال، تغییر قالب پیام به:
yy/MM/dd'T'HH:mm:ss.SSSZ
..جایگزینی خط تیره با اسلش و کوتاه کردن آن به یک سال 2 رقمی، یک مهر زمانی را به شکل زیر ثبت می کند:
22/09/28T22:38:11.721+0000
برای تغییر فرمت:
- فایل message-processor.properties را در یک ویرایشگر باز کنید. اگر فایل وجود ندارد، آن را ایجاد کنید:
> vi /opt/apigee/customer/application/message-processor.properties - خواص را به صورت دلخواه تنظیم کنید:
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-processor restart
محل فایل را در Edge برای Private Cloud ثبت کنید
Edge برای Private Cloud نسخه 4.16.01 و بالاتر
بهطور پیشفرض، گزارشهای پیام خصوصی Cloud در فهرست زیر در گرههای پردازشگر پیام قرار دارند:
/opt/apigee/var/log/edge-message-processor/messagelogging/org_name/environment/api_proxy_name/revision/logging_policy_name/
میتوانید مکان پیشفرض گزارش را با تغییر ویژگیهای فایل message-logging.properties در پردازشگرهای پیام تغییر دهید:
- 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 ارجاع دهید زیرا به صورت پیشفرض کامنت شده است. برای اطلاعات بیشتر به تنظیم نشانه ای که در حال حاضر نظر داده شده است مراجعه کنید.
اگر می خواهید فایل های log را در یک ساختار فایل مسطح ذخیره کنید تا همه فایل های log در یک دایرکتوری قرار گیرند، conf/message-logging.properties+enable.flat.directory.structure را در فایل message-logging.properties روی true تنظیم کنید. پیامها در دایرکتوری مشخص شده توسط ویژگیهای بالا ذخیره میشوند و نام فایلها به شکل {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}
.
برای تنظیم این ویژگی ها:
- فایل message-processor.properties را در یک ویرایشگر باز کنید. اگر فایل وجود ندارد، آن را ایجاد کنید:
> vi /opt/apigee/customer/application/message-processor.properties - خواص را به صورت دلخواه تنظیم کنید:
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-processor restart
Edge برای Private Cloud 4.15.07 و نسخه های قبلی
به طور پیشفرض، گزارشهای پیام در مکان زیر در پردازندههای پیام قرار دارند:
/opt/apigee4/var/log/apigee/message-processor/messagelog/{org}/{environment}/{api_proxy_name}/{revision}/{logging_policy_name}/
میتوانید با تغییر ویژگیهای زیر در فایل message-logging.properties در پردازندههای پیام، مکان پیشفرض گزارش را تغییر دهید:
- data.dir - مسیر اصلی را برای ذخیره سازی فایل لاگ تنظیم می کند. برای مثال data.dir=/opt/apigee4/var/log
- log.root.dir - اگر این را روی یک مسیر نسبی تنظیم کنید، مانند log.root.dir=custom/folder/، مسیر به مکان data.dir اضافه می شود.
به عنوان مثال، ترکیب این دو ویژگی، دایرکتوری ورود به سیستم را در /opt/apigee4/var/log/custom/folder/messagelog/ تنظیم می کند (توجه داشته باشید که /messagelog به طور خودکار اضافه می شود).
اگر این را روی یک مسیر مطلق تنظیم کنید، مانند log.root.dir=/opt/apigee4/var/log/messages ، گزارشهای پیام در /opt/apigee4/var/log/messages/messagelog/ ذخیره میشوند. یک مسیر مطلق در log.root.dir بر data.dir ارجحیت دارد.
اگر میخواهید فایلهای گزارش را در یک ساختار فایل مسطح ذخیره کنید تا همه فایلهای گزارش در یک دایرکتوری قرار گیرند، ویژگی enable.flat.directory.structure را در فایل message-logging.properties در Message Processors روی true تنظیم کنید. پیامها در دایرکتوری مشخص شده توسط ویژگیهای بالا ذخیره میشوند و نام فایلها به شکل {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>
با تنظیم ویژگی defaultVariableValue
در عنصر Message
، میتوان یک مقدار پیشفرض مشترک را برای همه متغیرهای حلنشده تعیین کرد:
<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 - سومو منطق
- همچنین این پست انجمن Apigee را ببینید: https://community.apigee.com/questions/5226/setting-up-logging-with-sumo-logic-which-host-shou.html
- برای مثال کامل استفاده از Sumo Logic به عنوان سرویس ورود به سیستم، به پست انجمن Apigee زیر مراجعه کنید. این راه حل از یک خط مشی جاوا اسکریپت استفاده می کند تا درخواست های HTTP POST به جمع آوری کننده منبع سومو منطق HTTP: https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html
- لاگ
هنگام استفاده از Loggly،<FormatMessage>true</FormatMessage>
به عنوان فرزند عنصر<Syslog>
در خط مشی مورد نیاز است.
همچنین برای اطلاعات بیشتر در مورد ثبت پیام به Loggly، این پست انجمن Apigee را ببینید: https://community.apigee.com/content/kbentry/14798/log-messages-into-loggly.html
مرجع خطا
این بخش کدهای خطا و پیامهای خطایی را که برگردانده میشوند و متغیرهای خطا را که توسط Edge تنظیم میشوند، هنگامی که این خطمشی خطا را راهاندازی میکند، توضیح میدهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.
خطاهای زمان اجرا
این خطاها ممکن است هنگام اجرای سیاست رخ دهند.
کد خطا | وضعیت HTTP | علت |
---|---|---|
steps.messagelogging.StepDefinitionExecutionFailed | 500 | رشته خطا را ببینید. |
خطاهای استقرار
این خطاها ممکن است زمانی رخ دهند که یک پروکسی حاوی این خط مشی را مستقر می کنید.
نام خطا | علت | رفع کنید |
---|---|---|
InvalidProtocol | اگر پروتکل مشخص شده در عنصر <Protocol> معتبر نباشد، اجرای سیاست MessageLogging ممکن است با این خطا با شکست مواجه شود. پروتکل های معتبر TCP و UDP هستند. برای ارسال پیام های syslog از طریق TLS/SSL، فقط TCP پشتیبانی می شود. | build |
InvalidPort | اگر شماره پورت در عنصر <Port> مشخص نشده باشد یا اگر معتبر نباشد، استقرار سیاست MessageLogging ممکن است با این خطا با شکست مواجه شود. شماره پورت باید یک عدد صحیح بزرگتر از صفر باشد. | build |
متغیرهای خطا
این متغیرها زمانی تنظیم می شوند که یک خطای زمان اجرا رخ دهد. برای اطلاعات بیشتر، به آنچه باید در مورد خطاهای خط مشی بدانید مراجعه کنید.
متغیرها | کجا | مثال |
---|---|---|
fault.name=" fault_name " | fault_name نام خطا است، همانطور که در جدول خطاهای Runtime در بالا ذکر شده است. نام خطا آخرین قسمت کد خطا است. | 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
موضوعات مرتبط
- متغیرهای در معرض Edge: مرجع متغیرها
شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

چی
یکی از بهترین راهها برای ردیابی مشکلات در محیط اجرای API، ثبت پیامها است. میتوانید یک خطمشی MessageLogging را در API خود پیوست و پیکربندی کنید تا پیامهای سفارشی را در یک دیسک محلی (فقط Edge برای Private Cloud) یا در syslog ثبت کنید.
نمونه ها
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>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 پیکربندی میشود، یک پراکسی API پیامهای گزارش را از Apigee Edge به یک سرور syslog از راه دور ارسال میکند. شما باید از قبل یک سرور syslog در دسترس داشته باشید. در غیر این صورت، خدمات مدیریت لاگ عمومی، مانند Splunk، Sumo Logic و Loggly در دسترس هستند. به پیکربندی خدمات مدیریت گزارش شخص ثالث مراجعه کنید.
به عنوان مثال، تصور کنید که باید اطلاعات مربوط به هر پیام درخواستی را که API شما از برنامه های مصرف کننده دریافت می کند، ثبت کنید. مقدار 3f509b58
یک مقدار کلیدی مخصوص سرویس لاگ را نشان می دهد. اگر حساب لاگ دارید، کلید لاگ خود را جایگزین کنید. پیام گزارشی که تولید میشود با چهار مقدار پر میشود: سازمان، پروکسی API، و نام محیط مرتبط با تراکنش، همراه با مقدار پارامتر پرس و جو در پیام درخواست.
اگر یک Edge برای استقرار Private Cloud دارید، میتوانید پیامهای گزارش را نیز در یک فایل بنویسید.
Syslog از طریق TLS/SSL
<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/SSL به ارائه دهندگان ثبت پیام شخص ثالث پیام ارسال کنید.
چرخش فایل: اندازه
<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 برای استقرار Private Cloud پشتیبانی میشود.) برای اطلاعات در مورد مکان ذخیره فایلها، به محل فایل گزارش در Edge برای Private Cloud مراجعه کنید. | Message | پیامی را بسازید که باید به فایل گزارش ارسال شود، متن را با متغیرها ترکیب کنید تا اطلاعاتی را که می خواهید دریافت کنید. نمونه ها را ببینید. |
FileName | نام پایه فایل لاگ. مسیر فایل را مشخص نکنید. به عنوان مثال، این عنصر FileName یک مسیر فایل را مشخص می کند و نامعتبر است:<FileName>/opt/apigee/var/log/messages/mylog.log</FileName> این کد فقط یک نام فایل را مشخص می کند و معتبر است: <FileName>mylog.log</FileName> برای اطلاعات در مورد محل ذخیره فایل، به محل فایل گزارش در Edge for Private Cloud مراجعه کنید. | |
FileRotationOptions | ||
rotateFileOnStartup | صفت. مقادیر معتبر: اگر روی true تنظیم شود، هر بار که موتور پیامرسان دوباره راهاندازی میشود، فایل log چرخانده میشود. | |
FileRotationType | خط مشی چرخش ( size یا time ) یک فایل گزارش را مشخص می کند. | |
MaxFileSizeInMB | (در انتخاب size به عنوان نوع چرخش) اندازه یک فایل گزارش را مشخص می کند که سرور را تحریک می کند تا پیام های گزارش را به یک فایل جداگانه منتقل کند. پس از اینکه فایل گزارش به اندازه مشخص شده رسید، سرور نام فایل لاگ فعلی را تغییر می دهد. | |
RotationFrequency | (در انتخاب time به عنوان نوع چرخش) زمانی را بر حسب دقیقه مشخص می کند که سرور را تحریک می کند تا پیام های گزارش را به یک فایل جداگانه منتقل کند. پس از سپری شدن فاصله زمانی مشخص شده، نام فایل گزارش فعلی تغییر می کند. | |
MaxFilesToRetain | حداکثر تعداد فایل هایی را که باید در زمینه تنظیمات چرخش شما حفظ شوند را مشخص می کند. مقدار پیش فرض 8 است. اگر صفر (0) را مشخص کنید، فایل های گزارش به طور نامحدود حفظ می شوند، اما منوط به تنظیمات چرخش فایل شما هستند، اگرچه هیچ یک از فایل ها حذف یا تغییر نام نمی دهند. بنابراین، برای جلوگیری از خطاهای پر دیسک در آینده، این مقدار را روی مقداری بزرگتر از صفر تنظیم کنید، یا یک سیستم منظم و خودکار برای پاکسازی یا بایگانی فایل های گزارش نگهداری شده قدیمی تر اجرا کنید. | |
BufferMessage | اگر پخش HTTP برای پراکسی شما فعال باشد ، پیامهای درخواست/پاسخ بافر نمیشوند. اگر میخواهید محتوایی را ثبت کنید که نیاز به تجزیه پیام جریان دارد، BufferMessage را روی true تنظیم کنید. برای مثال به برگه نمونه «فعال جریان» مراجعه کنید. پیش فرض: نادرست | |
مقصد syslog. برای ارسال syslog به Splunk، Sumo Logic یا Loggly، به پیکربندی خدمات مدیریت گزارش شخص ثالث مراجعه کنید. | Message | پیامی را بسازید که باید به syslog ارسال شود، متن را با متغیرها ترکیب کنید تا اطلاعاتی را که می خواهید دریافت کنید. نمونه ها را ببینید. توجه: متغیرهای پاسخ در PostClientFlow به دنبال یک جریان خطا در دسترس نخواهند بود. از متغیرهای پیام برای ثبت اطلاعات پاسخ برای هر دو موقعیت خطا و موفقیت استفاده کنید. همچنین به یادداشت های استفاده مراجعه کنید. |
Host | نام میزبان یا آدرس IP سروری که syslog باید در آن ارسال شود. اگر این عنصر را وارد نکنید، پیش فرض لوکال هاست است. | |
Port | پورتی که syslog در آن اجرا می شود. اگر این عنصر را وارد نکنید، پیشفرض 514 است. | |
Protocol | TCP یا UDP (پیشفرض). در حالی که UDP کارایی بیشتری دارد، پروتکل TCP تحویل گزارش پیام به سرور syslog را تضمین می کند. برای ارسال پیام های syslog از طریق TLS/SSL، فقط TCP پشتیبانی می شود. | |
FormatMessage | اختیاری است، اما این عنصر به شما امکان می دهد قالب محتوای تولید شده توسط Apigee که به پیام اضافه شده است را کنترل کنید. اگر روی درست تنظیم شود، پیام syslog با تعداد ثابتی از نویسهها اضافه میشود که به شما امکان میدهد آن اطلاعات را از پیامها فیلتر کنید. در اینجا یک مثال برای فرمت ثابت آورده شده است: اطلاعات تولید شده توسط Apigee شامل:
اگر روی false (پیشفرض) تنظیم شود، پیام با آن کاراکترهای ثابت اضافه نمیشود. | |
PayloadOnly | این عنصر قالب پیامهای تولید شده توسط Apigee را طوری تنظیم میکند که فقط حاوی متن پیام syslog باشد، بدون نویسههای از پیش تعیینشده توسط FormatMessage . اگر این عنصر را وارد نکنید یا آن را خالی بگذارید، مقدار پیشفرض به FormatMessage مراجعه کنید. | |
DateFormat | اختیاری. یک رشته قالب قالببندی برای قالببندی مهر زمانی برای هر پیام گزارش. به طور پیش فرض، Apigee از | |
SSLInfo | به شما امکان می دهد پیام ها را از طریق SSL/TLS ثبت کنید. با عنصر فرعی اگر این عنصر را وارد نکنید یا آن را خالی بگذارید، مقدار پیشفرض نادرست است (بدون TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> میتوانید تگ <SSLInfo> را همانند آنچه در TargetEndpoint میتوانید پیکربندی کنید، از جمله فعال کردن TLS/SSL دو طرفه، همانطور که در مرجع پیکربندی پروکسی API توضیح داده شده است. فقط پروتکل TCP پشتیبانی می شود. | |
logLevel | اختیاری. مقادیر معتبر: سطح خاصی از اطلاعات را برای درج در گزارش پیام تنظیم کنید. اگر از عنصر |
طرحواره ها
نکات استفاده
هنگام پیوست کردن یک خط مشی MessageLogging به یک جریان پروکسی API، در نظر داشته باشید که آن را در پاسخ ProxyEndpoint، در یک جریان ویژه به نام PostClientFlow قرار دهید. PostClientFlow پس از ارسال پاسخ به مشتری درخواست کننده اجرا می شود، که تضمین می کند که تمام معیارها برای ورود به سیستم در دسترس هستند. برای جزئیات در مورد استفاده از PostClientFlow، به مرجع پیکربندی پروکسی API مراجعه کنید.
PostClientFlow از دو جهت خاص است:
- فقط به عنوان بخشی از جریان پاسخ اجرا می شود.
- این تنها جریانی است که پس از ورود پراکسی به حالت خطا اجرا می شود.
از آنجایی که بدون توجه به موفقیت یا عدم موفقیت پروکسی اجرا می شود، می توانید سیاست های MessageLogging را در PostClientFlow قرار دهید و تضمین کنید که همیشه اجرا می شوند.
تصویر Trace زیر یک سیاست MessageLogging را نشان می دهد که به عنوان بخشی از PostClientFlow، پس از اجرای DefaultFaultRule اجرا می شود:
در این مثال، خط مشی Verify API Key به دلیل یک کلید نامعتبر باعث خطا شده است.
در زیر، تعریف ProxyEndpoint نشان داده شده است که شامل PostClientFlow است:
<ProxyEndpoint name="default"> ... <PostClientFlow> <Response> <Step> <Name>Message-Logging-1</Name> </Step> </Response> </PostClientFlow> ... </ProxyEndpoint>
Edge پیامها را به صورت متن ساده ثبت میکند و میتوانید گزارشگیری را به گونهای پیکربندی کنید که شامل متغیرهایی مانند تاریخ و ساعت دریافت درخواست یا پاسخ، هویت کاربر در درخواست، آدرس IP منبعی که درخواست از آن ارسال شده است، و غیره باشد. Edge پیام را به صورت ناهمزمان ثبت می کند، به این معنی که هیچ تاخیری که ممکن است در اثر مسدود کردن فراخوان ها ایجاد شود، به API شما وارد نمی شود.
خط مشی MessageLogging پیام های ثبت شده را در حافظه در بافر می نویسد. ثبت کننده پیام پیام ها را از بافر می خواند و سپس به مقصدی که پیکربندی می کنید می نویسد. هر مقصدی بافر مخصوص به خود را دارد.
اگر نرخ نوشتن در بافر فراتر از نرخ خواندن افزایش یابد، بافر سرریز میشود و ثبت نام با شکست مواجه میشود. اگر این اتفاق بیفتد، ممکن است پیامی حاوی موارد زیر را در فایل گزارش پیدا کنید:
Log message size exceeded. Increase the max message size setting
اگر در Edge for Private Cloud 4.15.07 و نسخه های قبلی با این مشکل مواجه شدید، فایل message-logging.properties
را پیدا کرده و از این راه حل استفاده کنید:
ویژگی max.log.message.size.in.kb
(مقدار پیش فرض = 128 کیلوبایت) را در فایل message-logging.properties
افزایش دهید.
برای Edge for Private Cloud 4.16.01 و جدیدتر، conf/message-logging.properties+max. log.message.size.in.kb
ویژگی conf/message-logging.properties+max. log.message.size.in.kb
در /opt/apigee/customer/application/message-processor.properties فایل و Message Processor را مجددا راه اندازی کنید. لطفاً توجه داشته باشید که این ویژگی در ابتدا به صورت پیش فرض اظهار نظر می شود.
توجه: متغیرهای پیام پاسخ در Edge از Error Flow در دسترس نیستند. اگر جریان قبلی Error Flow بود، این متغیرها در PostClientFlow نیز موجود نیستند. اگر میخواهید اطلاعات پاسخ را از PostClientFlow ثبت کنید، از شی پیام استفاده کنید. میتوانید از این شی برای دریافت سرصفحهها و سایر اطلاعات از پاسخ استفاده کنید که آیا خطایی وجود دارد یا خیر. برای اطلاعات بیشتر و یک مثال به متغیرهای پیام مراجعه کنید.
کنترل مهر زمانی پیام گزارش در Edge for Private Cloud
به طور پیشفرض، مُهر زمانی در همه پیامهای گزارش دارای قالب زیر است:
yyyy-MM-dd'T'HH:mm:ss.SSSZ
این پیشفرض در سراسر سیستم را میتوان برای مقاصد syslog با استفاده از عنصر DateFormat
لغو کرد. رفتار این الگو در مستندات کلاس SimpleDateFormat جاوا توضیح داده شده است. با توجه به آن تعریف، yyyy
با یک سال 4 رقمی، MM
با یک ماه 2 رقمی جایگزین می شود و غیره. فرمت فوق ممکن است منجر به رشته ای از این فرم شود:
2022-09-28T22:38:11.721+0000
برای کنترل آن فرمت می توانید از ویژگی conf_system_apigee.syslogger.dateFormat در Edge Message Processor استفاده کنید. به عنوان مثال، تغییر قالب پیام به:
yy/MM/dd'T'HH:mm:ss.SSSZ
.. تنظیم مجدد خط ها با بریدگی ، و کوتاه شدن به یک سال 2 رقمی ، یک جدول زمانی را به شکل ثبت می کند:
22/09/28T22:38:11.721+0000
برای تغییر قالب:
- پرونده پیام-پردازشگر. properties را در یک ویرایشگر باز کنید. اگر پرونده وجود ندارد ، آن را ایجاد کنید:
> vi /opt/apigee/customer/application/message-processor.properties - خواص را به دلخواه تنظیم کنید:
conf_system_apigee.syslogger.dateformat = yy/mm/dd't'hh: mm: ss.sssz - تغییرات خود را ذخیره کنید
- اطمینان حاصل کنید که پرونده Properties متعلق به کاربر "Apigee" است:
> apigee chown: apigee /opt/apigee/customer/application/message-processor.properties - پردازنده پیام Edge را مجدداً راه اندازی کنید:
>/opt/apigee/apigee-service/bin/apigee-service edge-message-processor راه اندازی مجدد
ورود به سیستم پرونده در لبه برای ابر خصوصی
لبه برای ابر خصوصی 4.16.01 و بعد
به طور پیش فرض ، سیاهههای مربوط به پیام های ابری خصوصی در فهرست زیر در گره های پردازنده پیام قرار دارند:
/opt/apigee/var/log/edge-message-processor/messagelogging/org_name/environment/api_proxy_name/revision/logging_policy_name/
می توانید با تغییر ویژگی ها در پرونده پیام-logging.properties در پردازنده های پیام ، مکان ورود به سیستم پیش فرض را تغییر دهید:
- 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 ارجاع دهید زیرا به طور پیش فرض اظهار نظر می شود. به تنظیم یک نشانه که در حال حاضر برای اطلاعات بیشتر اظهار نظر می کند ، مراجعه کنید.
اگر می خواهید پرونده های ورود به سیستم را در یک ساختار فایل مسطح ذخیره کنید تا تمام پرونده های ورود به سیستم در یک دایرکتوری قرار گیرند ، Conf/Message-logging.properties+Enable.flat.directory.structure را در پرونده پیام-logging.properties تنظیم کنید. پیام ها در دایرکتوری مشخص شده توسط خصوصیات بالا ذخیره می شوند ، و نام پرونده ها به شکل {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}
.
برای تنظیم این خصوصیات:
- پرونده پیام-پردازشگر. properties را در یک ویرایشگر باز کنید. اگر پرونده وجود ندارد ، آن را ایجاد کنید:
> vi /opt/apigee/customer/application/message-processor.properties - خواص را به دلخواه تنظیم کنید:
Conf/Message-logging.properties+log.root.dir = /opt/apigee/var/log/پیام ها - تغییرات خود را ذخیره کنید
- اطمینان حاصل کنید که پرونده Properties متعلق به کاربر "Apigee" است:
> apigee chown: apigee /opt/apigee/customer/application/message-processor.properties - مؤلفه لبه را مجدداً راه اندازی کنید:
>/opt/apigee/apigee-service/bin/apigee-service edge-message-processor راه اندازی مجدد
لبه برای ابر خصوصی 4.15.07 و زودتر
به طور پیش فرض ، گزارش های پیام در مکان زیر در پردازنده های پیام قرار دارند:
/opt/apigee4/var/log/apigee/message-processor/messagelog/{org}/{environment}/{api_proxy_name}/{revision}/{logging_policy_name}/
می توانید با تغییر ویژگی های زیر در پرونده پیام-logging.properties در پردازنده های پیام ، مکان ورود به سیستم پیش فرض را تغییر دهید:
- data.dir - مسیر ریشه را برای ذخیره سازی پرونده ورود به سیستم تنظیم می کند. به عنوان مثال ، data.dir =/opt/apigee4/var/log
- log.root.dir - اگر این کار را در یک مسیر نسبی تنظیم کنید ، مانند log.root.dir = سفارشی/پوشه/، مسیر به محل data.dir اضافه می شود.
به عنوان مثال ، ترکیب این دو ویژگی می تواند فهرست ورود به سیستم را در/OPT/APIGEE4/VAR/LOG/CUSTOR/FOLTER/MessageLog/(توجه داشته باشید که/پیام به طور خودکار اضافه می شود).
اگر این کار را در یک مسیر مطلق تنظیم کنید ، مانند log.root.dir =/opt/apigee4/var/log/پیام ها ، گزارش های پیام در/opt/apigee4/var/log/message/messageLog ذخیره می شوند. یک مسیر مطلق در log.root.dir بر Data.dir تقدم می کند.
اگر می خواهید پرونده های ورود به سیستم را در یک ساختار فایل مسطح ذخیره کنید تا تمام پرونده های ورود به سیستم در یک دایرکتوری قرار گیرند ، ویژگی Enable.flat.directory.structure را در پرونده پیام-logging.properties در پردازنده های پیام تنظیم کنید. پیام ها در دایرکتوری مشخص شده توسط خصوصیات بالا ذخیره می شوند ، و نام پرونده ها به شکل {org} _ {محیط} _ {api_proxy_name} _ {Revision} _ {logging_policy_name} _ {نام پرونده} .
مقادیر پیش فرض برای متغیرها در الگوی پیام
مقادیر پیش فرض را می توان برای هر متغیر در الگوی پیام به طور جداگانه مشخص کرد. به عنوان مثال ، اگر متغیر request.header.id
قابل حل نیست ، مقدار آن با مقدار unknown
جایگزین می شود.
<Message>This is a test message. id = {request.header.id:unknown}</Message>
یک مقدار پیش فرض مشترک را می توان برای همه متغیرهای حل نشده با تنظیم ویژگی defaultVariableValue
در عنصر Message
مشخص کرد:
<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>
پیکربندی خدمات مدیریت ورود به سیستم شخص ثالث
خط مشی MessageLogging به شما امکان می دهد پیام های SYSLOG را به خدمات مدیریت ورود به سیستم شخص ثالث مانند Splunk ، Sumo Logic و Loggly ارسال کنید. اگر می خواهید Syslog را به یکی از این خدمات ارسال کنید ، برای پیکربندی میزبان ، پورت و پروتکل سرویس ، به اسناد سرویس مراجعه کنید ، سپس عنصر Syslog را بر این اساس تنظیم کنید.
مستندات زیر را برای پیکربندی مدیریت ورود به سیستم شخص ثالث مشاهده کنید:
- Splunk (نسخه محصول را انتخاب کنید)
همچنین این پست جامعه Apigee را ببینید: https://community.apigee.com/content/kbentry/13298/log-messages-into-splunk.html - سومو منطق
- همچنین به این پست جامعه Apigee مراجعه کنید: https://community.apigee.com/questions/5226/setting-up-logging-with-sumo-logic-which-host-hest-hestml
- برای مثال کامل با استفاده از SUMO Logic به عنوان سرویس ورود به سیستم ، به پست انجمن Apigee زیر مراجعه کنید. راه حل از یک خط مشی JavaScript واحد استفاده می کند تا درخواست های HTTP را به SUMO Logic Http Source جمع آوری کند: https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html
- لاگ
هنگام استفاده از Loggly ،<FormatMessage>true</FormatMessage>
در این خط مشی به عنوان فرزند عنصر<Syslog>
لازم است.
همچنین برای اطلاعات بیشتر در مورد ورود به سیستم به Loggly: https://community.apigee.com/content/kbentry/14798/log-messages-into-loggly.html این پست انجمن Apigee را ببینید.
مرجع خطا
این بخش کدهای خطا و پیامهای خطایی را که برگردانده میشوند و متغیرهای خطا را که توسط Edge تنظیم میشوند، هنگامی که این خطمشی خطا را راهاندازی میکند، توضیح میدهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.
خطاهای زمان اجرا
این خطاها ممکن است هنگام اجرای سیاست رخ دهند.
کد خطا | وضعیت HTTP | علت |
---|---|---|
steps.messagelogging.StepDefinitionExecutionFailed | 500 | رشته خطا را ببینید. |
خطاهای استقرار
این خطاها ممکن است زمانی رخ دهند که یک پروکسی حاوی این خط مشی را مستقر می کنید.
نام خطا | علت | رفع کنید |
---|---|---|
InvalidProtocol | اگر پروتکل مشخص شده در عنصر <Protocol> معتبر نباشد، اجرای سیاست MessageLogging ممکن است با این خطا با شکست مواجه شود. پروتکل های معتبر TCP و UDP هستند. برای ارسال پیام های syslog از طریق TLS/SSL، فقط TCP پشتیبانی می شود. | build |
InvalidPort | اگر شماره پورت در عنصر <Port> مشخص نشده باشد یا اگر معتبر نباشد، استقرار سیاست MessageLogging ممکن است با این خطا با شکست مواجه شود. شماره پورت باید یک عدد صحیح بزرگتر از صفر باشد. | build |
متغیرهای خطا
این متغیرها زمانی تنظیم می شوند که یک خطای زمان اجرا رخ دهد. برای اطلاعات بیشتر، به آنچه باید در مورد خطاهای خط مشی بدانید مراجعه کنید.
متغیرها | کجا | مثال |
---|---|---|
fault.name=" fault_name " | fault_name نام خطا است، همانطور که در جدول خطاهای Runtime در بالا ذکر شده است. نام خطا آخرین قسمت کد خطا است. | 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
موضوعات مرتبط
- متغیرهای در معرض لبه: مرجع متغیرها
شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

چی
یکی از بهترین راهها برای ردیابی مشکلات در محیط زمان اجرا API ، ورود به سیستم است. می توانید یک خط مشی پیام MessageLogging را در API خود وصل و پیکربندی کنید تا پیام های سفارشی را به یک دیسک محلی (لبه فقط برای ابر خصوصی) یا به Syslog وارد کنید.
نمونه ها
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>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 پیکربندی شده است ، یک پروکسی API پیام های ورود به سیستم را از Apigee Edge به یک سرور Syslog از راه دور ارسال می کند. شما در حال حاضر باید یک سرور syslog در دسترس داشته باشید. اگر اینگونه نباشد ، خدمات مدیریت ورود به سیستم عمومی ، چنین چلپ چلوون ، منطق سومو و Loggly در دسترس هستند. به پیکربندی خدمات مدیریت ورود به سیستم شخص ثالث مراجعه کنید.
به عنوان مثال ، تصور کنید که باید اطلاعات مربوط به هر پیام درخواست را که API شما از برنامه های مصرف کننده دریافت می کند ، وارد کنید. مقدار 3f509b58
یک مقدار کلیدی خاص برای سرویس loggly را نشان می دهد. اگر یک حساب loggly دارید ، کلید ورود به سیستم خود را جایگزین کنید. پیام ورود به سیستم که تولید می شود با چهار مقدار جمع می شود: سازمان ، پروکسی API و نام محیط مرتبط با معامله ، به همراه مقدار پارامتر پرس و جو در پیام درخواست.
اگر حاشیه ای برای استقرار ابر خصوصی دارید ، می توانید پیام های ورود به سیستم را نیز در یک پرونده بنویسید.
syslog بیش از TLS/SSL
<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/SSL ارسال کنید.
چرخش پرونده: اندازه
<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 برای Cloud Private مراجعه کنید. | Message | پیام را بسازید تا به پرونده ورود به سیستم ارسال شود و متن را با متغیرها ترکیب کنید تا اطلاعات مورد نظر خود را ضبط کنید. نمونه ها را ببینید. |
FileName | نام پایه پرونده log. مسیر پرونده را مشخص نکنید. به عنوان مثال ، این عنصر FileName یک مسیر پرونده را مشخص می کند و نامعتبر است:<FileName>/opt/apigee/var/log/messages/mylog.log</FileName> این کد فقط یک نام پرونده را مشخص می کند و معتبر است: <FileName>mylog.log</FileName> برای کسب اطلاعات در مورد محل ذخیره پرونده ، به محل ورود پرونده در Edge برای Cloud Private مراجعه کنید. | |
FileRotationOptions | ||
rotateFileOnStartup | ویژگی مقادیر معتبر: اگر روی True تنظیم شود ، هر بار که موتور پیام رسانی دوباره راه اندازی می شود ، پرونده ورود به سیستم چرخانده می شود. | |
FileRotationType | خط مشی چرخش ( size یا time ) یک پرونده ورود را مشخص می کند. | |
MaxFileSizeInMB | (در انتخاب size به عنوان نوع چرخش) اندازه یک پرونده ورود به سیستم را نشان می دهد که سرور را به انتقال پیام های ورود به یک فایل جداگانه سوق می دهد. پس از رسیدن پرونده ورود به اندازه مشخص شده ، سرور پرونده ورود به سیستم فعلی را تغییر می دهد. | |
RotationFrequency | (در انتخاب time به عنوان نوع چرخش) زمان را در دقیقه ها مشخص می کند که سرور را برای انتقال پیام های ورود به یک فایل جداگانه سوق می دهد. پس از گذشت فاصله مشخص شده ، پرونده ورود به سیستم فعلی تغییر نام می یابد. | |
MaxFilesToRetain | حداکثر تعداد پرونده هایی را که باید در زمینه تنظیمات چرخش شما حفظ شود ، مشخص می کند. مقدار پیش فرض 8 است. اگر صفر (0) را مشخص کنید ، پرونده های ورود به سیستم به طور نامحدود حفظ می شوند ، اما منوط به تنظیمات چرخش فایل شما هستند ، اگرچه هیچ یک از پرونده ها حذف یا تغییر نام ندارند. بنابراین ، برای جلوگیری از خطاهای آینده دیسک ، این مقدار را بر روی مقداری بیشتر از صفر تنظیم کنید ، یا یک سیستم منظم و منظم از پاکسازی یا بایگانی پرونده های قدیمی نگهدارنده را پیاده سازی کنید. | |
BufferMessage | اگر جریان HTTP برای پروکسی شما فعال باشد ، پیام های درخواست/پاسخ بافر نمی شوند. اگر می خواهید محتوایی را که نیاز به تجزیه و تحلیل پیام جریان دارد ، وارد کنید ، سپس Buffermessage را روی True تنظیم کنید. برای مثال به برگه نمونه "جریان فعال" مراجعه کنید. پیش فرض: نادرست | |
یک مقصد syslog. برای ارسال Syslog به Splunk ، Sumo Logic یا Loggly ، به پیکربندی خدمات مدیریت ورود به سیستم شخص ثالث مراجعه کنید. | Message | این پیام را بسازید تا به Syslog ارسال شود و متن را با متغیرها ترکیب کنید تا اطلاعات مورد نظر خود را ضبط کنید. نمونه ها را ببینید. توجه: متغیرهای پاسخ به دنبال جریان خطا در PostcleientFlow در دسترس نخواهند بود. برای ورود به اطلاعات پاسخ برای هر دو موقعیت خطا و موفقیت از متغیرهای پیام استفاده کنید. همچنین یادداشت های استفاده را ببینید. |
Host | نام میزبان یا آدرس IP سرور که در آن باید syslog ارسال شود. اگر این عنصر را درج نکنید ، پیش فرض LocalHost است. | |
Port | بندری که در آن syslog در حال اجرا است. اگر این عنصر را درج نکنید ، پیش فرض 514 است. | |
Protocol | TCP یا UDP (پیش فرض). در حالی که UDP عملکرد بیشتری دارد ، پروتکل TCP تحویل ورود به سیستم را به سرور Syslog تضمین می کند. برای ارسال پیام های syslog از طریق TLS/SSL ، فقط TCP پشتیبانی می شود. | |
FormatMessage | اختیاری ، اما این عنصر به شما امکان می دهد قالب محتوای تولید شده توسط Apigee را که به پیام رسیده است ، کنترل کنید. اگر روی True تنظیم شده باشد ، پیام Syslog توسط تعداد مشخصی از کاراکتر ها پیش می رود ، که به شما امکان می دهد این اطلاعات را از پیام ها فیلتر کنید. در اینجا مثالی برای قالب ثابت آورده شده است: اطلاعات تولید شده Apigee شامل موارد زیر است:
اگر روی False (پیش فرض) تنظیم شود ، پیام با آن شخصیت های ثابت پیش بینی نمی شود. | |
PayloadOnly | این عنصر قالب پیام های تولید شده توسط Apigee را تنظیم می کند تا فقط بدنه پیام Syslog را شامل شود ، بدون اینکه شخصیت های پیش بینی شده توسط FormatMessage مشخص شود. اگر این عنصر را وارد نکنید یا آن را خالی بگذارید ، مقدار پیش فرض FormatMessage را ببینید. | |
DateFormat | اختیاری. یک رشته الگوی قالب بندی برای استفاده برای قالب بندی Timestamp برای هر پیام ورود. به طور پیش فرض ، Apigee از | |
SSLInfo | به شما امکان می دهد پیام ها را از طریق SSL/TLS وارد کنید. با عناصر زیر اگر این عنصر را وارد نکنید یا آن را خالی بگذارید ، مقدار پیش فرض نادرست است (بدون TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> شما می توانید برچسب <Sslinfo> را همانند شما در یک نقطه TargetEnd ، از جمله فعال کردن TLS/SSL دو طرفه ، همانطور که در مرجع پیکربندی پروکسی API توضیح داده شده است ، پیکربندی کنید. فقط پروتکل TCP پشتیبانی می شود. | |
logLevel | اختیاری. مقادیر معتبر: یک سطح خاص از اطلاعات را تنظیم کنید تا در گزارش پیام گنجانده شود. اگر از عنصر |
طرحواره ها
نکات استفاده
هنگام اتصال یک خط مشی پیام به یک جریان پروکسی API ، در یک جریان ویژه به نام PostcleientFlow ، آن را در پاسخ ProxyendPoint قرار دهید. PostcleientFlow پس از ارسال پاسخ به مشتری درخواست کننده اجرا می شود ، که تضمین می کند همه معیارها برای ورود به سیستم در دسترس هستند. برای جزئیات بیشتر در مورد استفاده از PostCleientFlow ، به مرجع پیکربندی پروکسی API مراجعه کنید.
PostcleientFlow از دو طریق خاص است:
- این فقط به عنوان بخشی از جریان پاسخ اجرا شد.
- این تنها جریان اجرا شده پس از ورود پروکسی به حالت خطا است.
از آنجا که بدون توجه به اینکه پروکسی موفق یا شکست خورده است ، اجرا می شود ، می توانید سیاست های پیام پیام را در PostclientFlow قرار دهید و تضمین کنید که همیشه آنها را اجرا می کنند.
تصویر ردیابی زیر یک سیاست پیام پیام را به عنوان بخشی از postclientflow ، پس از اجرای پیش فرض فولترول ، نشان می دهد:
در این مثال ، خط مشی Key Verify به دلیل یک کلید نامعتبر باعث ایجاد خطا شده است.
در زیر تعریف ProxyendPoint نشان داده شده است که شامل PostcleientFlow است:
<ProxyEndpoint name="default"> ... <PostClientFlow> <Response> <Step> <Name>Message-Logging-1</Name> </Step> </Response> </PostClientFlow> ... </ProxyEndpoint>
پیام های Edge را به عنوان متن ساده ثبت می کنید ، و می توانید ورود به سیستم را پیکربندی کنید تا متغیرهایی را شامل شود ، مانند تاریخ و زمان دریافت درخواست یا پاسخ ، هویت کاربر در درخواست ، آدرس IP منبع که از آن درخواست ارسال شده است و غیره. Edge Logs پیام ناهمزمان ، به این معنی که هیچ تأخیر که ممکن است در اثر مسدود کردن فراخوان ها ایجاد شود به API شما معرفی نمی شود.
خط مشی پیام پیام پیام های وارد شده در حافظه را به یک بافر می نویسد. پیامگر پیام پیام هایی را از بافر می خواند و سپس به مقصدی که پیکربندی می کنید می نویسد. هر مقصد بافر خاص خود را دارد.
اگر نرخ نوشتن به بافر فراتر از نرخ خواندن افزایش یابد ، سرریز بافر و ورود به سیستم از بین می رود. اگر این اتفاق بیفتد ، ممکن است پیامی را در پرونده ورود به سیستم پیدا کنید:
Log message size exceeded. Increase the max message size setting
اگر با این مسئله در Edge for Private Cloud 4.15.07 و قبل از آن روبرو شدید ، پرونده message-logging.properties
پیدا کرده و از این راه حل استفاده کنید:
ویژگی max.log.message.size.in.kb
(مقدار پیش فرض = 128 کیلوبایت) را در پرونده message-logging.properties
افزایش دهید.
برای Edge for Private Cloud 4.16.01 و بعد ، conf/message-logging.properties+max. log.message.size.in.kb
ویژگی conf/message-logging.properties+max. log.message.size.in.kb
در /opt/apigee/customer/application/message-processor.properties پرونده و مجدداً پردازنده پیام را مجدداً راه اندازی کنید. لطفاً توجه داشته باشید که این ویژگی در ابتدا به طور پیش فرض اظهار نظر می شود.
توجه: متغیرهای پیام پاسخ در Edge از جریان خطا در دسترس نیست. اگر جریان قبلی جریان خطا باشد ، این متغیرها در PostcleientFlow نیز در دسترس نیستند. اگر می خواهید اطلاعات پاسخ را از PostclientFlow وارد کنید ، از شیء پیام استفاده کنید. شما می توانید از این شیء برای دریافت هدر و سایر اطلاعات از پاسخ استفاده کنید که آیا خطایی رخ داده است یا خیر. برای اطلاعات بیشتر و یک مثال به متغیرهای پیام مراجعه کنید.
کنترل جدول زمانی پیام ورود به سیستم در لبه برای ابر خصوصی
به طور پیش فرض ، Timestamp در تمام پیام های ورود به سیستم دارای فرمت است:
yyyy-MM-dd'T'HH:mm:ss.SSSZ
این پیش فرض در سطح سیستم با استفاده از عنصر DateFormat
می تواند برای مقصد Syslog نادیده گرفته شود. رفتار این الگوی در مستندات کلاس SimpleDateFormat جاوا شرح داده شده است. طبق این تعریف ، yyyy
با یک سال 4 رقمی جایگزین می شود ، MM
با شماره 2 رقمی و غیره جایگزین می شود. قالب فوق ممکن است به رشته ای از این فرم منجر شود:
2022-09-28T22:38:11.721+0000
برای کنترل آن قالب می توانید از ویژگی های conf_system_apigee.syslogger.dateformat در پردازنده پیام Edge استفاده کنید. به عنوان مثال ، تغییر قالب پیام به:
yy/MM/dd'T'HH:mm:ss.SSSZ
.. تنظیم مجدد خط ها با بریدگی ، و کوتاه شدن به یک سال 2 رقمی ، یک جدول زمانی را به شکل ثبت می کند:
22/09/28T22:38:11.721+0000
برای تغییر قالب:
- پرونده پیام-پردازشگر. properties را در یک ویرایشگر باز کنید. اگر پرونده وجود ندارد ، آن را ایجاد کنید:
> vi /opt/apigee/customer/application/message-processor.properties - خواص را به دلخواه تنظیم کنید:
conf_system_apigee.syslogger.dateformat = yy/mm/dd't'hh: mm: ss.sssz - تغییرات خود را ذخیره کنید
- اطمینان حاصل کنید که پرونده Properties متعلق به کاربر "Apigee" است:
> apigee chown: apigee /opt/apigee/customer/application/message-processor.properties - پردازنده پیام Edge را مجدداً راه اندازی کنید:
>/opt/apigee/apigee-service/bin/apigee-service edge-message-processor راه اندازی مجدد
ورود به سیستم پرونده در لبه برای ابر خصوصی
لبه برای ابر خصوصی 4.16.01 و بعد
به طور پیش فرض ، سیاهههای مربوط به پیام های ابری خصوصی در فهرست زیر در گره های پردازنده پیام قرار دارند:
/opt/apigee/var/log/edge-message-processor/messagelogging/org_name/environment/api_proxy_name/revision/logging_policy_name/
می توانید با تغییر ویژگی ها در پرونده پیام-logging.properties در پردازنده های پیام ، مکان ورود به سیستم پیش فرض را تغییر دهید:
- 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 ارجاع دهید زیرا به طور پیش فرض اظهار نظر می شود. به تنظیم یک نشانه که در حال حاضر برای اطلاعات بیشتر اظهار نظر می کند ، مراجعه کنید.
اگر می خواهید پرونده های ورود به سیستم را در یک ساختار فایل مسطح ذخیره کنید تا تمام پرونده های ورود به سیستم در یک دایرکتوری قرار گیرند ، Conf/Message-logging.properties+Enable.flat.directory.structure را در پرونده پیام-logging.properties تنظیم کنید. پیام ها در دایرکتوری مشخص شده توسط خصوصیات بالا ذخیره می شوند ، و نام پرونده ها به شکل {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}
.
برای تنظیم این خصوصیات:
- پرونده پیام-پردازشگر. properties را در یک ویرایشگر باز کنید. اگر پرونده وجود ندارد ، آن را ایجاد کنید:
> vi /opt/apigee/customer/application/message-processor.properties - خواص را به دلخواه تنظیم کنید:
Conf/Message-logging.properties+log.root.dir = /opt/apigee/var/log/پیام ها - تغییرات خود را ذخیره کنید
- اطمینان حاصل کنید که پرونده Properties متعلق به کاربر "Apigee" است:
> apigee chown: apigee /opt/apigee/customer/application/message-processor.properties - مؤلفه لبه را مجدداً راه اندازی کنید:
>/opt/apigee/apigee-service/bin/apigee-service edge-message-processor راه اندازی مجدد
لبه برای ابر خصوصی 4.15.07 و زودتر
به طور پیش فرض ، گزارش های پیام در مکان زیر در پردازنده های پیام قرار دارند:
/opt/apigee4/var/log/apigee/message-processor/messagelog/{org}/{environment}/{api_proxy_name}/{revision}/{logging_policy_name}/
می توانید با تغییر ویژگی های زیر در پرونده پیام-logging.properties در پردازنده های پیام ، مکان ورود به سیستم پیش فرض را تغییر دهید:
- data.dir - مسیر ریشه را برای ذخیره سازی پرونده ورود به سیستم تنظیم می کند. به عنوان مثال ، data.dir =/opt/apigee4/var/log
- log.root.dir - اگر این کار را در یک مسیر نسبی تنظیم کنید ، مانند log.root.dir = سفارشی/پوشه/، مسیر به محل data.dir اضافه می شود.
به عنوان مثال ، ترکیب این دو ویژگی می تواند فهرست ورود به سیستم را در/OPT/APIGEE4/VAR/LOG/CUSTOR/FOLTER/MessageLog/(توجه داشته باشید که/پیام به طور خودکار اضافه می شود).
اگر این کار را در یک مسیر مطلق تنظیم کنید ، مانند log.root.dir =/opt/apigee4/var/log/پیام ها ، گزارش های پیام در/opt/apigee4/var/log/message/messageLog ذخیره می شوند. یک مسیر مطلق در log.root.dir بر Data.dir تقدم می کند.
اگر می خواهید پرونده های ورود به سیستم را در یک ساختار فایل مسطح ذخیره کنید تا تمام پرونده های ورود به سیستم در یک دایرکتوری قرار گیرند ، ویژگی Enable.flat.directory.structure را در پرونده پیام-logging.properties در پردازنده های پیام تنظیم کنید. پیام ها در دایرکتوری مشخص شده توسط خصوصیات بالا ذخیره می شوند ، و نام پرونده ها به شکل {org} _ {محیط} _ {api_proxy_name} _ {Revision} _ {logging_policy_name} _ {نام پرونده} .
مقادیر پیش فرض برای متغیرها در الگوی پیام
مقادیر پیش فرض را می توان برای هر متغیر در الگوی پیام به طور جداگانه مشخص کرد. به عنوان مثال ، اگر متغیر request.header.id
قابل حل نیست ، مقدار آن با مقدار unknown
جایگزین می شود.
<Message>This is a test message. id = {request.header.id:unknown}</Message>
یک مقدار پیش فرض مشترک را می توان برای همه متغیرهای حل نشده با تنظیم ویژگی defaultVariableValue
در عنصر Message
مشخص کرد:
<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>
پیکربندی خدمات مدیریت ورود به سیستم شخص ثالث
خط مشی MessageLogging به شما امکان می دهد پیام های SYSLOG را به خدمات مدیریت ورود به سیستم شخص ثالث مانند Splunk ، Sumo Logic و Loggly ارسال کنید. اگر می خواهید Syslog را به یکی از این خدمات ارسال کنید ، برای پیکربندی میزبان ، پورت و پروتکل سرویس ، به اسناد سرویس مراجعه کنید ، سپس عنصر Syslog را بر این اساس تنظیم کنید.
مستندات زیر را برای پیکربندی مدیریت ورود به سیستم شخص ثالث مشاهده کنید:
- Splunk (نسخه محصول را انتخاب کنید)
همچنین این پست جامعه Apigee را ببینید: https://community.apigee.com/content/kbentry/13298/log-messages-into-splunk.html - سومو منطق
- همچنین به این پست جامعه Apigee مراجعه کنید: https://community.apigee.com/questions/5226/setting-up-logging-with-sumo-logic-which-host-hest-hestml
- برای مثال کامل با استفاده از SUMO Logic به عنوان سرویس ورود به سیستم ، به پست انجمن Apigee زیر مراجعه کنید. راه حل از یک خط مشی JavaScript واحد استفاده می کند تا درخواست های HTTP را به SUMO Logic Http Source جمع آوری کند: https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html
- لاگ
هنگام استفاده از Loggly ،<FormatMessage>true</FormatMessage>
در این خط مشی به عنوان فرزند عنصر<Syslog>
لازم است.
همچنین برای اطلاعات بیشتر در مورد ورود به سیستم به Loggly: https://community.apigee.com/content/kbentry/14798/log-messages-into-loggly.html این پست انجمن Apigee را ببینید.
مرجع خطا
این بخش کدهای خطا و پیامهای خطایی را که برگردانده میشوند و متغیرهای خطا را که توسط Edge تنظیم میشوند، هنگامی که این خطمشی خطا را راهاندازی میکند، توضیح میدهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.
خطاهای زمان اجرا
این خطاها ممکن است هنگام اجرای سیاست رخ دهند.
کد خطا | وضعیت HTTP | علت |
---|---|---|
steps.messagelogging.StepDefinitionExecutionFailed | 500 | رشته خطا را ببینید. |
خطاهای استقرار
این خطاها ممکن است زمانی رخ دهند که یک پروکسی حاوی این خط مشی را مستقر می کنید.
نام خطا | علت | رفع کنید |
---|---|---|
InvalidProtocol | اگر پروتکل مشخص شده در عنصر <Protocol> معتبر نباشد، اجرای سیاست MessageLogging ممکن است با این خطا با شکست مواجه شود. پروتکل های معتبر TCP و UDP هستند. برای ارسال پیام های syslog از طریق TLS/SSL، فقط TCP پشتیبانی می شود. | build |
InvalidPort | اگر شماره پورت در عنصر <Port> مشخص نشده باشد یا اگر معتبر نباشد، استقرار سیاست MessageLogging ممکن است با این خطا با شکست مواجه شود. شماره پورت باید یک عدد صحیح بزرگتر از صفر باشد. | build |
متغیرهای خطا
این متغیرها زمانی تنظیم می شوند که یک خطای زمان اجرا رخ دهد. برای اطلاعات بیشتر، به آنچه باید در مورد خطاهای خط مشی بدانید مراجعه کنید.
متغیرها | کجا | مثال |
---|---|---|
fault.name=" fault_name " | fault_name نام خطا است، همانطور که در جدول خطاهای Runtime در بالا ذکر شده است. نام خطا آخرین قسمت کد خطا است. | 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
موضوعات مرتبط
- متغیرهای در معرض لبه: مرجع متغیرها
شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

چی
یکی از بهترین راهها برای ردیابی مشکلات در محیط زمان اجرا API ، ورود به سیستم است. می توانید یک خط مشی پیام MessageLogging را در API خود وصل و پیکربندی کنید تا پیام های سفارشی را به یک دیسک محلی (لبه فقط برای ابر خصوصی) یا به Syslog وارد کنید.
نمونه ها
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>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 پیکربندی شده است ، یک پروکسی API پیام های ورود به سیستم را از Apigee Edge به یک سرور Syslog از راه دور ارسال می کند. شما در حال حاضر باید یک سرور syslog در دسترس داشته باشید. اگر اینگونه نباشد ، خدمات مدیریت ورود به سیستم عمومی ، چنین چلپ چلوون ، منطق سومو و Loggly در دسترس هستند. به پیکربندی خدمات مدیریت ورود به سیستم شخص ثالث مراجعه کنید.
به عنوان مثال ، تصور کنید که باید اطلاعات مربوط به هر پیام درخواست را که API شما از برنامه های مصرف کننده دریافت می کند ، وارد کنید. مقدار 3f509b58
یک مقدار کلیدی خاص برای سرویس loggly را نشان می دهد. اگر یک حساب loggly دارید ، کلید ورود به سیستم خود را جایگزین کنید. پیام ورود به سیستم که تولید می شود با چهار مقدار جمع می شود: سازمان ، پروکسی API و نام محیط مرتبط با معامله ، به همراه مقدار پارامتر پرس و جو در پیام درخواست.
اگر حاشیه ای برای استقرار ابر خصوصی دارید ، می توانید پیام های ورود به سیستم را نیز در یک پرونده بنویسید.
syslog بیش از TLS/SSL
<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/SSL ارسال کنید.
چرخش پرونده: اندازه
<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 برای Cloud Private مراجعه کنید. | Message | پیام را بسازید تا به پرونده ورود به سیستم ارسال شود و متن را با متغیرها ترکیب کنید تا اطلاعات مورد نظر خود را ضبط کنید. نمونه ها را ببینید. |
FileName | نام پایه پرونده log. مسیر پرونده را مشخص نکنید. به عنوان مثال ، این عنصر FileName یک مسیر پرونده را مشخص می کند و نامعتبر است:<FileName>/opt/apigee/var/log/messages/mylog.log</FileName> این کد فقط یک نام پرونده را مشخص می کند و معتبر است: <FileName>mylog.log</FileName> برای کسب اطلاعات در مورد محل ذخیره پرونده ، به محل ورود پرونده در Edge برای Cloud Private مراجعه کنید. | |
FileRotationOptions | ||
rotateFileOnStartup | ویژگی مقادیر معتبر: اگر روی True تنظیم شود ، هر بار که موتور پیام رسانی دوباره راه اندازی می شود ، پرونده ورود به سیستم چرخانده می شود. | |
FileRotationType | خط مشی چرخش ( size یا time ) یک پرونده ورود را مشخص می کند. | |
MaxFileSizeInMB | (در انتخاب size به عنوان نوع چرخش) اندازه یک پرونده ورود به سیستم را نشان می دهد که سرور را به انتقال پیام های ورود به یک فایل جداگانه سوق می دهد. پس از رسیدن پرونده ورود به اندازه مشخص شده ، سرور پرونده ورود به سیستم فعلی را تغییر می دهد. | |
RotationFrequency | (در انتخاب time به عنوان نوع چرخش) زمان را در دقیقه ها مشخص می کند که سرور را برای انتقال پیام های ورود به یک فایل جداگانه سوق می دهد. پس از گذشت فاصله مشخص شده ، پرونده ورود به سیستم فعلی تغییر نام می یابد. | |
MaxFilesToRetain | حداکثر تعداد پرونده هایی را که باید در زمینه تنظیمات چرخش شما حفظ شود ، مشخص می کند. مقدار پیش فرض 8 است. اگر صفر (0) را مشخص کنید ، پرونده های ورود به سیستم به طور نامحدود حفظ می شوند ، اما منوط به تنظیمات چرخش فایل شما هستند ، اگرچه هیچ یک از پرونده ها حذف یا تغییر نام ندارند. بنابراین ، برای جلوگیری از خطاهای آینده دیسک ، این مقدار را بر روی مقداری بیشتر از صفر تنظیم کنید ، یا یک سیستم منظم و منظم از پاکسازی یا بایگانی پرونده های قدیمی نگهدارنده را پیاده سازی کنید. | |
BufferMessage | اگر جریان HTTP برای پروکسی شما فعال باشد ، پیام های درخواست/پاسخ بافر نمی شوند. اگر می خواهید محتوایی را که نیاز به تجزیه و تحلیل پیام جریان دارد ، وارد کنید ، سپس Buffermessage را روی True تنظیم کنید. برای مثال به برگه نمونه "جریان فعال" مراجعه کنید. پیش فرض: نادرست | |
یک مقصد syslog. برای ارسال Syslog به Splunk ، Sumo Logic یا Loggly ، به پیکربندی خدمات مدیریت ورود به سیستم شخص ثالث مراجعه کنید. | Message | این پیام را بسازید تا به Syslog ارسال شود و متن را با متغیرها ترکیب کنید تا اطلاعات مورد نظر خود را ضبط کنید. نمونه ها را ببینید. توجه: متغیرهای پاسخ به دنبال جریان خطا در PostcleientFlow در دسترس نخواهند بود. برای ورود به اطلاعات پاسخ برای هر دو موقعیت خطا و موفقیت از متغیرهای پیام استفاده کنید. همچنین یادداشت های استفاده را ببینید. |
Host | نام میزبان یا آدرس IP سرور که در آن باید syslog ارسال شود. اگر این عنصر را درج نکنید ، پیش فرض LocalHost است. | |
Port | بندری که در آن syslog در حال اجرا است. اگر این عنصر را درج نکنید ، پیش فرض 514 است. | |
Protocol | TCP یا UDP (پیش فرض). در حالی که UDP عملکرد بیشتری دارد ، پروتکل TCP تحویل ورود به سیستم را به سرور Syslog تضمین می کند. برای ارسال پیام های syslog از طریق TLS/SSL ، فقط TCP پشتیبانی می شود. | |
FormatMessage | اختیاری ، اما This element lets you control the format of Apigee-generated content prepended to the message. If set to true, the syslog message is prepended by a fixed number of characters, which lets you filter out that information from messages. Here's an example for the fixed format: The Apigee-generated information includes:
If set to false (default), the message is not prepended with those fixed characters. | |
PayloadOnly | This element sets the format of Apigee-generated messages to contain only the body of the syslog message, without the prepended characters specified by FormatMessage . If you don't include this element or leave it empty, the default value is See FormatMessage . | |
DateFormat | اختیاری. A formatting template string to use to format the timestamp for each log message. By default, Apigee uses | |
SSLInfo | Lets you log messages through SSL/TLS. Use with sub-element If you don't include this element or leave it empty, the default value is false (no TLS/SSL). <SSLInfo> <Enabled>true</Enabled> </SSLInfo> You can configure the <SSLInfo> tag the same as you can on a TargetEndpoint, including enabling two-way TLS/SSL, as described in API proxy configuration reference . Only the TCP protocol is supported. | |
logLevel | اختیاری. Valid values: Set a specific level of information to be included in the message log. If you're using the |
طرحواره ها
نکات استفاده
When attaching a MessageLogging policy to an API proxy flow, consider placing it in the ProxyEndpoint response, in a special flow called PostClientFlow. The PostClientFlow executes after the response is sent to the requesting client, which ensures that all metrics are available for logging. For details on using PostClientFlow, see API proxy configuration reference .
The PostClientFlow is special in two ways:
- It only executed as part of the response flow.
- It is the only flow executed after the proxy enters the error state.
Because it is executed regardless of whether the proxy succeeded or failed, you can put MessageLogging policies in the PostClientFlow and be guaranteed that they always execute.
The following Trace image shows a MessageLogging policy executing as part of the PostClientFlow, after the DefaultFaultRule executes:
In this example, the Verify API Key policy caused the fault because of an invalid key.
Shown below is the ProxyEndpoint definition that includes the PostClientFlow:
<ProxyEndpoint name="default"> ... <PostClientFlow> <Response> <Step> <Name>Message-Logging-1</Name> </Step> </Response> </PostClientFlow> ... </ProxyEndpoint>
Edge logs messages as simple text, and you can configure logging to include variables, such as the date and time when the request or response was received, the user identity on the request, the source IP address from which the request was sent, and so on. Edge logs message asynchronously, meaning that no latency that might be caused by blocking callouts is introduced to your API.
The MessageLogging policy writes logged messages in memory to a buffer. The message logger reads messages from the buffer and then writes to the destination that you configure. Each destination has its own buffer.
If the write rate to the buffer increases beyond the read rate, the buffer overflows and logging will fail. If this happens, you might find a message containing the following in the log file:
Log message size exceeded. Increase the max message size setting
If you encounter this issue in Edge for Private Cloud 4.15.07 and earlier, locate the message-logging.properties
file and use this solution:
Increase the max.log.message.size.in.kb
property (default value = 128 KB) in the message-logging.properties
file.
For Edge for Private Cloud 4.16.01 and later, set the conf/message-logging.properties+max. log.message.size.in.kb
property in the /opt/apigee/customer/application/message-processor.properties file and restart the Message Processor. Please note that this property is initially commented out by default.
Note: The response message variables in Edge are not available from the Error Flow. These variables are also not available in PostClientFlow if the preceding flow was the Error Flow. If you want to log response information from the PostClientFlow, use the message object. You can use this object to get at headers and other information from the response whether or not there was an error. See Message variables for more information and an example.
Controlling log message timestamp in Edge for Private Cloud
By default, the timestamp in all log messages has the format:
yyyy-MM-dd'T'HH:mm:ss.SSSZ
This system-wide default can be overridden for syslog destinations using the DateFormat
element. The behavior of this template is described in the documentation for Java's SimpleDateFormat class . According to that definition, yyyy
will be replaced with a 4-digit year, MM
will be replaced with a 2-digit month number, and so on. The above format might result in a string of this form:
2022-09-28T22:38:11.721+0000
You can use the conf_system_apigee.syslogger.dateFormat property on the Edge Message Processor to control that format. For example, changing the message format to:
yy/MM/dd'T'HH:mm:ss.SSSZ
..replacing the dashes with slashes, and shortening to a 2-digit year, records a timestamp in the form:
22/09/28T22:38:11.721+0000
To change the format:
- Open the message-processor.properties file in an editor. If the file does not exist, create it:
> vi /opt/apigee/customer/application/message-processor.properties - Set the properties as desired:
conf_system_apigee.syslogger.dateFormat=yy/MM/dd'T'HH:mm:ss.SSSZ - تغییرات خود را ذخیره کنید
- Make sure the properties file is owned by the 'apigee' user:
> chown apigee:apigee /opt/apigee/customer/application/message-processor.properties - Restart the Edge Message Processor:
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Log file location in Edge for Private Cloud
Edge for Private Cloud 4.16.01 and later
By default, Private Cloud message logs are located in the following directory on Message Processor nodes:
/opt/apigee/var/log/edge-message-processor/messagelogging/org_name/environment/api_proxy_name/revision/logging_policy_name/
You can change the default log location by modifying properties in the message-logging.properties file on the Message Processors:
- bin_setenv_data_dir - Sets the root path for log file storage. For example,
bin_setenv_data_dir=/opt/apigee/var/log
- conf_message-logging_log.root.dir - If you set this to a relative path, such as
conf/message-logging.properties+log.root.dir=custom/folder/
, the path is appended to the bin_setenv_data_dir location.
If you set this to an absolute path, such asconf/message-logging.properties+log.root.dir=/opt/apigee/var/log/messages
, message logs will be stored in/opt/apigee/var/log/messages/messagelog/
. An absolute path takes precedence overbin_setenv_data_dir
.
Note that you have to reference the property as conf/message-logging.properties+log.root.dir because it is commented out by default. See Setting a token that is currently commented out for more.
If you want to store log files in a flat file structure so that all log files are put in the same directory, set the conf/message-logging.properties+enable.flat.directory.structure to true in the message-logging.properties file. Messages are stored in the directory specified by the properties above, and the file names take the form of {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename}
.
To set these properties:
- Open the message-processor.properties file in an editor. If the file does not exist, create it:
> vi /opt/apigee/customer/application/message-processor.properties - Set the properties as desired:
conf/message-logging.properties+log.root.dir= /opt/apigee/var/log/messages - تغییرات خود را ذخیره کنید
- Make sure the properties file is owned by the 'apigee' user:
> chown apigee:apigee /opt/apigee/customer/application/message-processor.properties - Restart the Edge component:
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Edge for Private Cloud 4.15.07 and earlier
By default, message logs are located in the following location on message processors:
/opt/apigee4/var/log/apigee/message-processor/messagelog/{org}/{environment}/{api_proxy_name}/{revision}/{logging_policy_name}/
You can change the default log location by modifying the following properties in the message-logging.properties file on the message processors:
- data.dir - Sets the root path for log file storage. For example, data.dir=/opt/apigee4/var/log
- log.root.dir - If you set this to a relative path, such as log.root.dir=custom/folder/, the path is appended to the data.dir location.
For example, the combination of the two properties would set the logging directory at /opt/apigee4/var/log/custom/folder/messagelog/ (note that /messagelog is added automatically).
If you set this to an absolute path, such as log.root.dir=/opt/apigee4/var/log/messages , message logs will be stored in /opt/apigee4/var/log/messages/messagelog/. An absolute path in log.root.dir takes precedence over data.dir .
If you want to store log files in a flat file structure so that all log files are put in the same directory, set the enable.flat.directory.structure property to true in the message-logging.properties file on Message Processors. Messages are stored in the directory specified by the properties above, and the file names take the form of {org}_{environment}_{api_proxy_name}_{revision}_{logging_policy_name}_{filename} .
Default values for variables in message template
Default values can be specified for each variable in message template separately. For example, if the variable request.header.id
cannot be resolved, then its value is replaced with the value unknown
.
<Message>This is a test message. id = {request.header.id:unknown}</Message>
A common default value can be specified for all the unresolved variables by setting the defaultVariableValue
attribute on the Message
element:
<Message defaultVariableValue="unknown">This is a test message. id = {request.header.id}</Message>
Configuring third-party log management services
The MessageLogging policy lets you send syslog messages to third-party log management services, such as Splunk, Sumo Logic, and Loggly. If you want to send syslog to one of those services, see that service's documentation to configure the service's host, port, and protocol, then set the Syslog element on this policy accordingly.
See the following documentation for third-party log management configuration:
- Splunk (select the product version)
Also see this Apigee Community post: https://community.apigee.com/content/kbentry/13298/log-messages-into-splunk.html - سومو منطق
- Also see this Apigee Community post: https://community.apigee.com/questions/5226/setting-up-logging-with-sumo-logic-which-host-shou.html
- For a complete example using Sumo Logic as the logging service, see the following Apigee Community post. The solution uses a single JavaScript policy to make HTTP POST requests to Sumo Logic HTTP Source Collector: https://community.apigee.com/articles/32286/logging-to-sumo-logic-using-javascript-and-http.html
- لاگ
When using Loggly,<FormatMessage>true</FormatMessage>
is required in the policy as a child of the<Syslog>
element.
Also see this Apigee Community post for more information about message logging to Loggly: https://community.apigee.com/content/kbentry/14798/log-messages-into-loggly.html
مرجع خطا
این بخش کدهای خطا و پیامهای خطایی را که برگردانده میشوند و متغیرهای خطا را که توسط Edge تنظیم میشوند، هنگامی که این خطمشی خطا را راهاندازی میکند، توضیح میدهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.
خطاهای زمان اجرا
این خطاها ممکن است هنگام اجرای سیاست رخ دهند.
کد خطا | وضعیت HTTP | علت |
---|---|---|
steps.messagelogging.StepDefinitionExecutionFailed | 500 | رشته خطا را ببینید. |
خطاهای استقرار
این خطاها ممکن است زمانی رخ دهند که یک پروکسی حاوی این خط مشی را مستقر می کنید.
نام خطا | علت | رفع کنید |
---|---|---|
InvalidProtocol | اگر پروتکل مشخص شده در عنصر <Protocol> معتبر نباشد، اجرای سیاست MessageLogging ممکن است با این خطا با شکست مواجه شود. پروتکل های معتبر TCP و UDP هستند. برای ارسال پیام های syslog از طریق TLS/SSL، فقط TCP پشتیبانی می شود. | build |
InvalidPort | اگر شماره پورت در عنصر <Port> مشخص نشده باشد یا اگر معتبر نباشد، استقرار سیاست MessageLogging ممکن است با این خطا با شکست مواجه شود. شماره پورت باید یک عدد صحیح بزرگتر از صفر باشد. | build |
متغیرهای خطا
این متغیرها زمانی تنظیم می شوند که یک خطای زمان اجرا رخ دهد. برای اطلاعات بیشتر، به آنچه باید در مورد خطاهای خط مشی بدانید مراجعه کنید.
متغیرها | کجا | مثال |
---|---|---|
fault.name=" fault_name " | fault_name نام خطا است، همانطور که در جدول خطاهای Runtime در بالا ذکر شده است. نام خطا آخرین قسمت کد خطا است. | 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>
Flow variables
The following variables are populated on policy failure.
-
messagelogging.failed
-
messagelogging.{stepdefinition-name}.failed
موضوعات مرتبط
- Variables exposed by Edge: Variables reference