قابلیت مشاهده‌ پذیری (observability) در WSO2

2024-02-12

مشاهدهپذیری را میتوان به عنوان یک مجموعه قابلیت در حوزه‌ی نظارت بر عملکرد سیستم در نظر گرفت که در آن نظارت با قابلیتهایی برای انجام اشکالزدایی و نمایهسازی از طریق تجزیه و تحلیل لاگ، همبستگی و ردیابی پیشرفته ارائه می‌شود. مشاهده‌پذیری مدرن امروزی بر سه پایه‌ی logs (لاگ‌ها یا گزارشات)، metrics (معیارها) و tracing (ردیابی) استوار است. کسب‌وکارهای مدرن به سیستم‌های مشاهده‌پذیری نیاز دارند تا به‌طور خودکفایی وضعیت فعلی خود را منتشر کنند، هشدارهایی را برای هر گونه ناهنجاری شناسایی شده برای شناسایی فعالانه خرابی‌ها نمایش داده و اطلاعاتی برای یافتن دلایل بروز خطا ارائه کنند. در ادامه این مطلب با شرکت دانش بنیان پلتکو همراه باشید.

Logs (لاگ ها یا گزارشات)

Correlation Logs (لاگ‌های مربوط به همبستگی)

قابلیت مشاهده در WSO2 API Manager (WSO2 API-M) برای اشکالزدایی مسائل در یک دوره کوتاه بسیار مهم است. WSO2 API-M با ثبت نکات مهم زیر از سیستم با زمان صرفشده برای دستیابی به آنها، مشاهده را تسهیل می‌کند.

Method Calls (فراخوانی‌های متد)
External Calls (HTTP/HTTPS) (فراخوانی‌های خارجی)
Database Calls (JDBC and LDAP) (فراخوانی‌های پایگاه داده)

علاوه بر این، هنگامی که قابلیت مشاهده در WSO2 API-M فعال است، یک Correlation ID (شناسه همبستگی) تصادفی در WSO2 API-M برای هر تراکنش ایجاد می‌شود که به شما امکان می‌دهد سه نوع فراخوانی آخر را به هم مرتبط کنید.

بنابراین، درخواست‌ها و پاسخ‌هایی که با یک فراخوانی API خاص مطابقت دارند، در یک شناسه همبستگی ثبت می‌شوند که تجزیه و تحلیل اطلاعات را آسان‌تر می‌کند. در صورت نیاز، می‌توانید با افزودن activityid در header درخواست ارسال شده به WSO2 API-M، یک شناسه همبستگی منحصر به فرد ارائه دهید.

توجه

قابلیت مشاهده‌پذیری به‌طور پیش‌فرض فعال نیست، زیرا کمی بر پرفورمنس API Manager تأثیر می‌گذارد.

Enabling Correlation Logs (فعال کردن لاگهای همبستگی)

فعال کردن قابلیت مشاهده در API Manager ساده است. تنها کاری که باید انجام دهید این است که property (ویژگی) سیستم زیر را در اسکریپت راه اندازی محصول (ذخیره شده در مسیر <API-M_HOME>/bin/) پیدا کنید و آن را روی true تنظیم کنید. به طور پیش فرض، این روی false تنظیم شده است.

-DenableCorrelationLogs=true

نکته

همچنین، می توانید مشاهده پذیری را در زمان راه اندازی سرور WSO2 API-M به صورت زیر فعال کنید:

Linux/Mac OS

sh api-manager.sh -DenableCorrelationLogs=true start

Windows

api-manager.bat –run -DenableCorrelationLogs=true start

توجه

وقتی قابلیت مشاهده در WSO2 API Manager فعال است، یک فایل لاگ جداگانه به نام correlation.log در فهرست <API-M_HOME>/repository ایجاد می‌شود.

External Calls (فراخوانی‌های خارجی)

می‌توانید لاگ‌های همبستگی را در WSO2 API-M فعال کنید تا مسیر رفت و برگشت کامل یک پیام HTTP را ردیابی کنید. این به معنای نظارت بر درخواست‌های HTTP از نقطه‌ای است که یک پیام توسط WSO2 API-M دریافت می‌شود تا زمانی که پیام پاسخ مربوطه به فرستنده پیام اصلی بازگردانده شود (client → API-M → back-end → API-M → client ).

External call logs with API-M specific information

(لاگ فراخوانی‌های خارجی با اطلاعات خاص API-M)

