نام (NAME)

pmdaweblog - عامل دامنه معیارهای عملکرد (PMDA) برای لاگ‌های وب‌سرور

خلاصه دستور (SYNOPSIS)

$PCP_PMDAS_DIR/weblog/pmdaweblog [-Cp] [-D debug] [-d domain] [-h helpfile] [-i port] [-l logfile] [-n idlesec] [-S num] [-t delay] [-u socket] [-U username] configfile

توضیحات (DESCRIPTION)

pmdaweblog یک «عامل دامنه معیارهای عملکرد» یا (PMDA(3)) است که لاگ‌های وب‌سرور را برای استخراج معیارهای توصیف‌کنندهٔ فعالیت وب‌سرور پویش می‌کند. سپس این معیارهای عملکرد از طریق زیرساخت Performance Co-Pilot (PCP) در دسترس قرار می‌گیرند.

فایل configfile مشخص می‌کند که کدام وب‌سرورها باید پایش شوند، فایل‌های لاگ دسترسی و لاگ خطای مرتبط با آن‌ها کدامند، و الگویی مبتنی بر عبارت باقاعده (regular expression) برای استخراج اطلاعات دقیق درباره هر دسترسی وب ارائه می‌دهد. این فایل به عنوان بخشی از فرایند نصب و/یا حذف PMDA توسط اسکریپت‌های Install و Remove در دایرکتوری $PCP_PMDAS_DIR/weblog نگهداری می‌شود. برای جزئیات بیشتر، به بخش‌های مربوط به نصب مراجعه کنید.

پس از راه‌اندازی، pmdaweblog مجموعه‌ای از فایل‌های لاگ را پایش کرده و در پاسخ به درخواست اطلاعات، هرگونه اطلاعات جدیدی را که به فایل‌های لاگ اضافه شده باشد، همانند tail(1) پردازش می‌کند. همچنین یک سازوکار «همگام‌سازی» (catch up) دوره‌ای برای پردازش اطلاعات جدید از تمام فایل‌های لاگ و طرحی برای تشخیص چرخش (rotation) فایل‌های لاگ وجود دارد.

مانند تمام PMDAهای دیگر، pmdaweblog توسط pmcd(1) و با استفاده از گزینه‌های خط فرمانی که در $PCP_PMCDCONF_PATH تعیین شده است اجرا می‌شود - اسکریپت Install مقادیر مناسب برای گزینه‌های خط فرمان را از کاربر می‌پرسد و $PCP_PMCDCONF_PATH را به‌روزرسانی می‌کند.

شرح مختصری از گزینه‌های خط فرمان pmdaweblog در ادامه آمده است:

-C: بررسی پیکربندی و خروج.
-d domain: تعیین شمارهٔ domain. بسیار حیاتی است که شمارهٔ domain معیارهای عملکرد تعیین‌شده در اینجا، یکتا و سازگار باشد؛ بدین معنا که domain باید برای هر PMDA روی یک میزبان یکتا و متفاوت باشد، و از همان شمارهٔ domain برای PMDAی pmdaweblog روی تمامی میزبان‌ها استفاده شود.

برای اکثر نصب‌ها، مقدار پیش‌فرض domain که در فایل $PCP_PMDAS_DIR/weblog/domain.h تعریف شده کافی خواهد بود. برای مقادیر جایگزین، $PCP_PMCDCONF_PATH را برای مقادیر domain که در حال حاضر روی این میزبان استفاده می‌شوند بررسی کنید؛ همچنین فایل $PCP_VAR_DIR/pmns/stdpmid حاوی مخزنی از تخصیص‌های «شناخته‌شدهٔ» domain است که احتمالاً باید از آن‌ها اجتناب شود.

