گزارش‌ها ابزار بسیار مهمی برای رصد فعالیت‌های هر اپلیکیشنی هستند و علاوه‌بر ارائه اطلاعات ارزشمند هنگام اشکال‌زدایی، می‌توانند به شما در شناسایی الگوهای غیرعادی کمک کنند. مانند هر برنامه دیگری، NGINX نیز رویدادهایی مانند بازدیدکنندگان سایت، خطاها و موارد دیگر را در فایل‌های گزارش ثبت می‌کند. این مقاله به‌صورت جامع شما را در پیکربندی گزارش‌دهی NGINX راهنمایی می‌کند تا بینش بهتری نسبت به فعالیت‌های آن داشته باشید.
انواع گزارش‌ها: Access Log و Error Log
به‌طور پیش‌فرض NGINX رویدادهای خود را در دو نوع گزارش ثبت می‌کند — گزارش خطا (error log) و گزارش دسترسی (access log). در بیشتر توزیع‌های محبوب لینوکس مانند Ubuntu، CentOS یا Debian، هر دو گزارش دسترسی و خطا را می‌توانید در /var/log/nginx پیدا کنید، با این فرض که قبلاً گزارش‌دهی در فایل پیکربندی اصلی NGINX فعال شده باشد. در ادامه با جزئیات بیشتری درباره هر کدام و نحوه فعال‌سازی آن‌ها آشنا می‌شویم.
گزارش دسترسی (Access Log)
NGINX فعالیت تمام بازدیدکنندگان سایت شما را در گزارش دسترسی ثبت می‌کند. در این گزارش می‌توانید ببینید کدام فایل‌ها فراخوانی شده‌اند، NGINX چگونه به یک درخواست پاسخ داده، کاربر از چه مرورگری استفاده کرده، آدرس IP کلاینت و موارد دیگر. از اطلاعات گزارش دسترسی می‌توان برای تحلیل ترافیک و بررسی استفاده سایت در طول زمان بهره برد. همچنین با پایش مناسب این گزارش‌ها می‌توانید درخواست‌های غیرمعمول یا تلاش برای یافتن آسیب‌پذیری‌ها را شناسایی کنید.
در کل، گزارش دسترسی را می‌توان با دستورالعمل access_log یا در بلاک http یا در بلاک server فعال کرد. آرگومان اول log_file اجباری است و آرگومان دوم log_format اختیاری است. اگر فرمت مشخصی تعیین نکنید، گزارش‌ها در فرمت پیش‌فرض combined نوشته می‌شوند.
به‌طور پیش‌فرض در بخش http فایل پیکربندی اصلی NGINX، گزارش دسترسی فعال است؛ بنابراین گزارش تمام میزبان‌های مجازی (virtual host) در یک فایل ثبت می‌شود. بهتر است گزارش هر میزبان مجازی را در فایل جداگانه ثبت کنید. برای این کار کافی است دستور access_log که در http تعریف شده را در بلاک server بازنویسی کنید تا مسیر فایل گزارش مخصوص آن دامنه تعریف شود.
پس از اعمال تنظیمات جدید، NGINX را ری‌لود کنید تا تغییرات اعمال شوند. برای مشاهده گزارش دسترسی دامنه domain1.com در فایل /var/log/nginx/domain1.access.log می‌توانید از دستور زیر استفاده کنید:
tail -f /var/log/nginx/domain1.access.log
تعریف فرمت سفارشی گزارش دسترسی
فرمت پیش‌فرض لاگ، فرمت combined است. می‌توانید با استفاده از دستور log_format در بلاک http، فرمت دلخواه خود را تعریف کرده و سپس نام فرمت را در دستور access_log مشخص کنید. مثال زیر یک فرمت سفارشی را تعریف می‌کند که میزان فشرده‌سازی gzip پاسخ را نیز ثبت می‌کند و سپس آن را به‌کار می‌گیرد:
http {
log_format custom_combined ‘$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_combined;
}
پس از اعمال این فرمت، NGINX را ری‌لود کنید. اکنون با دنبال کردن فایل گزارش می‌توانید نسبت gzip را در انتهای هر ورودی گزارش ببینید:
tail -f /var/log/nginx/custom_access.log
گزارش خطا (Error Log)
دستور error_log پیکربندی گزارش خطا را به فایل یا stderr یا syslog: مشخص می‌کند و شدت حداقلی رویدادهای خطا که باید ثبت شوند را تعیین می‌کند. سینتکس کلی این دستور به‌صورت زیر است:
error_log <log_file> [<log_level>];
آرگومان اول log_file مسیر فایل گزارش را تعریف می‌کند و آرگومان دوم log_level شدت رویدادهایی را که باید ثبت شوند تعیین می‌کند. اگر سطح لاگ را مشخص نکنید، به‌طور پیش‌فرض تنها رویدادهایی با سطح error ثبت می‌شوند. برای مثال، مثال زیر سطح ثبت خطاها را روی crit قرار می‌دهد. دستور error_log در بلاک http به این معنی است که گزارش خطا برای تمام میزبان‌های مجازی در یک فایل موجود خواهد بود:
http {
error_log /var/log/nginx/error.log crit;
}
می‌توانید گزارش خطا را برای هر میزبان مجازی به‌صورت جداگانه نیز ثبت کنید، با بازنویسی دستور error_log در بلاک server:
server {
server_name domain1.com;
error_log /var/log/nginx/domain1.error.log warn;
…
}
علاوه بر نوشتن در فایل، می‌توانید گزارش خطا را به سرور syslog ارسال کنید. مثال زیر گزارش‌ها را به سرور syslog با آدرس 192.168.10.11 در سطح debug می‌فرستد:
error_log syslog:server=192.168.10.11 debug;
در برخی شرایط ممکن است بخواهید گزارش خطا را غیرفعال کنید؛ برای این کار نام فایل لاگ را به /dev/null تنظیم کنید:
error_log /dev/null;
سطوح لاگ (Log Levels)
NGINX از سطوح مختلفی برای کنترل جزئیات گزارش‌های خطا پشتیبانی می‌کند. ترتیب سطوح به‌گونه‌ای است که سطح debug بیشترین جزئیات را دارد و شامل پیام‌های سایر سطوح نیز می‌شود. به‌عنوان مثال اگر سطح را روی error قرار دهید، رویدادهای crit، alert و emerg نیز ثبت خواهند شد. سطوح معمول عبارت‌اند از:
debug: بیشترین جزئیات، مناسب برای عیب‌یابی
info و notice: پیام‌های اطلاعاتی
warn: هشدارها که عملیات را متوقف نمی‌کنند
error: خطاهای معمول که مانع پردازش می‌شوند
crit, alert, emerg: مسائل بحرانی سطح سیستم
برای افزایش جزئیات لاگ، می‌توانید سطح را به debug تغییر دهید. مثال:
error_log /var/log/nginx/error.log debug;
پس از تغییر، NGINX را ری‌لود کنید:
sudo systemctl reload nginx
در سیستم‌های تولیدی معمولاً سطح را روی warn یا error قرار می‌دهند تا از نویز زائد جلوگیری و مصرف دیسک کاهش یابد. اما در زمان وقوع حادثه یا برای ردیابی باگ‌های پیچیده، می‌توان موقتاً به info یا debug سوئیچ کرد.
قابلیت‌های پیشرفته‌تر شامل لاگینگ شرطی بر اساس متغیرها یا تعیین سطوح مختلف برای میزبان‌های مجازی متفاوت است. برای مثال می‌توانید ترافیک عمومی را با سطح warn لاگ کنید و مسیرهایی حساس یا مشکوک را با info یا debug ثبت کنید.
برای کنترل دقیق‌تر نیز می‌توانید لاگ‌گیری debug را فقط برای اتصال‌های خاص فعال کنید با استفاده از debug_connection در بلاک events:
events {
debug_connection 127.0.0.1;
}
این کار خروجی‌های debug را محدود به کلاینت‌های مورد اعتماد می‌کند و مناسب عیب‌یابی پشت NAT یا reverse proxy است.
تشخیص گلوگاه‌ها و رفتارهای مشکوک از طریق لاگ‌ها
لاگ‌های NGINX برای شناسایی نقاط با تاخیر بالا و رفتارهای مشکوک ضروری‌اند. برای مثال می‌توانید از فرمت‌های سفارشی برای ثبت زمان پاسخ‌دهی استفاده کرده و سپس با فیلتر کردن درخواست‌هایی که زمان زیادی می‌گیرند، نقاط مشکل‌ساز را بیابید. همچنین با تحلیل الگوهای درخواست و کدهای وضعیت مانند 403، 404 یا 500 می‌توان IPهایی که تلاش برای brute-force یا اسکن آسیب‌پذیری انجام می‌دهند را تشخیص داد.
یک رویکرد پایه‌ای شامل موارد زیر است:
تعریف فرمت لاگ سفارشی برای ثبت $request_time و دیگر متغیرهای مرتبط با عملکرد
استفاده از ابزارهای خط فرمان مانند awk، cut یا grep برای مرتب‌سازی و تحلیل درخواست‌های کند
نوشتن اسکریپت‌های ساده برای شناسایی تلاش‌های مکرر ورود ناموفق یا درخواست‌های غیرعادی
مثال فرمت سفارشی برای بهینه‌سازی عملکرد:
http {
log_format perf ‘$remote_addr – $remote_user [$time_local] ‘
‘”$request” $status $body_bytes_sent ‘
‘$request_time $upstream_response_time’;
access_log /var/log/nginx/perf_access.log perf;
}
از این طریق می‌توانید با ابزارهای خط فرمان خروجی‌های کند را فیلتر کنید:
awk ‘$NF > 1 { print $0 }’ /var/log/nginx/perf_access.log
برای ممیزی امنیتی می‌توانید اسکریپت‌هایی بنویسید که موارد زیر را انجام دهند:
شناسایی IPهایی که دفعات زیادی خطای 4xx یا 5xx تولید می‌کنند
کشف درخواست‌هایی به مسیرهای حساس مانند /wp-admin یا /phpmyadmin
تجمیع و ارسال هشدار به تیم امنیتی در صورت افزایش ناگهانی رخدادهای مشکوک
ادغام با ابزارهای مانیتورینگ و مدیریت لاگ
برای دید عمیق‌تر و خودکارسازی مدیریت لاگ‌ها می‌توانید لاگ‌های NGINX را به ابزارهای استاندارد صنعت متصل کنید. برخی گزینه‌ها:
ELK Stack (Elasticsearch, Logstash, Kibana) برای دریافت، ذخیره و مصورسازی لاگ‌ها
Graylog، BetterStack و سایر پلتفرم‌های متمرکز مدیریت لاگ
فرستنده‌های سبک مانند Filebeat، Fluentd یا Vector برای ارسال لاگ‌های دسترسی به مقصدهای امن
روش مرسوم یک pipeline معمولی:
NGINX logs –> Filebeat/Fluentd –> Logstash –> Elasticsearch –> Kibana
این تنظیمات می‌تواند افزایش‌های 5xx، نقشه‌برداری ترافیک جغرافیایی، همبستگی زمان پاسخ با مسیرهای خاص و مصورسازی ترافیک بر اساس کشور یا مرورگر را شناسایی کند.
برای ارسال امن لاگ‌ها از سرورهای ابری به‌صورت راه دور، از خروجی‌های TLS-رمزگذاری‌شده یا APIهای HTTPS استفاده کنید (مثلاً از Fluentd یا Vector برای ارسال به سرویس‌های مدیریت‌شده).
درک متغیرهای لاگ و فرمت ورودی‌ها
شناخت معنی هر متغیر در یک ورودی لاگ به شما در اشکال‌زدایی و تحلیل کمک می‌کند. نمونه یک ورودی access log ممکن است شبیه به این باشد:
127.0.0.1 – – [10/Oct/2023:13:55:36 +0000] “GET /index.html HTTP/1.1” 200 612 “-” “Mozilla/5.0” 0.123
توضیح متغیرها:
$remote_addr: آدرس IP کلاینت
$time_local: زمان محلی درخواست
$request: خط درخواست HTTP
$status: کد وضعیت HTTP
$body_bytes_sent: تعداد بایت‌هایی که ارسال شده
$http_user_agent: رشته user agent
$request_time: زمان پاسخ‌دهی در سمت سرور
این متغیرها را می‌توان در فرمت‌های پیچیده ترکیب کرد، در پارسرهای سفارشی به‌کار برد یا به پلتفرم‌های 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 سفارشی‌سازی شوند.
تغییر فرمت لاگ
برای تغییر فرمت لاگ از log_format در بلاک http استفاده کنید. می‌توانید فرمت سفارشی تعریف کنید و متغیرهایی مانند $remote_addr، $status، $request_time و غیره را درج نمایید. سپس فرمت را به شکل زیر به یک فایل access log نسبت دهید:
access_log /var/log/nginx/custom_access.log custom_format;
فرمت‌های سفارشی به شما اجازه می‌دهند زمینه‌های بیشتری مانند نسبت فشرده‌سازی، زمان upstream یا کوکی‌ها را ثبت کنید. پس از تغییر فرمت فراموش نکنید NGINX را ری‌لود کنید:
sudo systemctl reload nginx
سطوح خطا در NGINX
خطاهای NGINX سطوح مختلفی دارند که کنترل‌کننده شدت گزارش‌دهی هستند:
debug: جزئیات حداکثری، مناسب برای عیب‌یابی
info و notice: پیام‌های اطلاعاتی
warn: هشدارها
error: خطاهای معمول
crit, alert, emerg: مسائل بحرانی
هر سطح شامل پیام‌های سطوح بالاتر نیز هست؛ برای مثال سطح error پیام‌های crit، alert و emerg را نیز ثبت می‌کند. می‌توانید سطح دلخواه را با دستوری مانند زیر تعیین کنید:
error_log /path/to/error.log warn;
مانیتورینگ در زمان واقعی
بله، می‌توانید لاگ‌های NGINX را در زمان واقعی با دستور tail دنبال کنید. برای مثال:
tail -f /var/log/nginx/access.log
ابزارهایی مانند multitail یا less +F امکانات نمایش پیشرفته‌تری ارائه می‌دهند. برای تنظیمات پیچیده‌تر می‌توانید لاگ‌ها را به پلتفرم‌های متمرکز متصل کنید تا داشبوردها، هشدارها و جستجو در میان چند سرور فراهم شود.
خاموش کردن لاگینگ
می‌توانید لاگینگ را در NGINX با استفاده از access_log off; و error_log /dev/null; در یک بلوک خاص غیرفعال کنید. این روش برای فایل‌های ایستا مانند 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 توسعه دهید تا فیلدهای بیشتری ثبت شود.
فعال‌سازی لاگ‌های دیباگ
برای فعال‌کردن لاگ‌های دیباگ سطح error_log را به سطح debug تنظیم کنید:
error_log /var/log/nginx/debug.log debug;
توجه داشته باشید که باید NGINX با گزینه –with-debug کامپایل شده باشد یا از debug_connection برای ماژول‌های خاص استفاده کنید. لاگ‌های debug بسیار حجیم هستند و می‌توانند فضای دیسک را مصرف کنند، پس بهتر است فقط موقتی و برای عیب‌یابی فعال شوند.
ارسال لاگ‌ها به syslog و ابزارهای جمع‌آوری مرکزی
NGINX می‌تواند خطاها را به سرور syslog راه دور ارسال کند با استفاده از پروتکل syslog::
error_log syslog:server=192.168.0.5:514 local0;
اما گزارش دسترسی به‌صورت بومی از طریق syslog پشتیبانی نمی‌شود. برای ارسال access logها از عامل‌هایی مانند Filebeat، Fluentd یا Vector استفاده کنید تا آن‌ها را به ELK، Graylog یا BetterStack بفرستید. این روش برای جمع‌آوری و تحلیل مقیاس‌پذیر بین چند نود مناسب است.
مدیریت اندازه لاگ‌ها با logrotate
NGINX به‌صورت خودکار لاگ‌ها را rotate نمی‌کند؛ از ابزارهایی مانند logrotate در لینوکس استفاده کنید تا از پُر شدن دیسک جلوگیری شود. یک پیکربندی نمونه برای logrotate می‌تواند شبیه به زیر باشد:
/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 با سیگنال مناسب به فایل لاگ جدید سوئیچ می‌کند. می‌توانید ایمیل هشدار در صورت خطا را با افزودن دایرکتیو mail در logrotate فعال کنید یا وضعیت logrotate را برای ممیزی در /var/lib/logrotate/status نگه دارید.
استفاده از ELK و سایر پلتفرم‌ها
ELK Stack (Elasticsearch, Logstash, Kibana) به‌طور گسترده برای دریافت، ذخیره‌سازی و مصورسازی لاگ‌ها استفاده می‌شود. یک pipeline معمولی می‌تواند افزایش‌های 5xx را شناسایی، ترافیک بر اساس موقعیت جغرافیایی را نقشه‌برداری کند، تاخیر را با مسیرها همبسته کند و ترافیک را بر حسب کشور یا مرورگر مصور کند.
این ابزارها امکان استقرار سریع و داشبوردهای مدیریت‌شده را فراهم می‌کنند. همچنین سرویس‌های مدیریت‌شده و ابزارهای سبک مانند Vector یا Fluentd برای ارسال امن لاگ‌ها در فضای ابری مناسب‌اند؛ همیشه از خروجی‌های رمزنگاری‌شده (TLS) یا APIهای HTTPS برای ارسال لاگ‌ها استفاده کنید.
نمونه‌ای از یک ورودی access log و تفسیر آن
127.0.0.1 – – [10/Oct/2023:13:55:36 +0000] “GET /index.html HTTP/1.1” 200 612 “-” “Mozilla/5.0” 0.123
این ورودی نشان می‌دهد یک درخواست GET برای /index.html با کد وضعیت 200 انجام شده، اندازه پاسخ 612 بایت بوده و زمان پردازش 0.123 ثانیه بوده است.
محل ذخیره لاگ‌ها در سیستم‌ها
به‌طور پیش‌فرض 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/ است. این مسیرها قابل تغییر در بلاک‌های پیکربندی هستند.
تغییر فرمت لاگ و استفاده از متغیرها
از log_format در بلاک http برای تعریف فرمت‌های سفارشی استفاده کنید. با ترکیب متغیرهایی مانند $remote_addr، $status، $request_time و غیره می‌توانید زمینه‌های بیشتری برای تحلیل فراهم کنید. پس از تعریف فرمت، آن را به یک فایل لاگ انتساب دهید:
access_log /var/log/nginx/custom_access.log custom_format;
فرمت‌های سفارشی برای ضبط نسبت فشرده‌سازی، زمان upstream یا کوکی‌ها مفیدند. پس از تغییر فراموش نکنید NGINX را ری‌لود کنید:
sudo systemctl reload nginx
خلاصه و توصیه‌ها
لاگ‌های NGINX ابزارهای کلیدی برای شناسایی گلوگاه‌ها و رفتارهای مشکوک هستند. با تعریف فرمت‌های سفارشی، کنترل سطح جزئیات با error_log، فعال‌سازی لاگ‌های debug هنگام نیاز، و ارسال لاگ‌ها به سیستم‌های متمرکز مانند ELK، می‌توانید مانیتورینگ و پاسخ به حوادث را بهبود دهید. همچنین حتماً از logrotate برای مدیریت فضای دیسک استفاده کنید تا از پر شدن ناگهانی دیسک جلوگیری شود.
از همراهی شما با جامعه پارمین کلود متشکریم. امکانات ما برای محاسبه، ذخیره‌سازی، شبکه و پایگاه‌داده‌های مدیریت‌شده را بررسی کنید.
نظرات کاربران