مقدمه

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

در حالت پیش‌فرض، هر سرور لاگ‌های خود را به‌صورت محلی ذخیره می‌کند. این روش برای یک یا دو سرور مناسب است، اما زمانی که زیرساخت شما شامل چندین سرور، ماشین مجازی یا نود Kubernetes باشد، مدیریت لاگ‌ها به‌شدت دشوار خواهد شد.

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

استفاده از یک سرور متمرکز برای ذخیره لاگ‌ها مزایای متعددی دارد، از جمله:

• کاهش مصرف فضای ذخیره‌سازی روی سرورهای اصلی
• امکان نگهداری لاگ‌ها برای مدت طولانی‌تر
• تحلیل رخدادها و مشکلات با استفاده از لاگ‌های چندین سرور به‌صورت هم‌زمان
• افزایش امنیت، زیرا حتی در صورت از دسترس خارج شدن یک سرور، لاگ‌های آن همچنان روی سرور مرکزی موجود خواهند بود.
• ساده‌تر شدن عیب‌یابی و مانیتورینگ زیرساخت

در این آموزش با استفاده از قابلیت systemd-journal-remote که بخشی از مجموعه ابزارهای systemd است، یک سرور مرکزی برای جمع‌آوری لاگ‌ها راه‌اندازی می‌کنیم.

همچنین برای محافظت از اطلاعات هنگام انتقال، ارتباط بین کلاینت و سرور را با استفاده از TLS رمزنگاری خواهیم کرد تا علاوه بر حفظ محرمانگی اطلاعات، هویت دو طرف نیز احراز شود.

نکته

نسخه اصلی این آموزش برای Debian 10 نوشته شده بود، اما در این مقاله تمامی مراحل برای Debian 13 بازبینی و به‌روزرسانی شده‌اند تا با آخرین نسخه پایدار این توزیع سازگار باشند.

پیش‌نیازها

برای انجام این آموزش به موارد زیر نیاز دارید:

• دو سرور با Debian 13
• یک کاربر دارای دسترسی sudo روی هر دو سرور
• فعال بودن فایروال UFW
• دو دامنه یا زیردامنه که به سرورها اشاره کنند.

در این مقاله از نام‌های زیر استفاده می‌کنیم:

در ادامه نیز فرض می‌کنیم از طریق SSH به هر دو سرور متصل هستید.

گام اول — نصب systemd-journal-remote

در اولین مرحله باید بسته‌ای را نصب کنیم که امکان ارسال و دریافت لاگ‌های Journald را فراهم می‌کند.

ابتدا روی هر دو سرور مخازن سیستم را به‌روزرسانی کنید.

sudo apt update
sudo apt upgrade -y

سپس بسته موردنیاز را نصب کنید.

sudo apt install systemd-journal-remote

این بسته شامل سه سرویس مهم است:

• systemd-journal-upload
• systemd-journal-remote
• systemd-journal-gatewayd

در این آموزش از دو سرویس اول استفاده خواهیم کرد.

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

sudo systemctl enable --now systemd-journal-remote.socket
sudo systemctl enable systemd-journal-remote.service

در این مرحله تنها Socket اجرا می‌شود و خود سرویس پس از تنظیم گواهی TLS راه‌اندازی خواهد شد.

سپس روی کلاینت سرویس ارسال لاگ را فعال کنید.

sudo systemctl enable systemd-journal-upload.service

تنظیم فایروال

سرور مرکزی باید بتواند درخواست‌های کلاینت را دریافت کند.

به همین دلیل پورت 19532 را باز می‌کنیم.

sudo ufw allow 19532/tcp

همچنین برای دریافت گواهی SSL از Let’s Encrypt لازم است پورت 80 نیز باز باشد.

sudo ufw allow 80/tcp

روی سرور کلاینت نیز تنها باز بودن پورت 80 کافی است.

sudo ufw allow 80/tcp

پس از انجام این مرحله، زیرساخت اولیه برای ارسال و دریافت لاگ‌ها آماده شده است.