-h helpfile: دریافت متن راهنما از helpfile تعیین‌شده به‌جای مکان پیش‌فرض.
-i port: برقراری ارتباط با pmcd(1) روی پورت اینترنتی port مشخص‌شده (که می‌تواند یک شماره یا یک نام باشد).
-l logfile: مکان فایل لاگ. به‌طور پیش‌فرض، هنگام اجرای pmdaweblog یک فایل لاگ به نام weblog.log در دایرکتوری جاری pmcd(1) نوشته می‌شود، یعنی در $PCP_LOG_DIR/pmcd. اگر فایل لاگ نتواند ایجاد شود یا قابل نوشتن نباشد، خروجی به‌جای آن در خطای استاندارد (standard error) نوشته می‌شود.
-n idlesec: اگر یک فایل لاگ وب‌سرور برای مدت idlesec ثانیه تغییر نکرده باشد، فایل بسته شده و دوباره باز می‌شود. این تنها راهی است که pmdaweblog می‌تواند چرخش ناهمگام لاگ‌ها را توسط اسکریپت‌های مدیریتی وب‌سرور تشخیص دهد. دوره زمانی پیش‌فرض ۲۰ ثانیه است. این مقدار را می‌توان به صورت پویا با استفاده از pmstore(1) برای اصلاح مقدار معیار عملکرد web.config.check تغییر داد.
-p: برقراری ارتباط با pmcd(1) از طریق یک لوله (pipe).
-S num: تعیین حداکثر تعداد وب‌سرورها به ازای هر sproc. ممکن است واگذاری مسئولیت پویش فایل‌های لاگ وب‌سرور به چند sproc (از دیدگاه زمان تأخیر و توازن بار) مطلوب، یا (به دلیل محدودیت‌های توصیف‌کنندهٔ فایل) ضروری باشد. pmdaweblog اطمینان حاصل خواهد کرد که هر sproc فایل‌های لاگ حداکثر num وب‌سرور را مدیریت کند. مقدار پیش‌فرض ۸۰ وب‌سرور به ازای هر sproc است.
-t delay: برای جلوگیری از نیاز به پویش حجم عظیمی از اطلاعات از لاگ‌های وب‌سرور در پاسخ به یک درخواست معیارهای عملکرد، تمام فایل‌های لاگ حداقل هر delay ثانیه یک بار بررسی می‌شوند. مقدار پیش‌فرض ۱۵ ثانیه است. این مقدار را می‌توان به صورت پویا با استفاده از pmstore(1) جهت اصلاح مقدار معیار عملکرد web.config.catchup تغییر داد..TP -u socket ارتباط با pmcd(1) از طریق socket دامنه یونیکس داده‌شده.
-U: حساب کاربری که عامل تحت آن اجرا می‌شود. پیش‌فرض در نسخه‌های کنونی PCP حساب بدون امتیاز "pcp" است، اما در نسخه‌های قدیمی‌تر به‌طور پیش‌فرض از حساب کاربری ریشه ("root") استفاده می‌شد.

نصب (INSTALLATION)

چارچوب PCP امکان جمع‌آوری معیارها روی یک میزبان و پایش آن‌ها را از میزبانی دیگر فراهم می‌کند. این میزبان‌ها به ترتیب با نام میزبان‌های collector (جمع‌آوری‌کننده) و monitor (پایشگر) شناخته می‌شوند. یک میزبان می‌تواند هم جمع‌آوری‌کننده و هم پایشگر باشد.

میزبان‌های جمع‌آوری‌کننده نیازمند نصب عامل هستند، در حالی که میزبان‌های پایشگر اصلاً به نصب عامل نیازی ندارند.

برای میزبان‌های جمع‌آوری‌کننده، دستورهای زیر را با کاربر root انجام دهید:

# cd $PCP_PMDAS_DIR/weblog
# ./Install

فرآیند نصب، در مورد نصب پیش‌فرض یا غیرپیش‌فرض از کاربر سوال می‌پرسد. یک نصب پیش‌فرض، پیکربندی‌های شناخته‌شده‌ی سرور را جستجو کرده و PMDA را به‌طور خودکار برای هر فایل گزارش سروری که پیدا شود پیکربندی می‌کند. یک نصب غیرپیش‌فرض، تک‌تک سرورها را پیمایش کرده و از کاربر سایر پیکربندی‌های سرور و آرگومان‌های مربوط به pmdaweblog را درخواست می‌کند. نتیجه نهایی نصب جمع‌آوری‌کننده، ساخت یک فایل پیکربندی است که از طریق آرگومان configfile به pmdaweblog داده می‌شود.