تمام فراخوانی‌های خارجی انجام شده توسط Manager API از طریق این دسته ثبت می‌شود. توجه داشته باشید که این شامل فراخوانی‌های DB نمی‌شود.

این کار از طریق یک Synapse Global Handler انجام می‌شود که اطلاعات مهم فراخوانی‌های خارجی را ثبت می‌کند. فرمت ورودی لاگ فراخوانی خارجی در سطح کنترل کننده جهانی Synapse به شرح زیر است:

قالب

مثال

فیلد	توضیحات
timestamp	زمانی که لاگ ایجاد می‌شود. مثال: 2021-11-28 10:10:56,293
correlationID	هر لاگ حاوی یک شناسه همبستگی است که منحصر به درخواست HTTP است. یک کلاینت می‌تواند یک شناسه همبستگی منحصر به فرد را در هدر activityID درخواست HTTP ارسال کند. اگر این شناسه همبستگی در درخواست ورودی وجود نداشته باشد، WSO2 API-M یک شناسه همبستگی تصادفی برای درخواست ایجاد می‌کند. مثال: a783f7c3-647f-4d10-9b72-106faa01bba8
threadName	شناسه ریسمان مثال: PassThroughMessageProcessor-4
Duration (BE Latency)	فاصله زمانی (بر حسب میلی ثانیه) بین دو حالت پیام. مثال: 0
callType	HTTP – نوع فراخوانی، لاگ‌هایی را شناسایی می‌کند که با وضعیت تأخیر پشتیبان یا وضعیت تأخیر رفت و برگشت مطابقت دارند. بنابراین، در صورت درخواست فردی، یک لاگ برای شناسایی تأخیر بک‌اند و لاگ دیگری برای تأخیر رفت و برگشت ثبت می‌شود. این لاگ‌ها با استفاده از نوع فراخونی HTTP دسته‌بندی می‌شوند، زیرا این لاگ‌ها به فراخوانی‌های HTTP بین WSO2 API-M و کلاینت‌های خارجی مربوط می‌شوند.
apiName	نام کلاس متدی که فراخوانی شد. مثال: admin–PizzaShackAPI:v1.0.0
apiMethod	نام متدی که فراخوانی شد. مثال: GET
apiContext	زمینه API که فراخوانی شد.
apiResourcePath	مسیر منبع API که فراخوانی شد. مثال: /pizzashack/1.0.0/menu
authHeader	هدر Authorization (احراز هویت) را ثبت می‌کند.
orgIdHeader	هدر organization-id (شناسه سازمان) را ثبت می‌کند.
SrcIdHeader	هدر source-id (شناسه منبع) را ثبت می‌کند.
applIdHeader	هدر application-id (شناسه برنامه) را ثبت می‌کند.
uuIdHeader	هدر uuid را ثبت می‌کند.
requestSize	اندازه payload (محموله) درخواست مثال: 71
responseSize	اندازه payload (محموله) پاسخ مثال: 2238
apiResponseStatusCode	کد وضعیت پاسخ مثال: 200
applicationName	نام برنامه ای که برای اشتراک در API استفاده شده است. مثال: DefaultApplication
consumerKey	این به کلید مصرف کننده ای اشاره دارد که هنگام تولید کلید برای محیط های production و sandbox خود دریافت می‌کنید. مثال: AwlPOz2aDf2i1gZFWgITEgf4oPsa
responseTime	زمان رفت و برگشت درخواست مثال: 21

Database Call logs (لاگ‌های فراخوانی‌ پایگاه داده)

ثبت فراخوانیهای پایگاهداده برای مشاهدهپذیری شامل دو نوع فراخوانی DB، یعنی فراخوانیهای LDAP و فراخوانیهای JDBC است. این به ردیابی تاخیرهای ناشی از فراخوانی پایگاهداده در یک نمونه کمک می‌کند.

JDBC call logs (لاگهای فراخوانی JDBC)

قالب

مثال

2021-11-28` `10:10:43,202|a783f7c3-647f-4d10-9b72-106faa01bba8|PassThroughMessageProcessor-1|0|jdbc|1543380043202|executeQuery|SELECT REG_NAME, REG_VALUE FROM REG_PROPERTY P, REG_RESOURCE_PROPERTY RP WHERE P.REG_ID=RP.REG_PROPERTY_ID AND RP.REG_VERSION=? AND P.REG_TENANT_ID=RP.REG_TENANT_ID AND RP.REG_TENANT_ID=?|jdbc:h2:repository/database/WSO2CARBON_DB

