لاگ‌های NGINX: بررسی، پیکربندی و بهترین روش‌ها

لاگ‌های دسترسی و لاگ‌های خطا

به‌صورت پیش‌فرض، NGINX رویدادهای خود را در دو نوع لاگ ثبت می‌کند — لاگ خطا (error log) و لاگ دسترسی (access log). در بیشتر توزیع‌های محبوب لینوکس مانند اوبونتو، سنت‌اواس یا دبیان، هر دو فایل لاگ دسترسی و خطا را می‌توانید در /var/log/nginx بیابید، مشروط بر اینکه لاگ دسترسی و لاگ خطا در فایل پیکربندی اصلی NGINX فعال شده باشند. در ادامه جزئیات بیشتری دربارهٔ لاگ دسترسی، لاگ خطا و نحوهٔ فعال‌سازی آن‌ها ارائه می‌دهیم.

لاگ دسترسی NGINX

NGINX فعالیت تمام بازدیدکنندگان سایت شما را در لاگ دسترسی ثبت می‌کند. در این لاگ می‌توانید ببینید چه فایل‌هایی دسترسی یافته‌اند، NGINX چگونه به درخواست پاسخ داده است، کاربر از چه مرورگری استفاده کرده، آدرس IP کلاینت‌ها و اطلاعات دیگر. از اطلاعات لاگ دسترسی می‌توان برای تحلیل ترافیک و مشاهدهٔ الگوهای استفاده در طول زمان بهره برد. همچنین با مانیتورینگ صحیح لاگ دسترسی می‌توانید متوجه درخواست‌های غیرمعمول برای یافتن آسیب‌پذیری‌های اپلیکیشن شوید.

فعال‌سازی access_log

لاگ دسترسی می‌تواند با دستور access_log در بلاک http یا server فعال شود. آرگومان اول log_file اجباری است و آرگومان دوم log_format اختیاری است. اگر فرمت را مشخص نکنید، NGINX از فرمت پیش‌فرض combined استفاده می‌کند.

به‌صورت پیش‌فرض، لاگ دسترسی در context http در فایل پیکربندی اصلی NGINX فعال است؛ بدین معنی که لاگ تمام میزبان‌های مجازی در یک فایل ثبت می‌شود. بهتر است برای هر میزبان مجازی فایل لاگ جداگانه داشته باشید. برای این کار باید دستور access_log تعریف‌شده در http را در context سرور بازنویسی کنید و یک access_log جدید در server تعریف کنید.

پس از اعمال تغییرات، NGINX را reload کنید تا تنظیمات جدید اعمال شوند. برای مشاهدهٔ لاگ دسترسی دامنه domain1.com در فایل /var/log/nginx/domain1.access.log می‌توانید از دستور زیر استفاده کنید:

tail -f /var/log/nginx/domain1.access.log

تعریف فرمت‌های سفارشی

فرمت پیش‌فرض لاگ برای ثبت رویداد در access log، فرمت combined است. می‌توانید این رفتار را با تعریف یک فرمت لاگ سفارشی در http تغییر دهید و سپس نام آن فرمت را در access_log مشخص کنید. مثال زیر فرمت سفارشی را با افزودن مقدار نسبت فشرده‌سازی gzip به فرمت combined تعریف می‌کند و سپس آن را در access_log به‌کار می‌برد:

log_format custom '$remote_addr - $remote_user [$time_local] '
                  '"$request" $status $body_bytes_sent '
                  '"$http_referer" "$http_user_agent" '
                  '$gzip_ratio;';

access_log /var/log/nginx/custom_access.log custom;

پس از اعمال فرمت فوق و ری‌لود NGINX، با tail بر روی لاگ می‌توانید مقدار gzip ratio را در انتهای هر سطر لاگ ببینید.

لاگ خطا (error_log)

دستور error_log برای پیکربندی لاگ خطا، ارسال به فایل یا stderr، یا ارسال به syslog استفاده می‌شود و سطح حداقلی شدّت (severity) رویدادهای لاگ را مشخص می‌کند. سینتکس عمومی:

error_log <log_file> <log_level>;

آرگومان اول path فایل لاگ و آرگومان دوم سطح لاگ است. اگر سطح لاگ را مشخص نکنید، به‌صورت پیش‌فرض تنها رویدادهای با سطح error ثبت می‌شوند. برای مثال، دستور زیر سطح لاگ را crit تنظیم می‌کند. همچنین تعریف error_log در context http به این معنی است که لاگ خطای همهٔ میزبان‌های مجازی در یک فایل واحد ثبت می‌شود.

error_log /var/log/nginx/error.log crit;

همچنین می‌توانید لاگ خطای هر میزبان مجازی را جداگانه با بازنویسی دستور error_log در context سرور ذخیره کنید:

server {
    server_name domain1.com;
    error_log /var/log/nginx/domain1.error.log warn;
    ...
}

علاوه بر ذخیرهٔ لاگ در فایل، می‌توان error_log را برای ارسال لاگ‌ها به یک سرور syslog پیکربندی کرد. مثال زیر لاگ‌ها را به سرور syslog با آدرس 192.168.10.11 در حالت debug ارسال می‌کند:

error_log syslog:server=192.168.10.11 debug;

در برخی شرایط ممکن است بخواهید لاگ خطا را غیرفعال کنید؛ برای این کار نام فایل لاگ را به /dev/null تنظیم کنید:

error_log /dev/null;

سطوح لاگ

انواع سطوح لاگ با اولویت‌های متفاوت وجود دارند. در این سطوح، debug بیشترین جزییات را دارد و شامل سایر سطوح نیز می‌شود. برای مثال، اگر سطح را error تعیین کنید، پیام‌های crit، alert و emergency نیز ثبت خواهند شد. سطوح مرسوم عبارت‌اند از:

• debug
• info
• notice
• warn
• error
• crit
• alert
• emerg

NGINX به شما امکان کنترل تفصیل لاگ خطا از طریق این سطوح را می‌دهد. در هنگام توسعه یا عیب‌یابی، تنظیم سطح به debug خروجی بسیار مفصلی دربارهٔ پردازش درخواست‌ها، پارس پیکربندی و تعامل ماژول‌ها می‌دهد:

error_log /var/log/nginx/error.log debug;

پس از اعمال تغییر، NGINX را reload کنید:

sudo systemctl reload nginx

در سیستم‌های تولیدی معمول است که سطح را روی warn یا error نگه دارند تا از پرشدن لاگ با اطلاعات کم‌ارزش جلوگیری شود. با این حال، در رخدادهای بحرانی یا برای ردیابی باگ‌های پیچیده می‌توان موقتاً به info یا debug سوئیچ کرد.

پیکربندی‌های پیشرفته‌تر می‌توانند شامل لاگ‌گیری شرطی بر اساس متغیرها یا تنظیم سطوح مختلف لاگ برای هر میزبان باشند؛ برای مثال می‌توان ترافیک عمومی را در سطح warn لاگ گرفت و مسیرهای حساس یا مشکوک را در سطح info یا debug ثبت کرد.

برای کنترل دقیق‌تر، می‌توانید لاگ دیباگ را فقط برای اتصالات مشخص با استفاده از debug_connection در بلاک events فعال کنید:

events {
    debug_connection 127.0.0.1;
}

این روش خروجی دیباگ را فقط برای کلاینت‌های مورد اعتماد محدود می‌کند و برای عیب‌یابی پشت NAT یا reverse proxy مفید است.

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

لاگ‌های NGINX برای شناسایی گلوگاه‌ها و رفتارهای مشکوک در سرور حیاتی هستند. برای مثال، با فیلتر کردن لاگ‌های دسترسی بر اساس زمان پاسخ می‌توانید نقاط پایان با تاخیر زیاد را بیابید. همچنین الگوهای درخواست و کدهای وضعیت مانند 403، 404 یا 500 می‌توانند نشانه‌ای از تلاش برای حمله یا اسکن آسیب‌پذیری‌ها باشند.

رویکرد پایه‌ای شامل موارد زیر است:

• تعریف فرمت لاگ اختصاصی برای ثبت request_time، upstream_time و دیگر پارامترهای عملکردی
• استفاده از ابزارهای خط فرمان مانند awk، cut یا grep برای مرتب‌سازی و تحلیل درخواست‌های کند
• اسکریپت‌نویسی برای تحلیل الگوهای مخرب مانند تلاش‌های brute-force یا اسکن مسیر

نمونهٔ فرمت لاگ سفارشی برای بهینه‌سازی عملکرد

log_format perf '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '$request_time $upstream_response_time $gzip_ratio;';

access_log /var/log/nginx/perf_access.log perf;

سپس می‌توانید با ابزارهایی مثل awk یا sort تاخیرهای بالا را شناسایی کنید:

awk '{ print $0 }' /var/log/nginx/perf_access.log | sort -kNF

مدیریت و ارسال لاگ‌ها

برای دید عمیق‌تر و خودکارسازی مدیریت لاگ، می‌توانید لاگ‌های NGINX را با ابزارهای مانیتورینگ استاندارد ادغام کنید.

مدیریت اندازهٔ فایل‌ها با logrotate

از logrotate برای کنترل اندازهٔ فایل‌های لاگ و جلوگیری از مصرف بی‌رویهٔ دیسک استفاده کنید. پیکربندی مناسب logrotate از پرشدن دیسک جلوگیری کرده، دسترسی بلندمدت به لاگ‌ها را تضمین می‌کند و با سیاست‌های حسابرسی سازگار است. یک پیکربندی نمونه برای NGINX به‌شکل زیر است:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 `cat /run/nginx.pid`
    endscript
}

می‌توانید اعلان ایمیلی در صورت مشکل اضافه کنید یا وضعیت logrotate را برای حسابرسی در /var/lib/logrotate/status نگه دارید.

پایپلاین‌های متمرکز لاگ (ELK، Fluentd و غیره)

ELK Stack (Elasticsearch, Logstash, Kibana) به‌طور گسترده برای دریافت، ذخیره و مصورسازی لاگ‌ها استفاده می‌شود. یک پایپلاین معمولی شامل ارسال لاگ‌ها از سرورها به Logstash یا Beats، ذخیره در Elasticsearch و نمایش در Kibana است. این مجموعه می‌تواند جهش‌های 5xx را تشخیص دهد، ترافیک را بر اساس کشور و مرورگر نقشه‌برداری کند و تاخیر را با مسیرها همبسته کند.

برای ارسال ایمن لاگ‌ها به ابر، از خروجی‌های TLS-محور یا APIهای HTTP ایمن استفاده کنید (مثلاً با Fluentd یا Vector).

ارسال لاگ به syslog یا سامانه‌های متمرکز

NGINX می‌تواند لاگ خطا را مستقیم به syslog ارسال کند:

error_log syslog:server=unix:/dev/log debug;

لاگ دسترسی به‌صورت مستقیم از طریق syslog پشتیبانی نمی‌شود و برای این منظور معمولاً از عوامل ارسال لاگ مثل Filebeat، Fluentd یا Vector استفاده می‌شود تا لاگ‌های دسترسی را به سامانه‌های متمرکز بفرستند.

درک ورودی‌های یک خط لاگ

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