اگر می‌خواهید نصب را به حالت اول برگردانید، دستورهای زیر را با دسترسی root انجام دهید:

# cd $PCP_PMDAS_DIR/weblog
# ./Remove

pmdaweblog توسط pmcd(1) راه‌اندازی می‌شود و هرگز نباید به‌طور مستقیم اجرا گردد. اسکریپت‌های Install و Remove هنگام نصب یا حذف عامل، به pmcd(1) اطلاع‌رسانی می‌کنند.

پیکربندی (CONFIGURATION)

فایل پیکربندی برای PMDA وب‌لاگ یک فایل ASCII است که می‌تواند به‌سادگی ویرایش شود. خطوط خالی و خطوطی که با '#' شروع می‌شوند، نادیده گرفته می‌شوند. تمام خطوط دیگر باید یا یک عبارت باقاعده باشند یا مشخصات سرور.

عبارت‌های باقاعده، که هم در فایل‌های گزارش access و هم error استفاده می‌شوند، باید به این شکل باشند:

regex regexName regexp
یا

regex_posix regexName ordering regexp_posix

شناسه regexName کلمه‌ای است که عبارت باقاعده را به‌طور یکتا مشخص می‌کند. این همان مرجعی است که در مشخصات سرور به کار می‌رود. regexp برای گزارش‌های دسترسی، در قالبی است که برای regcmp(3) توضیح داده شده است. regexp_posix برای گزارش‌های دسترسی، در قالبی است که برای regcomp(3) توضیح داده شده است. آرگومان ordering در ادامه شرح داده شده است. ساختار Posix باید در تمامی پلتفرم‌ها در دسترس باشد.

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

برای نسخه غیر- Posix، آرگومان $0 باید شامل متد باشد: GET، HEAD، POST یا PUT. متد PUT به‌عنوان هم‌معنی POST در نظر گرفته می‌شود و هر چیز دیگری در دسته OTHER طبقه‌بندی می‌گردد.

آرگومان دوم، $1، باید شامل اندازه‌ی درخواست باشد. اندازه‌ی «-» یا « » به‌عنوان ناشناخته در نظر گرفته می‌شود.

آرگومان $3 باید شامل کد وضعیتی باشد که به مرورگر کلاینت بازگردانده شده و آرگومان $4 باید شامل کد وضعیتی باشد که از یک میزبان راه دور به سرور بازگردانده شده است. این دو آرگومان آخر برای سرورهای حافظه پنهان (caching) استفاده می‌شوند و باید به‌صورت یک جفت تعیین شوند (در غیر این صورت $3 نادیده گرفته خواهد شد). برای کسب اطلاعات بیشتر درباره کدهای وضعیت، به وب‌سایت http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html مراجعه کنید.

برخی از مشخصات معتبر عبارت‌های باقاعده غیر- Posix برای پایش گزارش دسترسی عبارتند از:

# pattern for CERN, NCSA, Netscape etc Access Logs
regex CERN ] "([A-Za-z][-A-Za-z]+)$0 .*" [-0-9]+ ([-0-9]+)$1
# pattern for FTP Server access logs (normally in SYSLOG)
regex SYSLOG_FTP ftpd[.*]: ([gp][-A-Za-z]+)$0( )$1

یک نوع خاص از گزارش‌های دسترسی با RegexName معادل SQUID وجود دارد. این قالب ۴ پارامتر را استخراج می‌کند، اما از آنجا که فایل گزارش Squid از کدهای وضعیت متنی استفاده می‌کند، به‌عنوان یک حالت خاص مدیریت می‌شود.

در مثال‌های زیر، NS_PROXY قالب Common Extended Log Format متعلق به Netscape/W3C را تحلیل می‌کند و SQUID فایل گزارش با قالب پیش‌فرض Squid Object Cache را تجزیه می‌کند.

# pattern for Netscape Proxy Server Extended Logs
regex NS_PROXY ] "([A-Za-z][-A-Za-z]+)$0 .*" ([-0-9]+)$2 \
([-0-9]+)$1 ([-0-9]+)$3
# pattern for Squid Cache logs
regex SQUID [0-9]+.[0-9]+[ ]+[0-9]+ [a-zA-Z0-9.]+ \
([_A-Z]+)$3([0-9]+)$2 ([0-9]+)$1 ([A-Z]+)$0