فیلد	توضیحات
timestamp	زمانی که لاگ ایجاد می‌شود. مثال: 2021-11-28 10:10:43,202
correlationID	هر لاگ حاوی یک شناسه همبستگی است که منحصر به درخواست HTTP است. یک کلاینت می‌تواند یک شناسه همبستگی منحصر به فرد را در هدر activityID درخواست HTTP ارسال کند. اگر این شناسه همبستگی در درخواست ورودی وجود نداشته باشد، WSO2 API-M یک شناسه همبستگی تصادفی برای درخواست ایجاد می‌کند. مثال: a783f7c3-647f-4d10-9b72-106faa01bba8
threadName	شناسه ریسمان مثال: PassThroughMessageProcessor-1
duration	فاصله زمانی (بر حسب میلی ثانیه) بین دو حالت پیام. مثال: 0
callType	jdbc – این نشان دهنده لاگ‌های سطح JDBC است
startTime	زمان شروع کوئری بر حسب میلی ثانیه. مثال: 1543380043202
methodName	نوع متد statement SQL که فراخوانی شده. مثال: executeQuery
query	SQL query. مثال: SELECT REG_NAME, REG_VALUE FROM REG_PROPERTY P, REG_RESOURCE_PROPERTY RP WHERE P.REG_ID=RP.REG_PROPERTY_ID AND RP.REG_VERSION=? AND P.REG_TENANT_ID=RP.REG_TENANT_ID AND RP.REG_TENANT_ID=?
connectionUrl	URL اتصال پایگاه داده. مثال: jdbc:h2:repository/database/WSO2CARBON_DB

LDAP call logs (لاگ‌های فراخوانی LDAP)

قالب

مثال

uid=admin,ou=Users,dc=WSO2,dc=ORG,(&(objectClass=person)(uid=admin)),javax.naming.directory.SearchControls@548e9a48

فیلد	توضیحات
timestamp	زمانی که لاگ ایجاد می‌شود. مثال: 2021-11-0514:05:18,599
correlationID	هر لاگ حاوی یک شناسه همبستگی است که منحصر به درخواست HTTP است. یک کلاینت می‌تواند یک شناسه همبستگی منحصر به فرد را در هدر activityID درخواست HTTP ارسال کند. اگر این شناسه همبستگی در درخواست ورودی وجود نداشته باشد، WSO2 API-M یک شناسه همبستگی تصادفی برای درخواست ایجاد می‌کند. مثال: a783f7c3-647f-4d10-9b72-106faa01bba8
threadName	شناسه ریسمان مثال: http-nio-9443-exec-8
duration	فاصله زمانی (بر حسب میلی ثانیه) بین دو حالت پیام. مثال: 200
callType	ldap – لاگ‌های سطح LDAP را تعیین می‌کند.
startTime	زمان شروع کوئری بر حسب میلی ثانیه. مثال: 1541406918591
methodName	نوع متد LDAP که فراخوانی شده. مثال: search
providerUrl	URL اتصال LDAP. مثال: ldap://localhost:10389
principal	نام ورود کاربر. مثال: uid=admin,ou=system
argsLength	طول استدلال. مثال: 3
args	آرگومان ها در کوئری LDAP. مثال: uid=admin,ou=Users,dc=WSO2,dc=ORG,(&(objectClass=person)(uid=admin)) ,javax.naming.directory.SearchControls@548e9a48

استفاده از لاگ‌های همبستگی برای ردیابی یک درخواست خاص

دستورالعمل‌های زیر را دنبال کنید تا لاگ‌های همبستگی یک درخواست ارسال شده خاص را بررسی کنید:

مرحله 1 – راه اندازی WSO2 API-M

قابلیت مشاهده با WSO2 API-M را فعال کنید و سرور WSO2 API-M را همانطور که در بالا توضیح داده شد راه اندازی کنید.

مرحله 2 – فراخوانی یک API

برای فراخوانی API از دستور زیر استفاده کنید.

curl -k “Authorization :Bearer <access-token>” -H “activityid:<example-correlation-ID>” –data “<payload>” <api_url>

توجه

اگر curl در دسترس نیست، می‌توانید از هر ابزاری برای فراخوانی API استفاده کنید. اما مطمئن شوید که هدر activityid را اضافه کنید

مرحله 3 – بررسی لاگ‌های Correlation