127.0.0.1 - - [10/Oct/2021:13:55:36 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0" 0.003 0.002 1.2

توضیح اجزای نمونه:

• 127.0.0.1 — آدرس IP کلاینت ($remote_addr)
• – — نام کاربری احراز هویت‌شده (در صورت وجود) ($remote_user)
• [timestamp] — زمان محلی درخواست ($time_local)
• “GET /index.html HTTP/1.1” — درخواست کامل ($request)
• 200 — وضعیت پاسخ ($status)
• 612 — بایت‌های ارسال‌شده ($body_bytes_sent)
• “-” — Referer ($http_referer)
• “Mozilla/5.0” — User-Agent ($http_user_agent)
• 0.003 — request_time
• 0.002 — upstream_response_time
• 1.2 — gzip_ratio

این متغیرها را می‌توان برای ساخت فرمت‌های پیچیده‌تر، استفاده در پارسرهای سفارشی یا واردسازی در پلتفرم‌های SIEM برای همبستگی امنیتی به‌کار برد.

مسیر پیش‌فرض لاگ‌ها

به‌طور پیش‌فرض، NGINX لاگ‌های خود را در دایرکتوری /var/log/nginx/ در سیستم‌های مبتنی بر لینوکس ذخیره می‌کند. دو فایل اصلی access.log و error.log ورودهای ترافیک ورودی و خطاهای سمت سرور را ثبت می‌کنند. مسیرهای دقیق لاگ را می‌توانید با بررسی دستورات access_log و error_log در پیکربندی NGINX (معمولاً /etc/nginx/nginx.conf یا در زیر /etc/nginx/sites-enabled/) تأیید کنید. در macOS با Homebrew مسیر لاگ ممکن است /usr/local/var/log/nginx/ باشد. این مسیرهای پیش‌فرض را می‌توان در بلاک‌های server یا http تغییر داد.

نحوهٔ تغییر فرمت لاگ

برای تغییر فرمت لاگ در NGINX از دستور log_format در بلاک http استفاده کنید. می‌توانید فرمت سفارشی را با متغیرهایی مانند $remote_addr، $status، $request_time و سایر موارد تعریف کنید و سپس آن را در access_log مشخص نمایید، مثلاً:

log_format custom '$remote_addr - $remote_user [$time_local] '
                  '"$request" $status $request_time';

access_log /var/log/nginx/custom_access.log custom;

فرمت‌های اختصاصی به شما امکان ثبت زمینه‌های اضافی مانند نسبت فشرده‌سازی، زمان upstream یا کوکی‌ها را برای تحلیل عمیق‌تر می‌دهند. پس از تغییر فرمت فراموش نکنید NGINX را reload کنید:

sudo systemctl reload nginx

سطوح لاگ خطا — جمع‌بندی

NGINX از سطوح مختلف برای کنترلی روی تفصیل لاگ پشتیبانی می‌کند:

• debug: بیشترین جزئیات، مناسب برای عیب‌یابی
• info و notice: پیام‌های اطلاعاتی
• warn: هشدارهایی که اجرای سرویس را متوقف نمی‌کنند
• error: خطاهای متداول
• crit، alert، emerg: مسائل بحرانی سطح سیستم

هر سطح شامل پیام‌های سطح بالاتر نیز می‌شود؛ برای مثال error پیام‌های crit، alert و emerg را نیز ثبت خواهد کرد. می‌توانید سطح دلخواه را با مثال زیر تنظیم کنید:

error_log /var/log/nginx/error.log warn;

مانیتورینگ لاگ در زمان واقعی

لاگ‌های NGINX را می‌توان به‌صورت زنده با دستور tail مشاهده کرد. برای مثال:

tail -f /var/log/nginx/access.log

این دستور خطوط جدید را هنگام نوشته‌شدن نمایش می‌دهد. ابزارهایی مانند multitail یا less +F امکانات پیشرفته‌تری ارائه می‌دهند. در تنظیمات پیشرفته‌تر می‌توانید مانیتورینگ لحظه‌ای را با پلتفرم‌های متمرکز لاگ (ELK، Graylog، BetterStack و غیره) یکپارچه کنید تا هشدارها، داشبوردها و جستجوی توزیع‌شده داشته باشید.

غیرفعال‌سازی لاگ

در NGINX می‌توانید لاگ‌ها را غیرفعال کنید با استفاده از access_log off; و error_log /dev/null; در یک location خاص. این کار برای منابع ثابت مانند فایل‌های CSS، JS یا تصاویر که لاگ آن‌ها ارزش کمی دارد مفید است و باعث کاهش مصرف دیسک و پاک‌تر شدن لاگ‌ها می‌شود. نمونه:

location ~* \.(css|js|png|jpg|jpeg|gif|ico)$ {
    access_log off;
    error_log /dev/null;
}

فرمت combined پیش‌فرض

فرمت combined به‌صورت پیش‌فرض برای لاگ دسترسی NGINX استفاده می‌شود و اطلاعاتی همچون IP کلاینت، timestamp، متد HTTP، URI، وضعیت پاسخ و user agent را شامل می‌شود. این فرمت برای تحلیل پایه‌ای و سازگاری با بیشتر پارسرها مناسب است و می‌توان آن را با دستور log_format گسترش داد.

فعال‌سازی لاگ‌های دیباگ

برای فعال‌سازی لاگ دیباگ، سطح log را در error_log به debug تغییر دهید:

error_log /var/log/nginx/error.log debug;

توجه داشته باشید برای دیباگ‌کردن ممکن است نیاز باشد NGINX با گزینه –with-debug کامپایل شده باشد یا از debug_connection برای ماژول‌های خاص استفاده کنید. لاگ دیباگ بسیار پرحجم است و می‌تواند فضای دیسک را سریع مصرف کند؛ بهتر است فقط موقتاً و هنگام عیب‌یابی فعال شود.

ارسال لاگ به syslog و ابزارهای ارسال

NGINX می‌تواند لاگ خطا را به syslog ارسال کند:

error_log syslog:server=192.168.10.11 debug;

اما لاگ دسترسی به‌صورت بومی از syslog پشتیبانی نمی‌کند؛ برای ارسال لاگ دسترسی از عامل‌هایی مانند Filebeat، Fluentd یا Vector استفاده کنید تا ورودی‌ها را به سامانه‌های متمرکز منتقل کنند.

چرخش لاگ‌ها (logrotate)

NGINX به‌تنهایی لاگ‌ها را به‌صورت خودکار نمی‌چرخاند؛ از ابزارهایی مانند logrotate برای مدیریت آن‌ها استفاده کنید. یک پیکربندی نمونه در /etc/logrotate.d/nginx می‌تواند به‌صورت زیر باشد:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 `cat /run/nginx.pid`
    endscript
}