گام دوم — دریافت گواهی TLS با Certbot (نسخه به‌روز برای Debian 13)

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

در این آموزش از Let’s Encrypt برای دریافت گواهی SSL رایگان استفاده می‌کنیم.

نکته

در Debian 13 همچنان Certbot بهترین و ساده‌ترین گزینه برای دریافت گواهی‌های Let’s Encrypt محسوب می‌شود.

نصب Certbot

روی هر دو سرور دستور زیر را اجرا کنید.

sudo apt update
sudo apt install certbot curl -y

دریافت گواهی

روی هر سرور، متناسب با دامنه همان سرور، دستور زیر را اجرا کنید.

برای مثال روی سرور لاگ:

sudo certbot certonly \
    --standalone \
    --agree-tos \
    --email admin@example.com \
    -d logs.example.com

و روی کلاینت:

sudo certbot certonly \
    --standalone \
    --agree-tos \
    --email admin@example.com \
    -d client.example.com

پارامترهای این دستور به معنی زیر هستند:

• certonly تنها گواهی را دریافت می‌کند و تغییری در تنظیمات وب‌سرور ایجاد نمی‌کند.
• –standalone یک وب‌سرور موقت برای تأیید مالکیت دامنه اجرا می‌کند.
• –agree-tos شرایط استفاده Let’s Encrypt را به‌صورت خودکار می‌پذیرد.
• –email ایمیل مدیر سیستم برای دریافت اعلان‌های تمدید گواهی.
• -d دامنه‌ای که گواهی برای آن صادر می‌شود.

در پایان، فایل‌های گواهی در مسیر زیر قرار خواهند گرفت:

/etc/letsencrypt/live/<hostname>/

برای مثال:

/etc/letsencrypt/live/logs.example.com/

بررسی تمدید خودکار گواهی

نسخه‌های جدید Certbot در Debian 13 به‌صورت پیش‌فرض یک Timer در systemd ایجاد می‌کنند.

برای اطمینان از فعال بودن آن:

systemctl status certbot.timer

اگر خروجی مشابه زیر مشاهده کردید، همه چیز درست است.

Active: active (waiting)

در این صورت گواهی‌ها به‌صورت خودکار قبل از پایان اعتبار تمدید خواهند شد.

دریافت گواهی‌های CA

برای اینکه کلاینت و سرور بتوانند گواهی یکدیگر را اعتبارسنجی کنند، باید گواهی‌های مرجع (CA Certificates) را نیز در اختیار Journald قرار دهیم.

ابتدا فایل ترکیبی را دانلود کنید.

curl -s \
https://letsencrypt.org/certs/isrgrootx1.pem \
-o isrgrootx1.pem

سپس گواهی میانی را نیز دریافت کنید.

curl -s \
https://letsencrypt.org/certs/lets-encrypt-r3.pem \
-o lets-encrypt-r3.pem

اکنون این دو فایل را با هم ترکیب کنید.

cat isrgrootx1.pem lets-encrypt-r3.pem \
> letsencrypt-combined-certs.pem

در نهایت فایل ساخته‌شده را به پوشه گواهی‌ها منتقل کنید.

sudo cp letsencrypt-combined-certs.pem \
/etc/letsencrypt/live/logs.example.com/

روی کلاینت نیز همین کار را انجام دهید و فقط نام دامنه را تغییر دهید.

گام سوم — پیکربندی سرور مرکزی برای دریافت لاگ‌ها

در این مرحله سرور مرکزی را به گونه‌ای پیکربندی می‌کنیم که بتواند لاگ‌های ارسالی از کلاینت‌ها را از طریق TLS دریافت و ذخیره کند.

سرویسی که این وظیفه را برعهده دارد systemd-journal-remote است.

ابتدا فایل تنظیمات آن را باز کنید.

sudo nano /etc/systemd/journal-remote.conf

در بخش [Remote] تنظیمات را به شکل زیر تغییر دهید.

[Remote]
Seal=false
SplitMode=host