یک ترمینال را باز کنید و به دایرکتوری <API-M_HOME>/repository/logs بروید که در آن فایلlog ذخیره شده است.

لاگ‌های مرتبط را جدا کنید.
<correlation_ID> را با <example-correlation-ID> داده شده در بالا جایگزین کنید.
cat correlation.log | grep “<correlation_ID>”

خواندن و تجزیه و تحلیل لاگ‌های مربوط به همبستگی

بیایید نمونه زیر را تجزیه و تحلیل کنیم.

14 `2021-11-29 15:19:13,984||pool-10-thread-1|0|jdbc|1543484953984|executeQuery|SELECT REG_PATH, REG_USER_ID, REG_LOGGED_TIME, REG_ACTION, REG_ACTION_DATA FROM REG_LOG WHERE REG_LOGGED_TIME>? AND REG_LOGGED_TIME<? AND REG_TENANT_ID=? ORDER BY REG_LOGGED_TIME DESC|jdbc:h2:repository/database/WSO2CARBON_DB`

15 `2021-11-29 15:19:13,984||pool-10-thread-1|0|jdbc|1543484953984|executeQuery|SELECT UM_ID, UM_DOMAIN_NAME, UM_EMAIL, UM_CREATED_DATE, UM_ACTIVE FROM UM_TENANT ORDER BY UM_ID|jdbc:h2:repository/database/WSO2CARBON_DB`

21 `2021-11-29 15:19:14,868|ff0c8866-d8a8-4189-930d-016b9d92f1e8|PassThroughMessageProcessor-18|1003|HTTP|admin–test:v1|GET|/testing/1/*|testing/1|null|null|null|null|null|71|73|200|DefaultApplication|AwlPOz2aDf2i1gZFWgITEgf4oPsa|1005`

شماره خط	توضیحات
1-2	انتقال وضعیت HTTP هنگام دریافت درخواست
3-13	متدهای فراخوانی شده در کنترل کننده های Gateway در مسیر درخواست
14-15	فراخوانی‌های پایگاه داده بی ربط به تماس API
16	انتقال وضعیت HTTP برای درخواست
17	تاخیر Backend در اینجا لاگ تأخیر بکند، تأخیر 800 میلی‌ثانیه‌ای را که برای این مثال به باطن اضافه شده بود، منعکس می‌کند.
18-20	انتقال وضعیت HTTP برای پاسخ
21	سطح کنترل کننده جهانی Synapse برای لاگ فراخوانی بکند
22-28	متد‌هایی که در کنترل‌کننده‌های Gateway در مسیر پاسخ فراخوانی شده‌اند
29-31	انتقال وضعیت HTTP برای ارسال پاسخ
32	تأخیر رفت و برگشت HTTP

باریک کردن یک bottleneck با استفاده از قابلیت مشاهده

سناریو: درخواستی که به Manager API ارسال می‌شود زمان زیادی برای پاسخ دادن نیاز دارد

این ممکن است به دلایل مختلفی رخ دهد،

به دلیل خطای برنامه نویسی
به دلیل زمانبر بودن تماس با سرویس پشتیبان
به دلیل زمانبر بودن تماس با پایگاه داده/LDAP

برای مشخص کردن تنگنا مراحل زیر را دنبال کنید

با استفاده از دستور زیر می توانید زمان های مصرف شده توسط سطح کد را لیست کنید. این به شما کمک می‌کند تا تاخیرهای سطح متد را مشخص کنید.

این زمان صرف شده توسط هر متد را به ترتیب صعودی نشان می‌دهد. اگر متدی با زمان مصرف بالا شناسایی شد، تماس سرویس و پایگاه داده زمان‌بر را با همان شناسه همبستگی لاگ‌های متد انجام دهید و تماس غیرمعمول زمان‌بر را پیدا کنید.

توجه

اگر متدی با زمان مصرف زیاد قابل شناسایی نباشد، اما باز هم تاخیر بالایی مشاهده شود، دستور زیر را می توان اجرا کرد تا بالاترین زمان ثبت شده را بیابد.

cat correlation.log | cut -d “|” -f4 | sort -n

سپس با جستجوی فایل برای این زمان، ورودی که دارای بیشترین مدت زمان است را می توان یافت.

cat correlation.log | grep “<highest_time>”

نکته

از سوی دیگر، ابزار تجزیه و تحلیل لاگ نیز می‌تواند برای استخراج این اطلاعات استفاده شود.

