شما در حال مشاهده اسناد 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 | نام فایل گزارشی که پیام در آن ثبت شده است. | |
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/
ذخیره میشوند./opt/apigee/var/log/messages/messagelog/
. یک مسیر مطلق برbin_setenv_data_dir
اولویت دارد.
توجه داشته باشید که باید ویژگی را به صورت conf/message-logging.properties+log.root.dir ارجاع دهید زیرا به صورت پیشفرض نظر داده میشود. برای اطلاعات بیشتر به تنظیم نشانه ای که در حال حاضر نظر داده شده است مراجعه کنید.
اگر میخواهید فایلهای گزارش را در یک ساختار فایل مسطح ذخیره کنید تا همه فایلهای 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: مرجع متغیرها