ServerKeyFile=/etc/letsencrypt/live/logs.example.com/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/logs.example.com/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/logs.example.com/letsencrypt-combined-certs.pem

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

بررسی گزینه‌های مهم

SplitMode

این گزینه مشخص می‌کند لاگ‌های دریافتی چگونه ذخیره شوند.

SplitMode=host

در این حالت برای هر کلاینت یک فایل Journal مجزا ایجاد می‌شود که بهترین گزینه برای بیشتر زیرساخت‌ها است.

اگر بخواهید تمام لاگ‌ها داخل یک فایل ذخیره شوند می‌توانید از مقدار زیر استفاده کنید.

SplitMode=none

اما این حالت برای محیط‌های عملیاتی پیشنهاد نمی‌شود.

Seal

Seal=false

اگر این گزینه روی true قرار گیرد، Journal برای جلوگیری از دستکاری لاگ‌ها از قابلیت Forward Secure Sealing استفاده می‌کند.

این ویژگی امنیت بیشتری فراهم می‌کند اما مصرف CPU و فضای ذخیره‌سازی را افزایش می‌دهد.

برای اکثر سرورها مقدار false کاملاً مناسب است.

تنظیم مجوز فایل‌های TLS

به‌صورت پیش‌فرض سرویس Journald اجازه خواندن کلید خصوصی را ندارد.

ابتدا مجوز پوشه‌ها را اصلاح کنید.

sudo chmod 755 /etc/letsencrypt/live
sudo chmod 755 /etc/letsencrypt/archive

سپس مجوز فایل کلید خصوصی را تغییر دهید.

sudo chmod 640 \
/etc/letsencrypt/live/logs.example.com/privkey.pem

اکنون مالک گروه فایل را تغییر دهید.

sudo chgrp systemd-journal-remote \
/etc/letsencrypt/live/logs.example.com/privkey.pem

بررسی فایل گواهی

اطمینان حاصل کنید فایل‌های زیر وجود داشته باشند.

privkey.pem
fullchain.pem
letsencrypt-combined-certs.pem

برای مشاهده آن‌ها:

ls -lh /etc/letsencrypt/live/logs.example.com/

راه‌اندازی سرویس

اکنون سرویس را اجرا کنید.

sudo systemctl start systemd-journal-remote.service

فعال بودن سرویس را بررسی کنید.

sudo systemctl status systemd-journal-remote

اگر همه چیز درست باشد، خروجی مشابه زیر مشاهده خواهید کرد.

Active: active (running)

بررسی پورت سرویس

اطمینان حاصل کنید سرویس روی پورت 19532 در حال گوش دادن باشد.

sudo ss -lntp | grep 19532

خروجی باید چیزی مشابه زیر باشد.

LISTEN 0 128 *:19532

گام چهارم — پیکربندی کلاینت برای ارسال لاگ‌ها

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

سرویسی که این وظیفه را برعهده دارد systemd-journal-upload است.

ایجاد کاربر اختصاصی سرویس

در نسخه‌های جدید systemd این مرحله در بسیاری از سیستم‌ها به‌صورت خودکار انجام می‌شود، اما اگر سرویس با خطای دسترسی به فایل‌های TLS مواجه شد، بهتر است یک کاربر سیستمی برای آن ایجاد کنید.

sudo adduser \
  --system \
  --home /run/systemd \
  --no-create-home \
  --disabled-login \
  --group \
  systemd-journal-upload

این دستور یک کاربر سیستمی ایجاد می‌کند که فقط برای اجرای سرویس استفاده می‌شود و امکان ورود به سیستم را ندارد.

تنظیم مجوز فایل‌های گواهی

برای اینکه سرویس بتواند کلید خصوصی را بخواند، مجوزها را اصلاح کنید.

sudo chmod 755 /etc/letsencrypt/live
sudo chmod 755 /etc/letsencrypt/archive

سپس:

sudo chmod 640 \
/etc/letsencrypt/live/client.example.com/privkey.pem