HTTP Access Logs (لاگ‌های دسترسی HTTP)

لاگ‌های دسترسی HTTP به شما کمک می‌کنند استفاده از برنامه‌تان را با اطلاعاتی مانند افرادی که به آن دسترسی دارند، تعداد بازدیدهایی که دریافت کرده‌اند، خطاها و غیره نظارت کنید. این اطلاعات برای عیب‌یابی خطاها مفید است.

در API Manager، لاگ‌های دسترسی را می‌توان هم برای انتقال سرور و هم برای انتقال PassThrough یا NIO در API Gateway پیکربندی کرد.

پیکربندی لاگ‌های دسترسی برای انتقال HTTP Servlet

در WSO2 API Manager، لاگ‌های دسترسی را می‌توان برای انتقال سرور HTTP که روی پورت های پیش فرض 9443/9763 کار می کند، تولید کرد. لاگ‌های دسترسی انتقال سرویس HTTP برای تجزیه و تحلیل جزئیات دسترسی در سطح عملیاتی/مدیریتی مفید هستند.

در Manager API، لاگ‌های دسترسی برنامه‌ها در فایل <APIM_HOME>repository/logs/http_access_.log ضبط یا نوشته می‌شوند. پیکربندی زیر مقدار جدیدی را فعال می‌کند که به لاگ‌ها اجازه می‌دهد در <APIM_HOME>repository/logs/wso2carbon.log یا هر فایل لاگ دیگری نوشته شده و در کنسول نمایش داده شوند.

فایل /repository/conf/deployment.toml را باز کنید.
پیکربندی زیر را اضافه کنید.

[http_access_log]

useLogger = true

سرور را مجددا راه اندازی کنید.

در زیر نمونه‌ای از ورودی‌های لاگ دسترسی آمده است که به‌طور پیش‌فرض از طریق فایل

<API-M_HOME>/repository/logs/http_access_.log قابل نظارت است.

– 127.0.0.1 – – [12/Dec/2019:16:53:29 +0530] “POST /token HTTP/1.1” – 125 “-” “-“

– 127.0.0.1 – [12/Dec/2019:16:53:29 +0530] “- – ” 200 – “-” “-“

– 127.0.0.1 – – [12/Dec/2019:16:53:29 +0530] “POST /oauth2/token HTTP/1.1” – – “-” “Synapse-PT-HttpComponents-NIO”

– 127.0.0.1 – [12/Dec/2019:16:53:29 +0530] “- – ” 200 – “-” “-“

– 127.0.0.1 – – [12/Dec/2019:16:54:38 +0530] “OPTIONS /pizzashack/1.0.0/menu HTTP/1.1” – – “https://localhost:9443/devportal/apis/462a90a2-9f2b-423f-9f58-28b95c30a184/test” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36”

– 127.0.0.1 – [12/Dec/2019:16:54:38 +0530] “- – ” 200 – “-” “-“

– 127.0.0.1 – – [12/Dec/2019:16:54:38 +0530] “GET /pizzashack/1.0.0/menu HTTP/1.1” – – “https://localhost:9443/devportal/apis/462a90a2-9f2b-423f-9f58-28b95c30a184/test” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36”

– 127.0.0.1 – – [12/Dec/2019:16:54:38 +0530] “GET /am/sample/pizzashack/v1/api/menu HTTP/1.1” – – “https://localhost:9443/devportal/apis/462a90a2-9f2b-423f-9f58-28b95c30a184/test” “Synapse-PT-HttpComponents-NIO“

از آنجایی که زمان اجرای WSO2 API Manager بر اساس Apache Tomcat است، می‌توانید از متغیر Access_Log_Valve در Tomcat همانطور که در زیر توضیح داده شده است برای پیکربندی لاگ‌های دسترسی به انتقال سرور HTTP استفاده کنید.

هشدار

تمامی گزینه های پشتیبانی شده در فایل زیر می باشد. بنابراین، مطمئن شوید که گزینه‌های مورد نیاز را حذف کرده و آن‌ها را در صورت لزوم فعال کنید.

# Default access log pattern

#access_log_pattern=%{X-Forwarded-For}i %h %l %u %t \”%r\” %s %b \”%{Referer}i\” \”%{User-Agent}i\”

# combinded log pattern

#access_log_pattern=%h %l %u %t \”%r\” %s %b \”%{Referer}i\” \”%{User-Agent}i\”