عبارت regexp برای گزارش‌های خطا به هیچ آرگومانی نیاز ندارد و تنها یک تطابق کافی است. برخی از عبارات معتبر عبارت‌اند از:

# pattern for CERN, NCSA, Netscape etc Error Logs
regex CERN_err .
# pattern for FTP Server error logs (normally in SYSLOG)
regex SYSLOG_FTP_err FTP LOGIN FAILED

اگر از عبارات باقاعدهٔ سازگار با POSIX استفاده شود، اطلاعات بیشتری مورد نیاز است زیرا ترتیب پارامترها را نمی‌توان در خودِ عبارت باقاعده مشخص کرد. برای سازگاری رو به عقب، در حالت متداولِ دو پارامتر، ترتیب می‌تواند به صورت method,size یا size,method مشخص شود. در حالت کلی، ترتیب با استفاده از یکی از روش‌های زیر تعیین می‌شود:

n1,n2,n3,n4: که در آن nX رقمی بین ۱ تا ۴ است. هر فیلدِ جداشده با کاما (به ترتیب) نشان‌دهندهٔ شمارهٔ آرگومان برای method,size,client_status,server_status است.
-: برای مواردی مانند گزارش‌های خطا که محتوا در آن‌ها نادیده گرفته می‌شود به کار می‌رود.

همانند قالب غیرِ Posix، شناسهٔ RegexName مربوط به SQUID به عنوان یک حالت خاص برای تطابق با کدهای وضعیت غیرعددی در نظر گرفته می‌شود.

برخی از مشخصات مجاز عبارات باقاعدهٔ Posix برای پایش گزارش دسترسی عبارت‌اند از:

# pattern for CERN, NCSA, Netscape, Apache etc Access Logs
regex_posix CERN method,size ][ \]+"([A-Za-z][-A-Za-z]+) \
[^"]*" [-0-9]+ ([-0-9]+)
# pattern for CERN, NCSA, Netscape, Apache etc Access Logs
regex_posix CERN 1,2 ][ \]+"([A-Za-z][-A-Za-z]+) \
[^"]*" [-0-9]+ ([-0-9]+)
# pattern for FTP Server access logs (normally in SYSLOG)
regex_posix SYSLOG_FTP method,size ftpd[.*]: \
([gp][-A-Za-z]+)( )
# pattern for Netscape Proxy Server Extended Logs
regex_posix NS_PROXY 1,3,2,4 ][ ]+"([A-Za-z][-A-Za-z]+) \
[^"]*" ([-0-9]+) ([-0-9]+) ([-0-9]+)
# pattern for Squid Cache logs
regex_posix SQUID 4,3,2,1 [0-9]+.[0-9]+[ ]+[0-9]+ \
[a-zA-Z0-9.]+ ([_A-Z]+)([0-9]+) ([0-9]+) ([A-Z]+)
# pattern for CERN, NCSA, Netscape etc Error Logs
regex_posix CERN_err - .
# pattern for FTP Server error logs (normally in SYSLOG)
regex_posix SYSLOG_FTP_err - FTP LOGIN FAILED

یک وب‌سرور را می‌توان با استفاده از این نحو تعیین کرد:

server serverName on|off accessRegex accessFile errorRegex errorFile

مقدار serverName باید برای هر سرور یکتا باشد، و نامی است که به نمونه (instance) برای معیارهای عملکردیِ مرتبط اختصاص داده می‌شود. برای بررسی دامنه‌های نمونه در PCP به PMAPI(3) مراجعه کنید. پرچم on یا off مشخص می‌کند که آیا سرور هنگام نصب PMDA باید پایش شود یا خیر. این مقدار را می‌توان به‌طور پویا با استفاده از pmstore(1) برای معیار web.perserver.watched تغییر داد، که برای هر وب‌سرورِ نام‌برده‌شده در configfile یک نمونه دارد.