و در ادامه مالک گروه فایل را تغییر دهید.

sudo chgrp systemd-journal-upload \
/etc/letsencrypt/live/client.example.com/privkey.pem

ویرایش فایل تنظیمات

اکنون فایل تنظیمات سرویس را باز کنید.

sudo nano /etc/systemd/journal-upload.conf

محتوای فایل را مشابه نمونه زیر تنظیم کنید.

[Upload]

URL=https://logs.example.com:19532

ServerKeyFile=/etc/letsencrypt/live/client.example.com/privkey.pem

ServerCertificateFile=/etc/letsencrypt/live/client.example.com/fullchain.pem

TrustedCertificateFile=/etc/letsencrypt/live/client.example.com/letsencrypt-combined-certs.pem

بررسی گزینه‌ها

URL

URL=https://logs.example.com:19532

آدرس سرور مرکزی که لاگ‌ها به آن ارسال می‌شوند.

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

ServerKeyFile

کلید خصوصی کلاینت.

ServerKeyFile=/etc/letsencrypt/live/client.example.com/privkey.pem

ServerCertificateFile

گواهی TLS کلاینت.

ServerCertificateFile=/etc/letsencrypt/live/client.example.com/fullchain.pem

TrustedCertificateFile

فایل شامل گواهی‌های مرجع (CA) که برای اعتبارسنجی گواهی سرور استفاده می‌شود.

TrustedCertificateFile=/etc/letsencrypt/live/client.example.com/letsencrypt-combined-certs.pem

راه‌اندازی مجدد سرویس

پس از ذخیره فایل، سرویس را ریستارت کنید.

sudo systemctl restart systemd-journal-upload

سپس وضعیت سرویس را بررسی کنید.

sudo systemctl status systemd-journal-upload

اگر همه چیز درست باشد، خروجی مشابه زیر مشاهده خواهید کرد.

Active: active (running)

بررسی لاگ سرویس

اگر سرویس اجرا نشد، ابتدا لاگ آن را بررسی کنید.

journalctl -u systemd-journal-upload -f

رایج‌ترین خطاها عبارت‌اند از:

• اشتباه بودن آدرس سرور
• باز نبودن پورت 19532
• تنظیم نبودن DNS
• مجوز نداشتن فایل privkey.pem
• اشتباه بودن مسیر فایل‌های گواهی

بررسی اتصال TLS

قبل از تست ارسال لاگ‌ها، بهتر است از برقراری ارتباط TLS مطمئن شوید.

روی کلاینت دستور زیر را اجرا کنید.

openssl s_client \
-connect logs.example.com:19532

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

Verify return code: 0 (ok)

این پیام نشان می‌دهد که:

• گواهی سرور معتبر است.
• ارتباط TLS بدون مشکل برقرار شده است.
• کلاینت آماده ارسال لاگ‌ها به سرور مرکزی است.

گام پنجم — بررسی عملکرد سرور و ارسال اولین لاگ

اکنون زمان آن رسیده است که مطمئن شویم ارتباط بین کلاینت و سرور به‌درستی برقرار شده و لاگ‌ها روی سرور مرکزی ذخیره می‌شوند.

بررسی فایل‌های Journal روی سرور

تمام لاگ‌هایی که از کلاینت‌ها دریافت می‌شوند در مسیر زیر ذخیره خواهند شد.

/var/log/journal/remote/

برای مشاهده فایل‌ها دستور زیر را اجرا کنید.

sudo ls -lh /var/log/journal/remote/

در صورت صحیح بودن تنظیمات، خروجی مشابه زیر خواهید دید.

total 24M

remote-CN=client.example.com.journal

اگر چندین کلاینت داشته باشید، برای هر کدام یک فایل Journal جداگانه ایجاد خواهد شد.

مثلاً:

remote-CN=client01.example.com.journal

remote-CN=client02.example.com.journal

remote-CN=client03.example.com.journal

این همان مزیتی است که قبلاً با گزینه SplitMode=host فعال کردیم.