access_log_pattern=time=%t remoteHostname=%h localPort=%p localIP=%A requestMethod=%m requestURL=%U remoteIP=%a requestProtocol=%H HTTPStatusCode=%s queryString=%q

# common log pattern

#access_log_pattern=%h %l %u %t \”%r\” %s %b

# file prefix

access_log_prefix=http_gw

# file suffix

access_log_suffix=.log

# file date format

access_log_file_date_format=yyyy-MM-dd

#access_log_directory=”/logs

بیشتر بخوانید : قابلیت Script Mediator در WSO2 API Manager

Audit Logs (لاگ‌‌های حسابرسی)

هنگام نظارت بر سرورهای تولید، حسابرسی یک نیاز اولیه است. به عنوان مثال، DevOps باید مکانیزم روشنی برای شناسایی افرادی که چه کارهایی انجام داده‌اند، و فیلتر کردن باگ‌های احتمالی سیستم داشته باشند. گزارش‌های حسابرسی یا مسیرهای حسابرسی شامل مجموعه‌ای از ورودی‌های گزارش هستند که توالی اقداماتی را که در یک دوره زمانی رخ داده‌اند، توصیف می‌کنند.

گزارش‌های حسابرسی به شما این امکان را می‌دهند که تمام اقدامات یک کاربر یا تمام اقدامات یا تغییرات وارد شده به یک ماژول خاص در سیستم و غیره را در یک دوره زمانی ردیابی کنید.

به عنوان مثال، تمام اقدامات یک کاربر را از اولین نقطه ورود به سرور ثبت می کند. به طور پیش‌فرض، گزارش‌های حسابرسی که هنگام اجرای WSO2 API-M ایجاد می‌شوند در فایل audit.log ذخیره می‌شوند که در فهرست

<API-M_HOME>/repository/logs قرار دارد.

پیکربندی گزارش های حسابرسی

گزارش‌های حسابرسی به‌طور پیش‌فرض در WSO2 API Manager (WSO2 API-M) از طریق پیکربندی‌های زیر که در فایل <API-M-HOME>/repository/conf/log4j2.properties هستند، فعال می‌شوند.

appender.AUDIT_LOGFILE.type = RollingFile

appender.AUDIT_LOGFILE.name = AUDIT_LOGFILE

appender.AUDIT_LOGFILE.fileName = ${sys:carbon.home}/repository/logs/audit.log

appender.AUDIT_LOGFILE.filePattern = ${sys:carbon.home}/repository/logs/audit-%d{MM-dd-yyyy}.log

appender.AUDIT_LOGFILE.layout.type = PatternLayout

appender.AUDIT_LOGFILE.layout.pattern = TID: [%tenantId] [%d] %5p {%c} – %m%ex%n

appender.AUDIT_LOGFILE.policies.type = Policies

appender.AUDIT_LOGFILE.policies.time.type = TimeBasedTriggeringPolicy

appender.AUDIT_LOGFILE.policies.time.interval = 1

appender.AUDIT_LOGFILE.policies.time.modulate = true

appender.AUDIT_LOGFILE.policies.size.type = SizeBasedTriggeringPolicy

appender.AUDIT_LOGFILE.policies.size.size=10MB

appender.AUDIT_LOGFILE.strategy.type = DefaultRolloverStrategy

appender.AUDIT_LOGFILE.strategy.max = 20

appender.AUDIT_LOGFILE.filter.threshold.type = ThresholdFilter

appender.AUDIT_LOGFILE.filter.threshold.level = INFO

رشد گزارش گزارش‌های حسابرسی را می‌توان با پیکربندی‌های مورد بحث در راهنمای Managing log growth (رشد گزارش مدیریت) مدیریت کرد.

اقدامات گزارش حسابرسی

در WSO2 API-M، گزارش های حسابرسی را می توان برای اقدامات کاربر زیر در پورتال ناشر و توسعه‌دهنده فعال کرد.

Publisher (ناشر)

Action

(عمل)

قالب نمونه

(ورود به ناشر)

[2017-06-07 22:26:22,506] INFO – ‘devona@carbon.super [-1234]’ logged in at [2017-06-07 22:26:22,501+0530]

Create an API

(ایجاد یک API)

[2017-06-07 22:28:06,027] INFO – {“performedBy”:”admin”,”action”:”created”,”typ”:”API”,”info”:”

{\”provider\”:\”admin\”,\”name\”:\”PhoneVerification\”,\

“context\”:\”\\\/phoneverify\\\/1.0.0\”,\”version\”:\”1.0.0\”}”}

