محصولات آکو
HPE
DELL
Broadcom
خدمات آکو
بلاگ
دانلود
HPE
DELL
Broadcom
Vmware
درباره ما
ارتباط با ما
راهنمای فیلدهای System Journal در Dell PowerStore؛ قسمت بیست‌ونهم و پایانی
فیلدهای System Journal در Dell PowerStore امکان شناسایی منبع پیام، زمان ثبت رخداد، سطح اهمیت و ارتباط پیام با درخواست‌ها یا اشیای سیستم را فراهم می‌کنند. این قسمت پایانی راهنمای Service Scripts، ساختار فیلدهای Default و Custom، شیوه خواندن خروجی و نمونه‌های فیلتر با svc_journalctl را بررسی می‌کند.
این مقاله پس از مبحث پایش ظرفیت و بازیابی Wear Trickle Write منتشر می‌شود و بر پیوست فنی Journal متمرکز است؛ برای استفاده از جدول‌های آن، آشنایی با محتوای قسمت قبلی الزامی نیست. این توضیحات در محدوده خانواده محصولات Dell PowerStore تنظیم شده‌اند.
برای تحلیل لاگ‌های Dell PowerStore، ابتدا فیلدهای زمان، میزبان، پردازش و پیام را از گروه Default بررسی کنید؛ سپس با فیلدهای Custom مانند COMPONENT، MARKER، CONTEXT_ID و OBJECT_ID محدوده جست‌وجو را دقیق‌تر کنید. دستور svc_journalctl امکان فیلترکردن و افزودن فیلدهای خروجی را فراهم می‌کند.
- مسیر مطالعه این راهنما
- ساختار System Journal و دسته‌بندی فیلدها
- اجرای svc_journalctl و بررسی قالب خروجی
- فیلدهای پیش‌فرض System Journal
- فیلدهای اختصاصی Cluster
- تفسیر سطوح Priority و دسته‌های Component
- نمونه‌های فیلترکردن و نمایش فیلدها
- ملاحظات فنی در تحلیل Journal
- مطالب و محصولات مرتبط
- جمع‌بندی فنی و پایان راهنما
- سوالات متداول
مسیر مطالعه این راهنما
این مقاله قسمت 29 و پایانی مجموعه راهنمای Service Scripts در Dell PowerStore است. بخش قبل به وضعیت Capacity Metrics و بازیابی Wear Trickle Write اختصاص داشت؛ این قسمت به‌جای عملیات ظرفیت، مرجع فیلدهای System Journal و استفاده از آن‌ها در تحلیل پیام‌ها را تکمیل می‌کند.
- قسمت پیشین: پایش ظرفیت و مدیریت Wear Trickle Write
- قسمت فعلی: فیلدهای System Journal در Dell PowerStore — قسمت 29 و پایانی (بدون لینک)
- قسمت بعدی: وجود ندارد؛ این قسمت پایان مجموعه است.
ساختار System Journal و دسته‌بندی فیلدها
System Journal مجموعه‌ای از Entryها است که اطلاعات هرکدام در فیلدهایی با معنای مشخص نگهداری می‌شود. داده‌های ثبت‌شده را می‌توان با انتخاب فیلدها یا تطبیق مقدار فیلدها فیلتر کرد. Core Logging Framework از سرویس‌های systemd journal در CoreOS استفاده می‌کند و علاوه بر فیلدهای استاندارد، فیلدهایی برای استفاده در Cluster دارد.
| نوع | نقش در بررسی |
|---|---|
| Default | فیلدهای پایه برای زمان، شناسه Entry، مبدأ، پردازش، systemd، پیام و Syslog. |
| Custom | فیلدهای تکمیلی برای Component، Marker، Context، Audit، عملیات مربوط به Object و وضعیت درخواست‌ها. |
شناسه‌های فنی این فیلدها ثابت هستند؛ هنگام نوشتن شرط یا انتخاب ستون خروجی باید نام انگلیسی فیلد عیناً استفاده شود. ترکیب چند فیلد به خواننده اجازه می‌دهد یک پیام منفرد را در متن عملیاتی گسترده‌تری بررسی کند.
اجرای svc_journalctl و بررسی قالب خروجی
Service Script با نام svc_journalctl برای مشاهده پیام‌های System Journal، فیلترکردن خروجی و نمایش جزئیات بیشتر استفاده می‌شود. در اطلاعات کاربرد آن، حالت Service، دامنه Node و عدم نیاز به root ذکر شده است. این فرمان در دسته عیب‌یابی و بازیابی قرار دارد.
آرگومان‌های کاربردی برای مشاهده و محدودکردن لاگ‌ها
| آرگومان | کاربرد |
|---|---|
-h, --help | نمایش راهنمای دستور |
-r, --reverse | نمایش جدیدترین Entryها در ابتدا |
-b, --boot | محدودکردن پیام‌ها به Boot فعلی یا Boot دارای ID مشخص |
-k, --dmesg | نمایش Kernel Message Log مربوط به Boot فعلی |
-t, --identifier | فیلتر براساس Syslog Identifier |
-p, --priority | فیلتر براساس Priority یا بازه آن |
-g, --grep | فیلتر براساس تطبیق Regular Expression |
--case-sensitive | تعیین حساسیت به حروف با TRUE یا FALSE |
-S, --since | نمایش Entryهایی که قدیمی‌تر از تاریخ مشخص نیستند |
-U, --until | نمایش Entryهایی که جدیدتر از تاریخ مشخص نیستند |
--system / --user | انتخاب System Journal یا User Journal کاربر فعلی |
-D, --directory / --file | مشاهده Journal از Directory یا فایل مشخص |
-f, --follow | نمایش آخرین Entryها همراه با پیام‌های جدید |
--output-fields | انتخاب فیلدهای نمایشی با فهرست جداشده با کاما |
نمایش پیش‌فرض هر Entry و تفسیر مقدارها
در قالب پیش‌فرض، مجموعه‌ای از فیلدها با ترتیب مشخص نمایش داده می‌شود. نمونه زیر علاوه بر متن Message، زمان، نام میزبان، Priority، Marker، Component، Sub-component، نام Thread و Context ID را در یک خروجی متنی نشان می‌دهد.
2019 Mar 11 14:51:45 FNM00175000815-A DEBUG CC CP bedrock.config.ConfigManagerVerticle
vert.x-eventloop-thread-0 no_ctx_id Starting to set injector.| فیلد | مقدار در نمونه |
|---|---|
| __REALTIME_TIMESTAMP | 2019 Mar 11 14:51:45 |
| _HOSTNAME | FNM00175000815-A |
| PRIORITY | DEBUG |
| MARKER | CC |
| COMPONENT | CP |
| SUB_COMPONENT | bedrock.config.ConfigManagerVerticle |
| THREAD_NAME | vert.x-eventloop-thread-0 |
| CONTEXT_ID | no_ctx_id |
| MESSAGE | Starting to set injector. |
این نگاشت نشان می‌دهد بخش‌های خروجی صرفاً متن آزاد نیستند؛ هر مقدار به فیلد مشخصی تعلق دارد. همین ساختار مبنای محدودکردن Entryها بر اساس Component، Marker یا Context ID است.
فیلدهای پیش‌فرض System Journal
فیلدهای Default بخش اصلی اطلاعات موردنیاز برای شناسایی زمان و منبع Entry را تشکیل می‌دهند. گروهی از آن‌ها درباره Process و شناسه کاربر هستند؛ گروه دیگر به Boot، Kernel، systemd و سازگاری با Syslog مربوط می‌شود.
شناسه رخداد، زمان و مبدأ پیام
برای تعیین جایگاه Entry، از __CURSOR و دو فیلد زمانی __MONOTONIC_TIMESTAMP و __REALTIME_TIMESTAMP استفاده می‌شود. فیلدهای _HOSTNAME و _BOOT_ID نیز به‌ترتیب نام Host مبدأ و Boot مرتبط با Message را مشخص می‌کنند. مقدارهای _MACHINE_ID، _PID، _UID و _GID برای تشخیص هویت مبدأ پردازشی قابل استفاده‌اند.
اطلاعات پردازش، سرویس و پیام
فیلدهایی مانند _COMM، _CMDLINE و _EXE مشخصات Process ایجادکننده Entry را ثبت می‌کنند. گروه _SYSTEMD_*، فیلد _TRANSPORT، شناسه‌های _STREAM_ID و _SOURCE_REALTIME_TIMESTAMP، فیلدهای _UDEV_* و اطلاعات Syslog نیز در این دسته قرار می‌گیرند. CODE_FILE، CODE_FUNC و CODE_LINE به محل ایجاد Message در کد مربوط هستند.
| نوع | نام فیلد | شرح کاربرد |
|---|---|---|
| Default | __CURSOR | شناسه یکتایی که موقعیت Entry را در Journal توصیف می‌کند. |
| Default | __MONOTONIC_TIMESTAMP | Monotonic Clock Timestamp که زمان سپری‌شده بین یک Event مشخص و زمان وقوع Entry در Journal را نشان می‌دهد. |
| Default | __REALTIME_TIMESTAMP | Wall Clock Timestamp که نقطه زمانی ثبت Entry در Journal را نشان می‌دهد. |
| Default | _AUDIT_LOGINUID, _AUDIT_SESSION | Session و Login UID مربوط به Processی که Journal Entry از آن ایجاد شده است. |
| Default | _BOOT_ID | Kernel Boot ID مربوط به Bootی که Message در آن ایجاد شده است. |
| Default | _CAP_EFFECTIVE | Effective Capabilityهای Processی که Journal Entry از آن ایجاد شده است. |
| Default | _CMDLINE | Command Line مربوط به Processی که Journal Entry از آن ایجاد شده است. |
| Default | _COMM | نام Processی که Journal Entry از آن ایجاد شده است. |
| Default | _EXE | Executable Path مربوط به Processی که Journal Entry از آن ایجاد شده است. |
| Default | _GID | Group ID مربوط به Processی که Journal Entry از آن ایجاد شده است. |
| Default | _HOSTNAME | نام Host مبدأ. |
| Default | _KERNEL_DEVICE | نام Kernel Device. |
| Default | _KERNEL_SUBSYSTEM | نام Kernel Subsystem. |
| Default | _LINE_BREAK | نشان می‌دهد Log Message در Standard Output/Error Stream با کاراکتر معمول Newline خاتمه نیافته است. |
| Default | _MACHINE_ID | Machine ID مربوط به Hostی که Journal Entry از آن ایجاد شده است. |
| Default | _PID | Process ID مربوط به Processی که Journal Entry از آن ایجاد شده است. |
| Default | _SELINUX_CONTEXT | SELinux Security Context (Label) مربوط به Processی که Journal Entry از آن ایجاد شده است. |
| Default | _SOURCE_REALTIME_TIMESTAMP | قدیمی‌ترین Trusted Timestamp مربوط به Message. |
| Default | _STREAM_ID | شناسه یکتای Stream Connection در زمان ایجاد اولیه آن. |
| Default | _SYSTEMD_CGROUP, _SYSTEMD_INVOCATION_ID, _SYSTEMD_OWNER_UID, _SYSTEMD_SESSION, _SYSTEMD_SLICE, _SYSTEMD_UNIT, _SYSTEMD_USER_UNIT | اطلاعات systemd مربوط به Processی که Journal Entry از آن ایجاد شده است. |
| Default | _TRANSPORT | اطلاعات مربوط به نحوه دریافت Message Entry توسط Journal Service. |
| Default | _UDEV_DEVLINK | شماره Low-level Unix Error که باعث ایجاد این Entry شده است. |
| Default | _UDEV_DEVNODE | Device Node Path این Device در /dev. |
| Default | _UDEV_SYSNAME | نام Kernel Device همان‌گونه که در Device Tree زیر /sys نمایش داده می‌شود. |
| Default | _UID | User ID مربوط به Processی که Journal Entry از آن ایجاد شده است. |
| Default | CODE_FILE | نام Source File حاوی Code ایجادکننده Message. |
| Default | CODE_FUNC | نام Function در Code ایجادکننده Message. |
| Default | CODE_LINE | محل Code در Source File ایجادکننده Message. |
| Default | COREDUMP_UNIT, COREDUMP_USER_UNIT | برای Annotate کردن Messageهای حاوی Coredump از System Unitها و Session Unitها استفاده می‌شود. |
| Default | ERRNO | شماره Low-level Unix-based Error مرتبط با Entry در Journal. |
| Default | MESSAGE | Message String مربوط به Entry در systemd journal. |
| Default | MESSAGE_ID | شناسه یکتای Message. |
| Default | OBJECT_AUDIT_LOGINUID, OBJECT_AUDIT_SESSION, OBJECT_CMDLINE, OBJECT_COMM, OBJECT_EXE, OBJECT_GID, OBJECT_PID, OBJECT_SYSTEMD_CGROUP, OBJECT_SYSTEMD_OWNER_UID, OBJECT_SYSTEMD_SESSION, OBJECT_SYSTEMD_UNIT, OBJECT_SYSTEMD_USER_UNIT, OBJECT_UID | Fieldهای تکمیلی که به‌صورت خودکار توسط systemd journal اضافه می‌شوند. |
| Default | PRIORITY | Journal Message Level. سطوح معتبر: ● CRITICAL—Eventهایی که به توجه فوری نیاز دارند. ● ERROR—Eventهایی که وجود مشکل را نشان می‌دهند، اما به توجه فوری نیاز ندارند. ● WARN—Eventهایی که درباره مشکلات احتمالی Warning می‌دهند یا نشان می‌دهند Component در وضعیت ایده‌آل نیست. ● INFO—Messageهای اطلاعاتی درباره Running Status و تغییرات سیستم. ● DEBUG—Verbose Status مانند Messageهای Progress یا Success. |
| Default | SYSLOG_FACILITY | Syslog Compatibility Field حاوی نام Facility. |
| Default | SYSLOG_IDENTIFIER | Syslog Compatibility Field حاوی Unique Identifier. |
| Default | SYSLOG_PID | Syslog Compatibility Field حاوی Process Identifier. |
برای فیلد _UDEV_DEVLINK شرح «Low-level Unix Error» درج شده است؛ به‌دلیل احتمال ابهام در تطبیق نام و شرح، پیش از استناد اجرایی باید تعریف دقیق آن بررسی شود.
فیلدهای اختصاصی Cluster
فیلدهای Custom برای تحلیل پیام‌ها در سطح Cluster و اجزای داخلی آن تعریف شده‌اند. این گروه شامل دسته‌بندی پیام، شناسه درخواست، اطلاعات Objectها، وضعیت عملیات و اطلاعات حسابرسی است.
شناسایی Component، Marker و Context
COMPONENT منشأ منطقی پیام را مشخص می‌کند و MARKER برای شناسایی سریع Event یا Condition کاربرد دارد. CONTEXT_ID شناسه پیگیری Request و ROOT_COMMAND_ID شناسه Context مربوط به Primary Request را ارائه می‌کنند؛ SUB_COMPONENT نیز مؤلفه جزئی‌تری از همان Message را بیان می‌کند.
فیلدهای Object، Audit و وضعیت درخواست
فیلدهای OBJECT_ID، OBJECT_TYPE، OBJECT_SUB_TYPE، OBJECT_HANDLE، OBJECT_CURRENT_STATE_NAME و OBJECT_OPERATION اطلاعات وابسته به Object را تفکیک می‌کنند. مجموعه AUDIT_* برای اطلاعات تکمیلی Audit Log، فیلد STATUS_CODE برای Status Code پاسخ درخواست و THREAD_NAME برای Thread ثبت‌کننده Message استفاده می‌شوند.
| نوع | نام فیلد | شرح کاربرد |
|---|---|---|
| Custom | AUDIT_TIMESTAMP, AUDIT_USERNAME, AUDIT_IS_SUCCESSFUL, AUDIT_CLIENT_ADDRESS, AUDIT_SERVER_ADDRESS, AUDIT_APPLIANCE_ID, AUDIT_JOB_ID, AUDIT_RESOURCE_TYPE, AUDIT_RESOURCE_ACTION, AUDIT_RESOURCE_ID, AUDIT_RESOURCE_NAME, AUDIT_MESSAGE_CODE, AUDIT_MESSAGE_L10N, AUDIT_REQUEST_BODY | Fieldهای تکمیلی مورد استفاده در Audit Logها. |
| Custom | COMPONENT | Logging Component. مقادیر شامل: ● CP—Componentهایی که مدیریت Cluster را ممکن می‌کنند. ● DP—Backend Data Engine Componentها. ● Platform—Backend Platform یا Base Storage Container (BSC) Componentها. ● Service—Serviceability یا Service Container Componentها. ● Fireman—Backend Serviceهایی که مسئول مدیریت ارتباط بین Internal Componentها هستند. ● PostGres—سرویس‌های PostGres. |
| Custom | CONTEXT_ID | شناسه یکتا برای رهگیری Requestها. |
| Custom | MARKER | رشته یکتایی که برای شناسایی سریع Eventها یا Conditionهای مشخص استفاده می‌شود. مقادیر شامل REST، RemoteSupport، ZMQ، NDU (Non-disruptive Upgrades)، CC (Cluster Creation)، LUN، ConfigurationCapture، Event، RB (Resource Balancer)، Import، PhysicalInventory، IDF (Platform ID Files)، DATAMOBILITY، NETWORK، DataCollection و Host هستند. |
| Custom | OBJECT_CURRENT_STATE_NAME | نام Current State مرتبط با Object. |
| Custom | OBJECT_HANDLE | شناسه یکتایی که برای نمایش Resource مدیریت‌شده درون Cluster استفاده می‌شود. |
| Custom | OBJECT_ID | شناسه یکتای Objectی که می‌خواهید اطلاعات آن را از System Journal بازیابی کنید. |
| Custom | OBJECT_OPERATION | نوع Operation مرتبط با Object. |
| Custom | OBJECT_SUB_TYPE | Sub-type مربوط به Objectی که می‌خواهید اطلاعات آن را از System Journal بازیابی کنید. |
| Custom | OBJECT_TYPE | نوع Objectی که می‌خواهید اطلاعات آن را از System Journal بازیابی کنید. |
| Custom | ROOT_COMMAND_ID | Context ID مربوط به Primary Request. |
| Custom | STATUS_CODE | Status Code که Response مربوط به یک Request مشخص را نمایش می‌دهد. |
| Custom | SUB_COMPONENT | Sub-component مرتبط با Message. |
| Custom | THREAD_NAME | نام Threadی که Message را Log می‌کند. |
تفسیر سطوح Priority و دسته‌های Component
PRIORITY سطح پیام را نشان می‌دهد و با COMPONENT و MARKER می‌توان بین شدت رخداد و موضوع آن تفاوت قائل شد. در تعریف این فیلد، پنج سطح معتبر ذکر شده است.
| سطح PRIORITY | معنا |
|---|---|
| CRITICAL | رخدادی که به توجه فوری نیاز دارد. |
| ERROR | رخدادی که وجود مشکل را نشان می‌دهد، اما در تعریف این سطح نیازمند توجه فوری نیست. |
| WARN | هشدار درباره مشکل احتمالی یا قرارداشتن Component در وضعیت غیرا‌یده‌آل. |
| INFO | اطلاعات وضعیت اجرا و تغییرات سیستم. |
| DEBUG | جزئیات Verbose مانند پیام‌های پیشرفت یا موفقیت. |
Componentهای قابل شناسایی
مقادیر COMPONENT شامل CP برای بخش‌های مدیریت Cluster، DP برای Backend Data Engine، Platform برای Backend Platform یا BSC، Service برای Serviceability یا Service Container، Fireman برای مدیریت ارتباط اجزای داخلی و PostGres برای سرویس‌های PostGres است.
نمونه Markerهای قابل استفاده در Query
در MARKER، برچسب‌هایی از جمله REST، RemoteSupport، ZMQ، NDU، CC، LUN، ConfigurationCapture، Event، RB، Import، PhysicalInventory، IDF، DATAMOBILITY، NETWORK، DataCollection و Host در نظر گرفته شده‌اند. به‌عنوان نمونه، NDU به Non-disruptive Upgrades، CC به Cluster Creation و RB به Resource Balancer اشاره دارد.
نمونه‌های فیلترکردن و نمایش فیلدها
برای محدودکردن خروجی، می‌توان نام فیلد و مقدار آن را در فرمان وارد کرد. سه مثال زیر از قابلیت Field Matching، فیلتر متن و افزودن فیلدها به خروجی استفاده می‌کنند.
فیلتر پیام‌های Platform با Marker و Priority
فرمان زیر Entryهای مرتبط با COMPONENT برابر Platform، MARKER برابر NDU و PRIORITY برابر ERROR را هدف می‌گیرد.
svc_journalctl COMPONENT=Platform MARKER=NDU PRIORITY=ERRORجست‌وجوی Text Pattern با حساسیت به حروف
نمونه زیر فیلتر Context ID و Component را همراه با گزینه Case-sensitive نشان می‌دهد. از آنجا که در فرمت کلی دستور، -g دارای Value معرفی شده است، مقدار موردنیاز این گزینه باید پیش از اجرای نمونه با راهنمای همان نسخه بررسی شود.
svc_journalctl -g --case-sensitive=TRUE CONTEXT_ID=456abc COMPONENT=Platformافزودن CODE_LINE و CODE_FUNC به نمایش خروجی
برای افزودن شماره خط و نام Function به فیلدهای نمایش‌داده‌شده، می‌توان از --output-fields و نام فیلدهای جداشده با کاما استفاده کرد.
svc_journalctl --output-fields=CODE_LINE,CODE_FUNCدر نمونه خروجی این دستور، CODE_LINE برابر [814] و CODE_FUNC برابر [validatePlatformResponseStateTask] است. این دو مقدار در کنار سایر اجزای Entry نمایش داده می‌شوند.
ملاحظات فنی در تحلیل Journal
فیلترکردن System Journal زمانی دقیق‌تر است که ابتدا فیلدهای اصلی یک Entry مشخص شوند و سپس شرط‌ها بر همان نام‌ها و مقدارها اعمال شوند. پیام‌های مربوط به Boot، Process، systemd و Object از فیلدهای متفاوتی استفاده می‌کنند؛ بنابراین انتخاب فیلد باید با موضوع بررسی هماهنگ باشد.
برای تشخیص گزینه‌ها و نحوه استفاده در نسخه نصب‌شده، می‌توان راهنمای svc_journalctl را با گزینه --help مشاهده کرد. در مواردی که نمونه دستور و فرمت کلی هم‌راستا نیستند، از اجرای مبتنی بر حدس خودداری شود.
اطلاعات کاربرد svc_journalctl شامل حالت Service، دامنه Node و عدم نیاز به دسترسی root است. این مقاله فرایند تغییر تنظیمات Journal یا پاک‌کردن لاگ‌ها را شرح نمی‌دهد؛ تمرکز آن بر مشاهده و تفسیر فیلدهاست.
برای بررسی عملیاتی تجهیزات و موضوعات نیازمند پشتیبانی، صفحه خدمات گارانتی و پشتیبانی تجهیزات آکو می‌تواند مسیر مرتبط بعدی باشد.
مطالب و محصولات مرتبط
سه مطلب زیر مسیر مطالعه مرتبط با تحلیل Journal، پایش رخدادها و گردآوری اطلاعات فنی PowerStore را ادامه می‌دهند.
جمع‌بندی فنی و پایان راهنما
ساختار System Journal در Dell PowerStore از فیلدهای پیش‌فرض systemd journal و فیلدهای اختصاصی Cluster تشکیل شده است. فیلدهای زمان و مبدأ، اجزای پردازشی و پیام را مشخص می‌کنند؛ در مقابل، COMPONENT، MARKER، CONTEXT_ID و فیلدهای Object و Audit برای محدودکردن و تفسیر دقیق‌تر رخدادها به کار می‌روند.
با تشخیص مقادیر فیلدها، استفاده هدفمند از svc_journalctl و افزودن CODE_LINE یا CODE_FUNC در صورت نیاز، امکان خواندن ساخت‌یافته پیام‌ها فراهم می‌شود. این بخش، قسمت بیست‌ونهم و پایان مجموعه راهنمای Service Scripts در Dell PowerStore است.
سوالات متداول
تفاوت فیلدهای Default و Custom در System Journal چیست؟
فیلدهای Default اطلاعات استانداردی مانند زمان، پردازش، میزبان و پیام را ارائه می‌کنند. فیلدهای Custom برای Component، Request، Object، Audit و سایر اطلاعات مرتبط با Cluster به کار می‌روند.
برای تشخیص سطح اهمیت یک پیام از کدام فیلد استفاده می‌شود؟
فیلد PRIORITY سطح پیام را با مقدارهایی مانند CRITICAL، ERROR، WARN، INFO و DEBUG مشخص می‌کند.
چطور می‌توان پیام‌های مربوط به یک Component مشخص را جدا کرد؟
در svc_journalctl می‌توان از تطبیق نام فیلد COMPONENT با مقدار آن استفاده کرد؛ برای مثال COMPONENT=Platform.
فیلد CONTEXT_ID در عیب‌یابی چه کاربردی دارد؟
CONTEXT_ID شناسه یکتایی است که برای رهگیری Requestها استفاده می‌شود و به محدودکردن پیام‌ها به Context مشخص کمک می‌کند.
چه تفاوتی میان COMPONENT و SUB_COMPONENT وجود دارد؟
COMPONENT مؤلفه اصلی ثبت پیام را مشخص می‌کند و SUB_COMPONENT به بخش جزئی‌تر مرتبط با همان Message اشاره دارد.
آیا امکان نمایش شماره خط کد و نام تابع در خروجی وجود دارد؟
بله. با استفاده از --output-fields می‌توان فیلدهای CODE_LINE و CODE_FUNC را به خروجی اضافه کرد.
آیا svc_journalctl به دسترسی root نیاز دارد؟
در جدول کاربرد این Service Script، نیاز به دسترسی root برابر «خیر» ثبت شده و حالت اجرای آن Service است.
این مقاله پایان مجموعه Service Scripts است. برای هماهنگی آموزش تیم زیرساخت در زمینه بررسی پیام‌های System Journal و استفاده از ابزارهای مرتبط، امکان استفاده از خدمات آموزش و انتقال دانش آکو وجود دارد.