ایجاد یک لاگ آزمایشی

اکنون روی کلاینت یک پیام دلخواه داخل Journal ثبت می‌کنیم.

sudo logger \
-p user.notice \
"### TEST MESSAGE FROM CLIENT ###"

همچنین می‌توانید سطح اهمیت (Severity) را تغییر دهید.

برای مثال:

sudo logger -p user.info "Info Message"

یا

sudo logger -p user.warning "Warning Message"

و حتی

sudo logger -p user.err "Error Message"

مشاهده لاگ روی سرور

اکنون روی سرور مرکزی فایل Journal مربوط به همان کلاینت را مشاهده کنید.

sudo journalctl \
--file=/var/log/journal/remote/remote-CN=client.example.com.journal

در خروجی باید پیام تست را مشاهده کنید.

Jun 18 10:15:02 client logger:

### TEST MESSAGE FROM CLIENT ###

این نشان می‌دهد که ارسال لاگ با موفقیت انجام شده است.

مشاهده لاگ‌های جدید به‌صورت لحظه‌ای

برای مشاهده لاگ‌های ورودی به‌صورت Real-Time دستور زیر بسیار کاربردی است.

sudo journalctl \
--file=/var/log/journal/remote/remote-CN=client.example.com.journal \
-f

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

فیلتر کردن لاگ‌ها

یکی از مزایای Journald امکان جستجوی بسیار سریع لاگ‌ها است.

به‌عنوان مثال فقط لاگ‌های مربوط به سرویس SSH را نمایش دهید.

sudo journalctl \
--file=/var/log/journal/remote/remote-CN=client.example.com.journal \
-u ssh

یا فقط لاگ‌های کرنل را مشاهده کنید.

sudo journalctl \
--file=/var/log/journal/remote/remote-CN=client.example.com.journal \
-k

همچنین می‌توانید تنها لاگ‌های یک بازه زمانی خاص را بررسی کنید.

sudo journalctl \
--file=/var/log/journal/remote/remote-CN=client.example.com.journal \
--since today

یا

sudo journalctl \
--file=/var/log/journal/remote/remote-CN=client.example.com.journal \
--since "1 hour ago"

بررسی وضعیت سرویس‌ها

اگر لاگ‌ها ارسال نمی‌شوند، ابتدا وضعیت سرویس‌ها را بررسی کنید.

روی کلاینت:

sudo systemctl status systemd-journal-upload

روی سرور:

sudo systemctl status systemd-journal-remote

اگر هر دو سرویس در وضعیت زیر باشند، ارتباط برقرار است.

Active: active (running)

خطاهای رایج

اگر فایل Journal روی سرور ایجاد نشد، موارد زیر را بررسی کنید.

۱. DNS

اطمینان حاصل کنید کلاینت بتواند سرور را Resolve کند.

ping logs.example.com

۲. باز بودن پورت

روی سرور:

sudo ss -lntp | grep 19532

اگر خروجی نداشت، سرویس هنوز Listen نمی‌کند.

۳. فایروال

sudo ufw status

اطمینان حاصل کنید پورت 19532/tcp باز باشد.

۴. گواهی TLS

بررسی کنید تاریخ انقضای گواهی نگذشته باشد.

openssl x509 \
-in /etc/letsencrypt/live/logs.example.com/fullchain.pem \
-noout -dates

۵. بررسی لاگ سرویس

در بیشتر مواقع علت اصلی خطا در لاگ سرویس مشخص می‌شود.

روی سرور:

journalctl -u systemd-journal-remote -f

روی کلاینت:

journalctl -u systemd-journal-upload -f

این دو دستور تقریباً تمام مشکلات مربوط به TLS، دسترسی فایل‌ها و ارتباط شبکه را نمایش می‌دهند.

نتیجه‌گیری

در این آموزش یاد گرفتید چگونه با استفاده از systemd-journal-remote و systemd-journal-upload یک زیرساخت Centralized Logging روی Debian 13 راه‌اندازی کنید.