Update an API

(ویرایش یک API)

[2017-06-08 10:22:49,657] INFO – {“performedBy”:”admin”,”action”:”updated”,”typ”:”API”,”info”:”

{\”provider\”:\”admin\”,\”name\”:\”PhoneVerification\”,

\”context\”:\”\\\/phoneverify\\\/1.0.0\”,\”version\”:\”1.0.0\”}”}

Delete an API

(حذف یک API)

[2017-06-08 10:15:55,369] INFO – {“performedBy”:”admin”,”action”:”deleted”,”typ”:”API”,”info”:”

{\”provider\”:\”admin\”,\”name\”:\”PhoneVerification\”,\”version\”

:\”1.0.0\”}”}

Developer Portal (پورتال توسعه‌دهنده)

Action

(عمل)

قالب نمونه

(ورود به پورتال توسعه‌دهنده)

[2017-06-07 22:34:54,684] INFO – ‘admin@carbon.super [-1234]’ logged in at [2017-06-07 22:34:54,682+0530]

(ثبت نام در پورتال توسعه‌دهنده)

[2017-06-07 22:55:34,054] INFO – Initiator : admin@carbon.super | Action : Update Roles of User | Target : Kimmmy | Data : { Roles : [] } | Result : Success

Create an application

(ایجاد یک برنامه)

[2017-06-07 22:40:17,625] INFO – {“performedBy”:”admin”,”action”:”created”,”typ”:”Application”,”info”:”

{\”tier\”:\”20PerMin\”,\”name\”:\”TestApp\”,\”callbackURL\”:null}”}

Update an application

(ویرایش یک برنامه)

[2017-06-07 22:44:25,931] INFO – {“performedBy”:”admin”,”action”:”updated”,”typ”:”Application”,”info”:”

{\”tier\”:\”20PerMin\”,\”name\”:\”MobileApp\”,\”callbackURL\”:\”\”,

\”status\”:\”APPROVED\”}”}

Delete an application

(حذف یک برنامه)

[2017-06-07 22:45:59,093] INFO – {“performedBy”:”admin”,”action”:”deleted”,”typ”:”Application”,”info”:”

{\”tier\”:\”20PerMin\”,\”name\”:\”MobileApp\”,\”callbackURL\”:\”\”}”}

Subscribe to an application

(مشترک شدن در یک برنامه)

[2017-06-07 22:36:48,826] INFO – {“performedBy”:”admin”,”action”:”created”,”typ”:”Subscription”,”info”:”

{\”application_name\”:\”DefaultApplication\”,\”tier\”:\”Gold\”,\

“provider\”:\”admin\”,\”api_name\”:\”PhoneVerification\”,

\”application_id\”:1}”}

Unsubscribe from an application

(لغو اشتراک از یک برنامه)

[2017-06-07 22:38:08,277] INFO – {“performedBy”:”admin”,”action”:”deleted”,”typ”:”Subscription”,”info”:”

{\”application_name\”:\”DefaultApplication\”,\”provider\”:\”admin\”,

\”api_name\”:\”PhoneVerification\”,\”application_id\”:1}”}

Traces (ردیابی)

OpenTracing (ردیابی باز)

در معماری توزیع‌شده API Manager، ردیابی یک پیام برای دیباگ یا اشکال‌زدایی و مشاهده مسیر پیام مهم است. این به عنوان ردیابی توزیع شده شناخته می شود. OpenTracing به شما امکان می‌دهد ردیابی توزیع شده را برای WSO2 API Manager فعال کنید. Open tracing روشی را برای توسعه دهندگان ارائه می‌دهد تا رشته را دنبال کنند – برای ردیابی درخواست ها از ابتدا تا انتها در across touchpoints (نقاط تماس) و understand distributed systems (سیستم های توزیع شده) در مقیاس. OpenTracing همچنین به ردیابی پیام و شناسایی تأخیرهای رخ داده در هر فرآیند یا متد کمک می کند. بنابراین، OpenTracing به شما کمک می‌کند تا یک تحلیل مربوط به زمان را انجام دهید.

WSO2 API Manager انواع روش های زیر را برای بازیابی داده های ابزاردار پشتیبانی می کند.

Jaeger
Zipkin
Log

برای اطلاعات بیشتر، OpenTracer Configurationsرا ببینید.

این مطلب چقدر مفید بود ؟

روی یک ستاره کلیک کنید تا به آن امتیاز دهید