برای هر وب‌سرور دو فایل پایش می‌شوند: گزارش دسترسی و گزارش خطا. هر فایل به نام یک عبارت باقاعده که قبلاً اعلان شده است و یک نام فایل نیاز دارد. نیازی نیست فایل‌های گزارش مشخص‌شده برای هر سرور هنگام نصب weblog PMDA وجود داشته باشند. مولفهٔ PMDA به بررسی فایل‌های گزارش ناموجود ادامه می‌دهد و در صورت امکان آن‌ها را باز خواهد کرد. برخی از مشخصات مجاز سرور عبارت‌اند از:

# Netscape Server on Port 80 at IP address 127.55.555.555
server 127.55.555.555:80 on CERN /logs/access CERN_err /logs/errors
# FTP Server.
server ftpd on SYSLOG_FTP /var/log/messages SYSLOG_FTP_err /var/log/messages

مشخص کردن عبارات باقاعده با تعداد نادرستی از آرگومان‌ها، هر چیزی غیر از ۲ مورد برای لاگ‌های دسترسی و هیچ مقداری برای لاگ‌های خطا، ممکن است باعث رفتار نادرست PMDA و حتی فروپاشی (crash) آن شود. این امر به دلیل محدودیت‌ها در رابط کاربری regex(3) است.

فایل‌ها (FILES)

$PCP_PMDAS_DIR/weblog: دایرکتوری نصب برای PMDA وب‌لاگ
$PCP_PMDAS_DIR/weblog/Install: اسکریپت نصب برای PMDA وب‌لاگ
$PCP_PMDAS_DIR/weblog/Remove: اسکریپت حذف برای PMDA وب‌لاگ
$PCP_LOG_DIR/pmcd/weblog.log: فایل لاگ پیش‌فرض برای گزارش خطا
$PCP_PMCDCONF_PATH: فایل پیکربندی pmcd که گزینه‌های خط فرمان مورد استفاده هنگام اجرای pmdaweblog را مشخص می‌کند
$PCP_LOG_DIR/NOTICES: لاگ نصب‌ها و حذف‌های PMDA
$PCP_VAR_DIR/config/web/weblog.conf: مکان احتمالی فایل پیکربندی PMDA وب‌لاگ
$PCP_DOC_DIR/pcpweb/index.html: مستندات برخط HTML برای PCPWEB

محیط PCP (PCP ENVIRONMENT)

متغیرهای محیطی با پیشوند PCP_ برای پارامتریک‌سازی نام فایل‌ها و دایرکتوری‌های مورد استفاده توسط PCP به کار می‌روند. در هر نصب، فایل /etc/pcp.conf حاوی مقادیر محلی برای این متغیرها است. متغیر $PCP_CONF ممکن است برای مشخص کردن یک فایل پیکربندی جایگزین استفاده شود، همان‌طور که در pcp.conf(5) شرح داده شده است.

گزینه‌های اشکال‌زدایی (DEBUGGING OPTIONS)

گزینهٔ -D یا --debug خروجی پیام‌های تشخیصی تکمیلی را در stderr فعال می‌کند تا به بررسی و اولویت‌بندی مشکلات کمک کند، اگرچه اطلاعات گاهی مبهم بوده و در وهله اول برای راهنمایی توسعه‌دهندگان در نظر گرفته شده است تا کاربران نهایی. debug فهرستی از گزینه‌های اشکال‌زدایی است که با کاما از هم جدا شده‌اند؛ از pmdbg(1) به همراه گزینهٔ -l برای دریافت فهرستی از گزینه‌های اشکال‌زدایی موجود و مفهوم آن‌ها استفاده کنید.

گزینه‌های اشکال‌زدایی ویژهٔ pmdaweblog به شرح زیر هستند:

گزینه	توضیحات
appl0	مقداردهی اولیه، تجزیهٔ configfile و پردازش فایل لاگ
appl1	عملیات‌های زمان‌سنج، کاوش فایل لاگ
appl2	ارتباط بین‌فرآیندی (IPC) با فرآیندهای کارگر، خطوط لاگ پردازش‌شده
"همچنین ببینید (SEE ALSO)"
pmcd (1)،
pmchart (1)،
pmdawebping (1)،
pminfo (1)،
pmstore (1)،
pmview (1)،
tail (1)،
weblogvis (1)،
webvis (1)،
PMAPI (3)،
PMDA (3)
و
regcmp (3).