تشخیص حملات و فعالیت‌های مشکوک از طریق لاگ

لاگ‌های NGINX می‌توانند علائمی از حملات brute-force، تلاش برای path traversal و پروب کردن سرور را نشان دهند؛ برای مثال:

• تلاش‌های متعدد لاگین ناموفق از یک آدرس IP
• متدهای HTTP غیرمعمول مانند PUT یا DELETE
• درخواست‌ها به مسیرهایی مثل /wp-admin یا /phpmyadmin در سایت‌هایی که CMS ندارند
• حجم بالای کدهای 404 یا 5xx

با تحلیل لاگ و ابزارهایی مانند GoAccess یا AWStats یا ادغام با پلتفرم‌های امنیتی می‌توانید به‌صورت خودکار الگوهای مشکوک را شناسایی و واکنش نشان دهید. مرور منظم لاگ‌ها برای حفظ امنیت ضروری است. همچنین امن‌سازی NGINX با SSL/TLS گامی کلیدی برای محافظت در برابر حملات معمول است. برای راهنمای گام‌به‌گام تنظیم SSL با Let’s Encrypt می‌توانید به آموزش ما دربارهٔ چگونگی امن‌سازی NGINX با Let’s Encrypt بر روی Ubuntu 20.04 مراجعه کنید.

جمع‌بندی

لاگ‌های دسترسی و خطای NGINX برای مانیتور کردن فعالیت کاربران و تسهیل فرایند دیباگ ضروری هستند. شما می‌توانید فرمت لاگ دسترسی را برای ثبت جزئیات بیشتر سفارشی کنید. فعال‌سازی هر دو نوع لاگ توصیه می‌شود چرا که برای نگهداری و عیب‌یابی سرور مفیدند. اگر در برنامه‌ریزی برای مقیاس‌بندی زیرساخت هستید، راهنمای ما دربارهٔ راه‌اندازی load balancing با NGINX را مطالعه کنید.

متشکریم که با ParminCloud یاد می‌گیرید. محصولات ما را در حوزهٔ  storage، networking و managed databases بررسی کنید.