در طول مقاله مراحل زیر را انجام دادیم:

• نصب سرویس‌های موردنیاز روی سرور و کلاینت
• دریافت گواهی‌های TLS از Let’s Encrypt
• رمزنگاری ارتباط بین سرورها
• پیکربندی سرور مرکزی برای دریافت لاگ‌ها
• پیکربندی کلاینت برای ارسال خودکار لاگ‌ها
• بررسی صحت عملکرد سرویس‌ها
• تست ارسال و دریافت لاگ‌ها

در پایان، اکنون تمام لاگ‌های سیستم‌های شما در یک محل متمرکز ذخیره می‌شوند و می‌توانید بدون نیاز به اتصال مستقیم به هر سرور، رخدادها و خطاها را بررسی کنید.

بهترین روش‌ها (Best Practices)

برای اینکه زیرساخت ثبت لاگ شما در محیط Production پایدارتر و امن‌تر باشد، رعایت نکات زیر توصیه می‌شود.

۱. استفاده از فضای ذخیره‌سازی مجزا

اگر حجم لاگ‌ها زیاد است، بهتر است مسیر

/var/log/journal

روی یک دیسک یا پارتیشن مجزا قرار بگیرد تا پر شدن فضای دیسک باعث اختلال در سیستم‌عامل نشود.

۲. تنظیم محدودیت حجم لاگ‌ها

برای جلوگیری از اشغال بیش از حد فضای ذخیره‌سازی، فایل زیر را ویرایش کنید.

sudo nano /etc/systemd/journald.conf

به عنوان مثال:

SystemMaxUse=10G
SystemKeepFree=5G
SystemMaxFileSize=512M
RuntimeMaxUse=1G

سپس سرویس را ریستارت کنید.

sudo systemctl restart systemd-journald

۳. مانیتورینگ سلامت سرویس

پیشنهاد می‌شود وضعیت سرویس‌های زیر به‌صورت دوره‌ای بررسی شوند.

systemd-journal-upload

و

systemd-journal-remote

در صورت توقف سرویس، می‌توانید Restart خودکار را نیز فعال کنید.

۴. محدود کردن دسترسی شبکه

اگر تمام سرورها داخل شبکه خصوصی پارمین کلود قرار دارند، بهتر است پورت 19532 فقط از همان شبکه قابل دسترس باشد و از اینترنت عمومی باز نباشد.

۵. تمدید خودکار گواهی‌ها

هر چند Certbot این کار را به‌صورت خودکار انجام می‌دهد، اما بهتر است هر چند وقت یکبار وضعیت Timer را بررسی کنید.

systemctl status certbot.timer

۶. تهیه نسخه پشتیبان

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

/var/log/journal/

توسعه زیرساخت در آینده

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

از جمله:

• Grafana Loki
• OpenSearch
• Elastic Stack (ELK)
• Graylog
• Fluent Bit
• Fluentd

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

جمع‌بندی

راه‌اندازی یک سامانه متمرکز برای جمع‌آوری لاگ‌ها، یکی از مهم‌ترین اقدامات در مدیریت زیرساخت‌های لینوکسی است. با استفاده از systemd-journal-remote می‌توانید بدون نصب نرم‌افزارهای جانبی، لاگ‌های تمام سرورهای Debian 13 را به‌صورت امن و رمزنگاری‌شده در یک سرور مرکزی ذخیره کنید.

این راهکار علاوه بر افزایش امنیت و سهولت عیب‌یابی، امکان نگهداری طولانی‌مدت لاگ‌ها، تحلیل بهتر رخدادها و مانیتورینگ متمرکز را نیز فراهم می‌کند. در صورتی که در آینده زیرساخت شما گسترش پیدا کند، می‌توانید همین بستر را با ابزارهایی مانند Grafana Loki یا OpenSearch ترکیب کنید و یک سامانه کامل مدیریت لاگ در مقیاس سازمانی داشته باشید.

از همراهی شما با پارمین کلود سپاسگزاریم.