Linux log ব্যবস্থাপনা: journalctl, logrotate ও disk সুরক্ষা

কিছু ভাঙলে log বলে দেয় কী ঘটেছিল। কিন্তু log-এর দুটি সমস্যা: অনেক হলে পড়া কঠিন, আর তারা disk ভরা পর্যন্ত বাড়ে। Log ব্যবস্থাপনা মানে তিনটি জিনিস: log কোথায় আছে জানা, কতটা জায়গা নেয় তা সীমিত করা, এবং কাজের log লেখা। নিচের logrotate ডেমো চালানো হয়েছে (logrotate 3.22, সাময়িক container-এ, কিছু রাখা হয়নি)। journalctl কমান্ডগুলো প্রচলিত, আর read-only গুলো একটি Linux server-এ যাচাই করা হয়েছে।

Log কোথায় থাকে

• systemd journal (journald): systemd দিয়ে চালু হওয়া service-এর log, binary ধাঁচে জমা, journalctl দিয়ে পড়া।
• /var/log-এ সাধারণ ফাইল: যেমন web server log (/var/log/nginx/access.log, error.log), Debian ও Ubuntu-তে auth.log ও syslog।
• আপনার নিজের অ্যাপের ফাইল, যেখানে কনফিগার করেছেন।
• Container: container যা standard output-এ লিখেছে তা docker logs <container> পড়ে।

অ্যাপের জন্য ভালো নিয়ম: log standard output-এ লিখুন এবং platform (systemd, Docker)-কে সংগ্রহ করতে দিন। সামলানোর ফাইল কম।

Journal পড়া: journalctl

journalctl -u nginx -n 50 --no-pager      # এক service-এর শেষ ৫০ লাইন
journalctl -u myapp -f                    # সরাসরি অনুসরণ
journalctl -p err -b                      # এই boot-এর পর থেকে error
journalctl --since "2026-10-28 02:00" --until "2026-10-28 03:00"
journalctl -k                             # kernel বার্তা (out of memory kill, disk error)
journalctl -u myapp -o json-pretty -n 1   # কাঠামোবদ্ধ আউটপুট

-p priority (err, warning, info...) দিয়ে ছাঁকে। -b মানে "এই boot"। -u একটি unit (service) বাছে। সমস্যা দ্রুত সংকীর্ণ করতে এগুলো মেলান।

Journal-এর আকার সীমিত করা

Journal বড় হয়ে যেতে পারে। দেখুন:

$ journalctl --disk-usage
Archived and active journals take up 311.7M in the file system.

(এটি একটি আসল server-এর সংখ্যা; আপনারটি আলাদা হবে।) সীমা দিতে /etc/systemd/journald.conf সম্পাদনা করুন:

[Journal]
SystemMaxUse=500M
MaxRetentionSec=1month

তারপর sudo systemctl restart systemd-journald। এখনই জায়গা ফাঁকা করতে: sudo journalctl --vacuum-size=200M বা --vacuum-time=2weeks। মনে রাখুন, reboot-এর পরও journal থাকে শুধু যদি /var/log/journal থাকে বা Storage=persistent দেওয়া হয়, আর এই ডিফল্ট distribution ভেদে আলাদা, তাই নিজেরটি দেখুন। দরকার পড়ার আগেই ঠিক করুন কত দিন log রাখতে হবে, কারণ নিরাপত্তা তদন্তে প্রায়ই সপ্তাহ বা মাসের ইতিহাস লাগে।

সাধারণ ফাইলের log rotate করা: logrotate

nginx বা আপনার অ্যাপের মতো ফাইল journal সামলায় না। logrotate বর্তমান log-এর নাম বদলায়, নতুন শুরু করে, পুরোনোগুলো compress করে ও সবচেয়ে পুরোনোটি মুছে দেয়। একটি সাধারণ config, যেমন /etc/logrotate.d/myapp:

/var/log/myapp/*.log {
    daily               # or: size 100M
    rotate 7            # keep 7 old files
    compress            # gzip old files
    delaycompress       # compress from the 2nd rotation (safe for apps still writing)
    missingok           # no error if the log is missing
    notifempty          # do not rotate empty files
    copytruncate        # copy then empty the file; use if the app cannot reopen its log
}

কাজ করে তার প্রমাণ

ইচ্ছা করে খুব ছোট আকারের সীমা দিয়ে একটি সাময়িক container-এ logrotate চালিয়েছি, প্রতিবারের আগে ৫০০ লাইন যোগ করে:

(size 1k, rotate 3, compress, delaycompress, copytruncate; each run adds 500 lines first)

after run 1:  app.log  app.log.1
after run 2:  app.log  app.log.1  app.log.2.gz
after run 3:  app.log  app.log.1  app.log.2.gz  app.log.3.gz
after run 4:  app.log  app.log.1  app.log.2.gz  app.log.3.gz      <- the oldest was deleted
after run 5:  app.log  app.log.1  app.log.2.gz  app.log.3.gz

সবচেয়ে নতুন পুরোনো ফাইল এক চক্র compress ছাড়া থাকে (delaycompress), পুরোনোগুলো gzip হয়, আর তৃতীয় rotation-এর পর সবচেয়ে পুরোনো ফাইল মুছে যায়, তাই মোট ফাইলের সংখ্যা rotate 3-এ স্থির থাকে। এভাবেই জায়গা নিয়ন্ত্রণে থাকে।

যে বাছাই গুরুত্বপূর্ণ

• copytruncate বনাম অ্যাপকে সংকেত। অনেক প্রোগ্রাম log ফাইল খোলা রাখে। logrotate নাম বদলালে প্রোগ্রাম নাম-বদলানো ফাইলেই লিখে চলে। হয় postrotate script-এ অ্যাপকে log আবার খুলতে বলুন (nginx: master process-এ kill -USR1, বা nginx -s reopen), নয়তো copytruncate ব্যবহার করুন, যা ফাইল কপি করে খালি করে। copytruncate সহজ, কিন্তু কপির সময় লেখা কয়েক লাইন হারাতে পারে।
• daily বা size: স্থির ট্রাফিকে সময়ভিত্তিক, হঠাৎ-বাড়া log-এ আকারভিত্তিক।
• কিছু না বদলিয়ে config test করুন: logrotate -d /etc/logrotate.d/myapp (debug, dry run), আর আসল চালানো জোর করতে logrotate -f।
• বেশিরভাগ distribution প্রতিদিন systemd timer বা cron থেকে logrotate চালায়। /etc/logrotate.d/-এর config নিজে নিজে ধরা হয় যদি logrotate install থাকে। আপনার server-এ logrotate --version ও systemctl list-timers | grep logrotate দিয়ে তা নিশ্চিত করুন। package-এর ডিফল্ট প্রায়ই ধরে নেয় এটি আছে, আর ন্যূনতম server-এ নাও থাকতে পারে।

পড়ার মতো log লেখা

• Level ব্যবহার করুন: DEBUG, INFO, WARNING, ERROR। production-এ INFO-তে log করুন এবং তদন্তের সময়ই কেবল DEBUG চালু করুন।
• প্রসঙ্গ দিন: timestamp (UTC), service-এর নাম, request id, user id (ব্যক্তিগত তথ্য নয়), এবং কী ব্যর্থ হলো। শুধু "Error" অকেজো।
• প্রতি লাইনে একটি ঘটনা, অথবা আরও ভালো, কাঠামোবদ্ধ log (JSON) যা টুল ক্ষেত্র ধরে খুঁজতে পারে।
• Secret বা সংবেদনশীল data কখনো log করবেন না: পাসওয়ার্ড, token, পুরো কার্ড নম্বর, session cookie। Log কপি হয়, পাঠানো হয় ও অনেকে পড়ে।
• সীমা ছাড়া tight loop-এ log করবেন না। একটি গোলমেলে লাইন disk ভরাতে পারে।
• যেখানে error সামলান সেখানেই stack trace সহ log করুন, প্রতি স্তরে নয়। ডুপ্লিকেট log আসল log লুকায়।

Log কেন্দ্রীভূত করা

একটি server-এ journalctl ও grep যথেষ্ট। একাধিক server বা container থাকলে log কেন্দ্রীয় জায়গায় পাঠান (Grafana সহ Loki, ELK/OpenSearch stack বা hosted সেবা), যাতে crash হলে মেশিনের সঙ্গে log যায় না, আর service জুড়ে খোঁজা যায়। monitoring লেখার মতো error হারের ওপর alert-ও জুড়ুন।

সাপ্তাহিক দ্রুত checklist

১. df -h ও journalctl --disk-usage: জায়গা কমছে? ২. ls -lhS /var/log | head: কোনো ফাইল বিশাল বা কখনো rotate হয়নি? ৩. logrotate install ও চালু (systemctl list-timers)? ৪. Log-এ secret আছে? একটি নমুনায় password ও token খুঁজুন। ৫. গতকালের error এক মিনিটের কমে খুঁজে পান?

মূল কথা: journalctl দিয়ে log পড়ুন, আকার সীমিত করুন, সাধারণ ফাইলের log logrotate দিয়ে rotate করুন (এবং এটি আসলে install আছে কি না দেখুন), আর প্রসঙ্গসহ কাঠামোবদ্ধ, secret-মুক্ত log লিখুন।

---

Linux ও DevOps সিরিজ, পর্ব ৩ (প্রতিদিনের পরিচালনা): 5 নম্বর (মোট 5)। আগের লেখা: Git branching strategy: trunk-based, GitHub Flow ও Git Flow.