میانگین امتیاز / 5. نتایج آرا:

تاکنون رأی ندارید! اولین نفری باشید که به این پست امتیاز می دهد.

Padmin

2024-02-12

مستندات

قابلیت مشاهده‌ پذیری (observability) در WSO2

Logs (لاگ ها یا گزارشات)

Correlation Logs (لاگ‌های مربوط به همبستگی)

Enabling Correlation Logs (فعال کردن لاگهای همبستگی)

External Calls (فراخوانی‌های خارجی)

External call logs with API-M specific information

(لاگ فراخوانی‌های خارجی با اطلاعات خاص API-M)

Database Call logs (لاگ‌های فراخوانی‌ پایگاه داده)

JDBC call logs (لاگهای فراخوانی JDBC)

LDAP call logs (لاگ‌های فراخوانی LDAP)

استفاده از لاگ‌های همبستگی برای ردیابی یک درخواست خاص

مرحله 1 – راه اندازی WSO2 API-M

مرحله 2 – فراخوانی یک API

مرحله 3 – بررسی لاگ‌های Correlation

خواندن و تجزیه و تحلیل لاگ‌های مربوط به همبستگی

باریک کردن یک bottleneck با استفاده از قابلیت مشاهده

HTTP Access Logs (لاگ‌های دسترسی HTTP)

پیکربندی لاگ‌های دسترسی برای انتقال HTTP Servlet

Audit Logs (لاگ‌‌های حسابرسی)

پیکربندی گزارش های حسابرسی

اقدامات گزارش حسابرسی

Publisher (ناشر)

Developer Portal (پورتال توسعه‌دهنده)

Traces (ردیابی)

OpenTracing (ردیابی باز)

مقاله قبلیمدیریت دسترسی وب‌سرویس‌ها در WSO2 API Manager

مقاله بعدیایجاد کار زمانبندی شده در WSO2 (Scheduled Tasks)

مطالب مرتبط:

ایجاد کار زمانبندی شده در WSO2 (Scheduled Tasks)

مدیریت دسترسی وب‌سرویس‌ها در WSO2 API Manager

قابلیت Script Mediator در WSO2 API Manager

بدون دیدگاه

دیدگاهتان را بنویسید لغو پاسخ

قابلیت مشاهده‌ پذیری (observability) در WSO2

Logs (لاگ ها یا گزارشات)

Correlation Logs (لاگ‌های مربوط به همبستگی)

Enabling Correlation Logs (فعال کردن لاگ­های همبستگی)

External Calls (فراخوانی‌های خارجی)

External call logs with API-M specific information

(لاگ فراخوانی‌های خارجی با اطلاعات خاص API-M)

Database Call logs (لاگ‌های فراخوانی‌ پایگاه داده)

JDBC call logs (لاگ­های فراخوانی JDBC)

LDAP call logs (لاگ‌های فراخوانی LDAP)

استفاده از لاگ‌های همبستگی برای ردیابی یک درخواست خاص

مرحله 1 – راه اندازی WSO2 API-M

مرحله 2 – فراخوانی یک API

مرحله 3 – بررسی لاگ‌های Correlation

خواندن و تجزیه و تحلیل لاگ‌های مربوط به همبستگی

باریک کردن یک bottleneck با استفاده از قابلیت مشاهده

HTTP Access Logs (لاگ‌های دسترسی HTTP)

پیکربندی لاگ‌های دسترسی برای انتقال HTTP Servlet

Audit Logs (لاگ‌‌های حسابرسی)

پیکربندی گزارش های حسابرسی

اقدامات گزارش حسابرسی

Publisher (ناشر)

Developer Portal (پورتال توسعه‌دهنده)

Traces (ردیابی)

OpenTracing (ردیابی باز)

مقاله قبلیمدیریت دسترسی وب‌سرویس‌ها در WSO2 API Manager

مقاله بعدیایجاد کار زمانبندی شده در WSO2 (Scheduled Tasks)

مطالب مرتبط:

ایجاد کار زمانبندی شده در WSO2 (Scheduled Tasks)

مدیریت دسترسی وب‌سرویس‌ها در WSO2 API Manager

قابلیت Script Mediator در WSO2 API Manager

بدون دیدگاه

دیدگاهتان را بنویسید لغو پاسخ

Enabling Correlation Logs (فعال کردن لاگهای همبستگی)

JDBC call logs (لاگهای فراخوانی JDBC)