مقدمه
مدیریت لاگها یکی از مهمترین بخشهای نگهداری و مانیتورینگ سرورهای لینوکسی است. لاگها فقط برای بررسی خطاها استفاده نمیشوند؛ بلکه اطلاعات ارزشمندی درباره عملکرد سرویسها، وضعیت امنیتی سیستم، فعالیت کاربران و اتفاقات مختلفی که روی سرور رخ میدهد نیز در اختیار مدیر سیستم قرار میدهند.
بهصورت پیشفرض، هر سرور لاگهای خود را بهصورت محلی ذخیره میکند. این روش برای یک یا دو سرور مناسب است، اما زمانی که تعداد سرورها افزایش پیدا میکند، مدیریت لاگها بهصورت جداگانه کار بسیار دشوار و زمانبری خواهد شد.
راهکار استاندارد برای حل این مشکل، راهاندازی یک سرور متمرکز جمعآوری لاگ (Centralized Logging Server) است؛ بهطوری که تمامی سرورها، لاگهای خود را بهصورت لحظهای (Real-Time) برای آن ارسال کنند.
استفاده از یک سرور متمرکز برای ذخیره و مدیریت لاگها مزایای زیادی دارد، از جمله:
- کاهش فضای ذخیرهسازی موردنیاز روی سرورهای عملیاتی
- امکان نگهداری لاگها برای مدت زمان طولانیتر
- تحلیل و بررسی رخدادها در چندین سرور بهصورت همزمان
- سادهتر شدن عیبیابی سرویسهای توزیعشده
- افزایش امنیت، زیرا مدیر سیستم بدون ورود مستقیم به همه سرورها میتواند لاگها را بررسی کند.
- امکان اتصال ابزارهای مانیتورینگ و تحلیل لاگ مانند Graylog، OpenSearch یا ELK Stack در آینده
در این آموزش یاد میگیرید چگونه با استفاده از systemd-journal-remote که بخشی از مجموعه ابزارهای systemd است، لاگهای چندین سرور را روی یک سرور مرکزی جمعآوری کنید.
همچنین ارتباط بین سرورهای ارسالکننده لاگ و سرور مرکزی با استفاده از TLS رمزنگاری میشود تا علاوه بر حفظ محرمانگی اطلاعات، هویت دو طرف نیز احراز شود و لاگها با امنیت کامل حتی از طریق اینترنت منتقل شوند.
پیشنیازها
برای انجام این آموزش به موارد زیر نیاز دارید:
- دو سرور Ubuntu 24.04 LTS
- یک کاربر دارای دسترسی
sudoروی هر دو سرور - فعال بودن فایروال UFW
- دو دامنه یا زیردامنه که به سرورها اشاره کنند
در این آموزش از نامهای زیر استفاده میکنیم:
| نقش | دامنه |
|---|---|
| سرور ارسالکننده لاگ | client.example.com |
| سرور جمعآوری لاگ | server.example.com |
اگر از پارمین کلود (Parmin Cloud) استفاده میکنید، کافی است این دو رکورد DNS را در پنل DNS دامنه خود ایجاد کنید تا به IP سرورها اشاره کنند.
در ادامه آموزش، در دو ترمینال جداگانه به هر دو سرور متصل شوید تا مراحل پیکربندی را آغاز کنیم.
مرحله اول — نصب systemd-journal-remote
در این مرحله، بسته systemd-journal-remote را روی هر دو سرور نصب میکنیم. این بسته شامل ابزارهای لازم برای ارسال و دریافت لاگها است.
ابتدا مخازن سیستم را بهروزرسانی کنید.
روی هر دو سرور اجرا کنید:
sudo apt update
sudo apt upgrade -yسپس بسته موردنیاز را نصب کنید:
sudo apt install systemd-journal-remote -yپس از نصب، روی سرور مرکزی سرویس دریافت لاگ را فعال کنید:
sudo systemctl enable --now systemd-journal-remote.socket
sudo systemctl enable systemd-journal-remote.serviceدستور اول سرویس Socket را هم فعال میکند و هم بلافاصله اجرا میکند.
سرویس دوم فعلاً اجرا نمیشود، زیرا هنوز گواهی TLS برای آن ایجاد نکردهایم و در مراحل بعدی آن را راهاندازی خواهیم کرد.
اکنون روی سرور Client سرویس ارسال لاگ را فعال کنید:
sudo systemctl enable systemd-journal-upload.serviceدر ادامه باید پورتهای موردنیاز را در فایروال باز کنیم.
روی سرور مرکزی اجرا کنید:
sudo ufw allow 19532/tcp
sudo ufw allow 80/tcp- پورت 19532 برای دریافت لاگها توسط Journald استفاده میشود.
- پورت 80 نیز برای دریافت گواهی TLS توسط Certbot موردنیاز است.
روی سرور Client نیز تنها کافی است پورت 80 را باز کنید:
sudo ufw allow 80/tcpدر پایان این مرحله، زیرساخت اولیه برای ارسال و دریافت لاگها آماده شده است.
در مرحله بعد گواهیهای TLS را با استفاده از Let’s Encrypt ایجاد میکنیم تا ارتباط بین سرورها بهصورت رمزنگاریشده برقرار شود.
مرحله دوم — نصب Certbot و دریافت گواهیهای TLS
برای اینکه ارتباط بین سرور ارسالکننده لاگ و سرور مرکزی کاملاً رمزنگاری شود، باید برای هر دو سرور گواهی TLS دریافت کنیم.
در این آموزش از Let’s Encrypt استفاده میکنیم که یک مرجع صدور گواهی (CA) رایگان و معتبر است. ابزار Certbot نیز فرآیند دریافت و تمدید خودکار این گواهیها را انجام میدهد.
نکته: مراحل این بخش روی هر دو سرور کاملاً یکسان است. تنها کافی است هنگام دریافت گواهی، نام دامنه مربوط به همان سرور را وارد کنید.
نصب Certbot
ابتدا روی هر دو سرور Certbot را نصب کنید:
sudo apt update
sudo apt install certbot -yدر Ubuntu 24.04 دیگر نیازی به فعال کردن مخزن Universe نیست، زیرا Certbot بهصورت مستقیم در مخازن رسمی اوبونتو در دسترس قرار دارد.
دریافت گواهی TLS
روی هر سرور دستور زیر را اجرا کنید.
روی سرور Client:
sudo certbot certonly \
--standalone \
--agree-tos \
--email admin@example.com \
-d client.example.comو روی سرور مرکزی:
sudo certbot certonly \
--standalone \
--agree-tos \
--email admin@example.com \
-d server.example.comدر دستور بالا:
certonlyفقط گواهی را دریافت میکند و هیچ تغییری در وبسرور ایجاد نمیکند.--standaloneاز وبسرور داخلی Certbot برای احراز مالکیت دامنه استفاده میکند.--agree-tosشرایط استفاده Let’s Encrypt را بهصورت خودکار میپذیرد.--emailایمیلی است که اعلانهای مربوط به تمدید گواهی برای آن ارسال میشود.-dنام دامنهای است که گواهی برای آن صادر خواهد شد.
پس از پایان موفقیتآمیز عملیات، فایلهای گواهی در مسیر زیر قرار میگیرند:
/etc/letsencrypt/live/<your-domain>/برای مثال:
/etc/letsencrypt/live/server.example.com/دریافت گواهیهای ریشه (CA)
برای اینکه کلاینت و سرور بتوانند اعتبار گواهی یکدیگر را بررسی کنند، باید گواهیهای ریشه Let’s Encrypt نیز روی هر دو سرور وجود داشته باشد.
ابتدا فایل ترکیبی گواهیها را دریافت کنید:
curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} \
> ~/letsencrypt-combined-certs.pemسپس آن را در کنار فایلهای گواهی قرار دهید:
روی Client:
sudo cp ~/letsencrypt-combined-certs.pem \
/etc/letsencrypt/live/client.example.com/و روی سرور مرکزی:
sudo cp ~/letsencrypt-combined-certs.pem \
/etc/letsencrypt/live/server.example.com/در پایان این مرحله، هر دو سرور دارای موارد زیر هستند:
- کلید خصوصی (Private Key)
- گواهی TLS
- فایل شامل گواهیهای ریشه Let’s Encrypt
در مرحله بعد، سرور مرکزی را طوری پیکربندی میکنیم که با استفاده از این گواهیها، لاگهای ارسالی از کلاینتها را دریافت و ذخیره کند.
مرحله سوم — پیکربندی سرور مرکزی جمعآوری لاگ
در این مرحله، سرور مرکزی را به گونهای پیکربندی میکنیم که بتواند با استفاده از گواهی TLS ایجادشده در مرحله قبل، لاگهای ارسالی از کلاینتها را دریافت و ذخیره کند.
سرویسی که مسئول دریافت لاگها است systemd-journal-remote نام دارد.
ابتدا فایل تنظیمات آن را باز کنید:
sudo nano /etc/systemd/journal-remote.confسپس بخش [Remote] را به شکل زیر ویرایش کنید:
[Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.example.com/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.example.com/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.example.com/letsencrypt-combined-certs.pemدر صورتی که از دامنه دیگری استفاده میکنید، مسیرها را متناسب با دامنه خود تغییر دهید.
بررسی گزینههای مهم
تنظیماتی که در بالا اعمال کردیم هر کدام وظیفه مشخصی دارند:
Seal
Seal=falseاین گزینه مشخص میکند که آیا Journald برای جلوگیری از دستکاری لاگها از امضای رمزنگاریشده استفاده کند یا خیر.
اگر نیاز به بالاترین سطح امنیت و قابلیت اثبات عدم تغییر لاگها دارید، میتوانید مقدار آن را روی true قرار دهید.
برای اکثر سناریوهای عملیاتی مقدار false کاملاً مناسب است.
SplitMode
SplitMode=hostاین گزینه نحوه ذخیره لاگها را مشخص میکند.
با مقدار host، برای هر سرور یک فایل Journal جداگانه ایجاد میشود که مدیریت و بررسی لاگها را بسیار سادهتر میکند.
اگر تمام لاگها را در یک فایل واحد میخواهید، میتوانید مقدار آن را برابر با:
SplitMode=falseقرار دهید.
ServerKeyFile
ServerKeyFile=/etc/letsencrypt/live/server.example.com/privkey.pemمسیر کلید خصوصی سرور است که هنگام برقراری ارتباط TLS استفاده میشود.
ServerCertificateFile
ServerCertificateFile=/etc/letsencrypt/live/server.example.com/fullchain.pemاین فایل شامل گواهی TLS سرور و زنجیره کامل اعتبار (Certificate Chain) است.
TrustedCertificateFile
TrustedCertificateFile=/etc/letsencrypt/live/server.example.com/letsencrypt-combined-certs.pemاین فایل شامل گواهیهای ریشه Let’s Encrypt است که برای اعتبارسنجی گواهی کلاینت استفاده میشود.
تنظیم مجوز دسترسی فایلهای TLS
بهصورت پیشفرض، سرویس systemd-journal-remote اجازه خواندن کلید خصوصی Let’s Encrypt را ندارد.
ابتدا سطح دسترسی پوشههای گواهی را اصلاح کنید:
sudo chmod 755 /etc/letsencrypt/live
sudo chmod 755 /etc/letsencrypt/archiveسپس دسترسی فایل کلید خصوصی را تغییر دهید:
sudo chmod 640 /etc/letsencrypt/live/server.example.com/privkey.pemدر ادامه مالک گروه فایل را نیز تغییر دهید تا سرویس بتواند آن را بخواند:
sudo chgrp systemd-journal-remote \
/etc/letsencrypt/live/server.example.com/privkey.pemراهاندازی سرویس دریافت لاگ
اکنون همه چیز آماده است و میتوانید سرویس دریافت لاگ را اجرا کنید:
sudo systemctl start systemd-journal-remote.serviceبرای اطمینان از اجرای صحیح سرویس نیز وضعیت آن را بررسی کنید:
sudo systemctl status systemd-journal-remote.serviceاگر همه چیز بهدرستی پیکربندی شده باشد، وضعیت سرویس باید Active (running) باشد.
در پایان این مرحله، سرور مرکزی آماده دریافت لاگهای رمزنگاریشده از سایر سرورها است.
در مرحله بعد، سرویس systemd-journal-upload را روی سرور Client پیکربندی میکنیم تا لاگها بهصورت خودکار برای سرور مرکزی ارسال شوند.
مرحله پنجم — بررسی عملکرد سیستم و تست ارسال لاگها
در این مرحله، مطمئن میشویم که سرور Client لاگها را بهدرستی برای سرور مرکزی ارسال میکند و سرور مرکزی نیز آنها را بدون مشکل ذخیره میکند.
بررسی فایلهای لاگ روی سرور مرکزی
تمام لاگهای دریافتی از کلاینتها در مسیر زیر ذخیره میشوند:
/var/log/journal/remote/ابتدا وارد سرور مرکزی شوید و محتویات این پوشه را مشاهده کنید:
sudo ls -lh /var/log/journal/remote/اگر ارتباط بین دو سرور بهدرستی برقرار شده باشد، خروجی مشابه زیر مشاهده خواهید کرد:
total 16M
-rw-r----- 1 systemd-journal-remote systemd-journal-remote 8.0M Jul 1 10:46 remote-CN=client.example.com.journalوجود این فایل نشان میدهد که Journald برای کلاینت یک Journal اختصاصی ایجاد کرده است.
ایجاد یک لاگ آزمایشی
اکنون روی سرور Client یک پیام آزمایشی تولید میکنیم.
برای این کار از ابزار logger استفاده میکنیم:
sudo logger -p syslog.debug "### TEST MESSAGE from client.example.com ###"پارامتر -p سطح اهمیت پیام را مشخص میکند.
در این مثال از سطح debug استفاده شده تا پیام آزمایشی بهراحتی قابل تشخیص باشد.
مشاهده لاگ روی سرور مرکزی
اکنون دوباره به سرور مرکزی برگردید.
از آنجایی که فایلهای Journald بهصورت Binary ذخیره میشوند، امکان مشاهده آنها با دستوراتی مانند cat یا less وجود ندارد.
برای خواندن این فایلها باید از ابزار journalctl استفاده کنید:
sudo journalctl \
--file=/var/log/journal/remote/remote-CN=client.example.com.journalاگر همه مراحل بهدرستی انجام شده باشد، در خروجی پیام زیر را مشاهده خواهید کرد:
Jun 29 13:10:09 client.example.com root[3576]:
### TEST MESSAGE from client.example.com ###این خروجی نشان میدهد که:
- لاگ روی Client ایجاد شده است.
- سرویس systemd-journal-upload آن را ارسال کرده است.
- ارتباط TLS بهدرستی برقرار شده است.
- سرور مرکزی لاگ را دریافت و ذخیره کرده است.
بررسی وضعیت سرویسها
اگر پیام آزمایشی دریافت نشد، ابتدا وضعیت سرویسها را بررسی کنید.
روی Client:
sudo systemctl status systemd-journal-uploadروی سرور مرکزی:
sudo systemctl status systemd-journal-remoteدر هر دو حالت باید وضعیت سرویس به شکل زیر باشد:
Active: active (running)بررسی لاگ خطاها
در صورت وجود مشکل، میتوانید لاگ همان سرویس را نیز مشاهده کنید.
روی Client:
journalctl -u systemd-journal-upload -fروی سرور مرکزی:
journalctl -u systemd-journal-remote -fاین دستورها لاگهای سرویس را بهصورت زنده (Real-Time) نمایش میدهند و معمولاً علت خطا را مشخص میکنند؛ مانند:
- مشکل در اعتبارسنجی گواهی TLS
- اشتباه بودن نام دامنه
- خطای دسترسی به فایلهای Certificate
- عدم دسترسی به پورت 19532
- مشکلات مربوط به فایروال
در پایان این مرحله، سرور مرکزی شما با موفقیت لاگهای سیستم را از کلاینت دریافت و ذخیره میکند و زیرساخت Centralized Logging آماده استفاده در محیط عملیاتی است.
نتیجهگیری
در این آموزش یاد گرفتید چگونه بدون استفاده از ابزارهای جانبی مانند ELK Stack یا Graylog، تنها با امکانات داخلی systemd یک زیرساخت Centralized Logging امن راهاندازی کنید.
در این معماری، تمامی سرورها لاگهای خود را بهصورت لحظهای برای یک سرور مرکزی ارسال میکنند و ارتباط بین کلاینت و سرور نیز با استفاده از TLS رمزنگاری میشود تا محرمانگی و صحت دادهها حفظ شود.
در طول این راهنما موارد زیر را پیادهسازی کردید:
- نصب و راهاندازی
systemd-journal-remote - ارسال لاگها با
systemd-journal-upload - دریافت و ذخیرهسازی لاگها روی سرور مرکزی
- دریافت گواهی SSL رایگان از Let’s Encrypt
- برقراری ارتباط امن بین کلاینت و سرور با TLS
- بررسی صحت ارسال لاگها و عیبیابی سرویسها
مزایای این روش
این راهکار نسبت به بسیاری از سیستمهای لاگ متمرکز، سادهتر و سبکتر است و برای بسیاری از زیرساختها کاملاً کافی خواهد بود.
مهمترین مزایای آن عبارتاند از:
- عدم نیاز به نصب Elasticsearch، Logstash یا سایر سرویسهای سنگین
- مصرف بسیار کم منابع سیستم
- استفاده از قابلیتهای داخلی systemd
- انتقال امن لاگها با TLS
- مدیریت ساده و نگهداری آسان
- مناسب برای سرورهای لینوکسی در مقیاس کوچک و متوسط
پیشنهادهایی برای توسعه این زیرساخت
اگر تعداد سرورهای شما در آینده افزایش پیدا کرد، میتوانید این زیرساخت را نیز توسعه دهید.
برای مثال:
- اتصال Journald به Loki برای ذخیرهسازی بلندمدت
- نمایش لاگها در Grafana
- ارسال هشدار هنگام رخداد خطاهای مهم
- آرشیو خودکار لاگهای قدیمی
- ایجاد چند سرور لاگ برای افزونگی (High Availability)
با پیادهسازی این معماری، تمام لاگهای سرورهای لینوکسی شما در یک نقطه متمرکز جمعآوری میشوند و فرآیند مانیتورینگ، عیبیابی و تحلیل رخدادها بسیار سادهتر و سریعتر خواهد شد.
از همراهی شما با پارمین کلود سپاسگزاریم.
نظرات کاربران