بخش ۱ — فلسفهٔ مرکزیت: چرا لاگ پراکنده شکست می‌خورد
نگه‌داشتن لاگ هر میزبان روی دیسک خودش، تا وقتی تعداد میزبان‌ها کم است کار می‌کند. اما به‌محض اینکه شبکه از چند ماشین بگذرد، هیچ‌کس تصویر کامل را در اختیار ندارد و شواهدی که در لحظهٔ حادثه لازم است، پراکنده و ناقص می‌شود. این بخش، پنج مشکلی را نام می‌برد که لاگ پراکنده را از کار می‌اندازد و نشان می‌دهد مرکزیت چگونه به هرکدام پاسخ می‌دهد.
یک سناریو که همه‌چیز را روشن می‌کند
شرکتی را تصور کنید که ۲۰۰ سرور دارد. هر سرور لاگ خودش را در مسیر /var/log روی دیسک محلی می‌نویسد و تیم عملیات یک رویهٔ ساده دارد: به سرور مربوطه SSH بزن و لاگ را ببین. این رویه برای یک سرور عالی است و برای ۲۰۰ سرور فاجعه.
یک روز صبح، مدیرعامل متوجه می‌شود داده‌های مشتریان در یک انجمن اینترنتی فروخته می‌شود. تیم امنیت مأمور بررسی می‌شود و نخستین سؤال روشن است: مهاجم از کجا وارد شده است؟ تحلیلگر باید به ۲۰۰ سرور وصل شود، فایل‌های لاگ را دستی جمع کند و ترتیب زمانی رویدادها را بازسازی کند. در همین حین، پنج مانع پیش می‌آید:
- سه سرور در هفتهٔ گذشته ری‌استارت شده‌اند و لاگ‌هایشان از بین رفته است.
- فایروال لاگ‌هایش را فقط ۷ روز نگه می‌دارد، در حالی که حمله احتمالاً دو هفته پیش شروع شده است.
- ساعت یکی از سرورها ۴۰ دقیقه عقب است و ترتیب رویدادها را به هم می‌ریزد.
- هر سرور قالب لاگ خودش را دارد و مقایسهٔ آن‌ها با هم زمان‌بر است.
- حجم لاگ‌ها آن‌قدر زیاد است که جست‌وجوی دستی در آن‌ها هفته‌ها طول می‌کشد.
تحلیلگر پس از سه روز کار فقط می‌تواند بگوید احتمالاً ورود از یک سرور وب بوده، ولی مطمئن نیست. چنین پاسخی برای مدیرعامل، مشتریان و نهاد نظارتی کافی نیست. شرکت نمی‌داند چه داده‌ای رفته، چه کسی آن را برده و چطور جلوی تکرارش را بگیرد.
وقتی لاگ یک میزبان دیگر به مقصد نمی‌رسد، از بیرون دقیقاً شبیه روزی دیده می‌شود که هیچ اتفاقی نیفتاده است. نبودن داده و نبودن حادثه از بیرون تفاوتی با هم ندارند و همین ابهام، لاگ پراکنده را خطرناک می‌کند.
این سناریو خیالی نیست و دقیقاً در سازمان‌هایی رخ می‌دهد که لاگ‌ها را پراکنده نگه می‌دارند. همین سناریو، روشن‌ترین بیان فلسفهٔ مرکزیت است: لاگ پراکنده، در لحظهٔ حادثه، عملاً وجود ندارد.
پنج مشکل بنیادین پشت این ناکارآمدی قرار دارند: مقیاس، زمان، قالب، عمر داده و ظرفیت انسانی. در پنج بخش بعد، هرکدام جداگانه بررسی می‌شود و خواهید دید مرکزیت چگونه هر پنج را حل می‌کند.
مقیاس
نخستین مشکل، ساده‌ترین و در عین حال بنیادی‌ترین است: تعداد. با یک سرور، لاگ محلی کافی است و با ده سرور می‌توان با یک اسکریپت همه را جمع کرد. با صد سرور، آن اسکریپت شکست می‌خورد و با هزار سرور، «جمع کردن» دیگر یک کار دستی نیست بلکه یک مسئلهٔ مهندسی است.
چرا؟ چون جمع‌کردن لاگ از هزار سرور، سه چالشی می‌سازد که در یک سرور وجود نداشتند.
اول، حجم. هزار سرور، هرکدام روزانه چند گیگابایت لاگ تولید می‌کنند و مجموع روزانه به چند ترابایت می‌رسد. این حجم را نمی‌توان در فایل‌های متنی ساده ذخیره و جست‌وجو کرد. نیاز به یک پایگاه دادهٔ تخصصی است که بتواند میلیون‌ها رکورد را در چند ثانیه پیدا کند.
دوم، تنوع. هزار سرور یعنی هزار پیکربندی متفاوت. برخی لاگ را به Syslog می‌فرستند، برخی در فایل می‌نویسند و برخی در پایگاه داده. برخی با UTF-8 کار می‌کنند و برخی با Latin-1، و برخی زمان را به وقت محلی می‌نویسند در حالی که برخی دیگر به UTC. بدون یک لایهٔ نرمال‌سازی، این تنوع داده را غیرقابل استفاده می‌کند.
سوم، اطمینان. وقتی لاگ را از هزار سرور جمع می‌کنید، از کجا می‌دانید که همه واقعاً لاگ فرستاده‌اند؟ اگر یک سرور حیاتی به‌دلیل خطای پیکربندی لاگ نفرستد، آن سرور را اصلاً نمی‌بینید و این کوری می‌تواند ماه‌ها پنهان بماند.
مرکز امنیت سایبری کانادا صریحاً هشدار می‌دهد که سازمان‌ها باید به‌طور منظم بررسی کنند آیا همهٔ منابع حیاتی واقعاً لاگ می‌فرستند یا نه. یک منبع خاموش، همان‌قدر نامرئی است که یک حمله.
مرکزیت، پاسخ به هر سه چالش است. یک سرور مرکزی که برای حجم طراحی شده باشد، تنوع را نرمال می‌کند و می‌تواند پایش کند کدام منابع دیگر لاگ نمی‌فرستند.
زمان
مشکل دوم ظریف‌تر است و اغلب نادیده گرفته می‌شود: ساعت. هر دستگاه ساعت خودش را دارد و این ساعت‌ها هرگز کاملاً همگام نیستند. اختلاف چند ثانیه‌ای طبیعی است و اختلاف چند دقیقه‌ای در شبکه‌های بزرگ هم غیرعادی نیست.
بازسازی یک حادثه بدون ترتیب زمانی دقیق، غیرممکن است. فرض کنید فایروال می‌گوید یک اتصال مشکوک ساعت ۹:۴۵ رخ داده و سرور وب می‌گوید همان اتصال ساعت ۱۰:۰۰ دریافت شده است. اگر ساعت فایروال ۱۵ دقیقه جلو باشد، ترتیب واقعی برعکس است، در حالی که تحلیلگر هرگز متوجه این جابه‌جایی نمی‌شود.
مرکز امنیت سایبری کانادا این موضوع را یک ریسک جدی می‌داند و تأکید می‌کند که حتی اختلاف کوچک در ساعت سیستم‌ها می‌تواند بازسازی توالی حمله را غیرممکن کند. راه‌حل، همگام‌سازی همهٔ دستگاه‌ها با یک منبع زمان واحد یعنی NTP است و این همگام‌سازی تنها زمانی قابل اعتماد است که یک مرجع مرکزی آن را پایش کند.
مرکزیت این مشکل را به دو شکل حل می‌کند. نخست، سرور مرکزی می‌تواند نقش مرجع زمان را بازی کند و همهٔ دستگاه‌ها را با خودش همگام کند. دوم، حتی اگر همگام‌سازی ناقص باشد، سرور مرکزی زمان دریافت هر لاگ را هم ثبت می‌کند تا تحلیلگر بتواند «زمان رویداد» را که دستگاه گزارش کرده از «زمان دریافت» که سرور مرکزی ثبت کرده جدا کند. این تمایز، همان چیزی است که تحلیل پس از حادثه بر آن تکیه می‌کند.
قالب
مشکل سوم در ظاهر ساده است ولی در عمل یکی از زمان‌برترین‌هاست: زبان مشترک. هر دستگاه، لاگ را با قالب خودش می‌نویسد.
یک فایروال ممکن است بنویسد: 2026-10-19 14:32:05 DENY TCP 10.0.1.5:443 -> 10.0.2.7:52341
یک سرور لینوکس ممکن است بنویسد: Oct 19 14:32:05 webserver sshd[1234]: Failed password for root from 10.0.1.5 port 52341
یک برنامهٔ وب ممکن است بنویسد: {"timestamp":"2026-10-19T14:32:05Z","level":"WARN","user":"ali","action":"login_failed","ip":"10.0.1.5"}
هر سه، یک رویداد را توصیف می‌کنند: تلاش ناموفق برای ورود از یک نشانی مشخص. اما سه قالب کاملاً متفاوت دارند، پس تحلیلگر نمی‌تواند آن‌ها را با یک جست‌وجوی ساده کنار هم بگذارد. باید هر کدام را جداگانه بفهمد و این کار در حجم میلیون‌ها رکورد، شدنی نیست.
مرکزیت این مشکل را با نرمال‌سازی حل می‌کند: تبدیل همهٔ قالب‌ها به یک ساختار واحد. پس از نرمال‌سازی، هر سه لاگ بالا به یک رکورد با فیلدهای یکسان تبدیل می‌شوند: زمان، منبع، مقصد، نوع رویداد و نتیجه. حالا یک جست‌وجو، هر سه را با هم نشان می‌دهد.
مرکز امنیت سایبری کانادا نرمال‌سازی را یکی از مزیت‌های اصلی معماری لاگ مرکزی می‌داند، چون همبستگی رویدادها از منابع مختلف را ممکن می‌سازد. بدون نرمال‌سازی، همبستگی ممکن نیست و بدون همبستگی، تشخیص حمله‌های چند مرحله‌ای هم ممکن نیست.
عمر داده
مشکل چهارم دربارهٔ بقا است. لاگ محلی شکننده است و سه چیز می‌تواند آن را از بین ببرد.
اول، ری‌استارت. اگر سرور ری‌استارت شود و لاگ در مسیر /var/log با پیکربندی پیش‌فرض نوشته شده باشد، بخشی از لاگ ممکن است از دست برود. سیستم‌هایی که از tmpfs استفاده می‌کنند، مثل بسیاری از توزیع‌های مدرن برای مسیر /var/log/journal، با هر ری‌استارت همه‌چیز را از دست می‌دهند.
دوم، پر شدن دیسک. لاگ‌ها رشد می‌کنند و اگر چرخهٔ عمر فایل‌ها درست تنظیم نشده باشد، دیسک پر می‌شود. در آن صورت یا سرور از کار می‌افتد یا لاگ‌های قدیمی حذف می‌شوند و در هر دو حالت، داده از دست می‌رود.
سوم، از کار افتادن خود سرور. اگر سرور به‌دلیل خرابی سخت‌افزار یا حمله از دسترس خارج شود، لاگ‌هایش هم با آن می‌روند. بدتر آن‌که دقیقاً همان لاگ‌هایی که برای فهمیدن علت خرابی لازم بودند، از بین می‌روند.
این پارادوکس تلخِ لاگ محلی است: لاگ‌ها دقیقاً وقتی بیشترین نیاز را دارید، از بین می‌روند. در سناریوی بالا، سه سروری که ری‌استارت شده بودند دقیقاً همان رکوردهایی را نابود کردند که تحلیلگر برای پاسخ به سؤال مدیرعامل به آن‌ها نیاز داشت.
مرکزیت این مشکل را با جدا کردن «محل تولید» از «محل نگهداری» حل می‌کند. لاگ روی سرور مرکزی ذخیره می‌شود، مستقل از سرنوشت سروری که آن را تولید کرده است. اگر آن سرور از کار بیفتد، لاگ‌هایش سالم می‌مانند و اگر دیسکش پر شود، لاگ‌های قبلی از پیش روی سرور مرکزی امن هستند.
این جداسازی، یک اصل بنیادین در طراحی سیستم‌های قابل اعتماد است: هیچ سیستمی نباید تنها شاهد خودش باشد. سروری که ممکن است هک شود، نباید تنها نگهدارندهٔ لاگ‌هایی باشد که آن هک را ثبت می‌کنند. مرکزیت دقیقاً همین استقلال را فراهم می‌کند.
ظرفیت انسانی
مشکل پنجم دربارهٔ انسان است. حتی اگر همهٔ مشکلات پیشین حل شوند، یعنی حجم، زمان، قالب و عمر داده، باز هم یک مشکل باقی می‌ماند: تحلیلگر انسانی نمی‌تواند میلیون‌ها رویداد روزانه را دستی بررسی کند.
یک شبکهٔ متوسط روزانه میلیون‌ها رویداد تولید می‌کند که شاید تنها ده‌ها مورد آن‌ها واقعاً مهم باشد. اما تحلیلگر از کجا بداند کدام‌ها مهم‌اند؟ اگر همه را بررسی کند، سال‌ها وقت لازم دارد و اگر هیچ‌کدام را بررسی نکند، حمله‌ها را از دست می‌دهد.
مرکزیت این مشکل را با اتوماسیون حل می‌کند. سرور مرکزی می‌تواند قواعدی داشته باشد که رویدادهای مهم را از نویز جدا کنند، برای مثال قاعده‌ای که اگر یک کاربر در ۵ دقیقه ۱۰ بار ورود ناموفق داشته باشد، هشدار بدهد. چنین قاعده‌ای میلیون‌ها رویداد را فیلتر می‌کند و تنها ده‌ها مورد مهم را به انسان می‌رساند. این همان کاری است که یک SIEM انجام می‌دهد و در بخش ۴ به تفصیل توضیح داده شده است.
بدون مرکزیت، اتوماسیون ممکن نیست. داده در صد جای مختلف پراکنده است و هیچ‌کس نمی‌تواند روی همهٔ آن یک قاعده اجرا کند.
چرا یک اسکریپت ساده کافی نیست
ممکن است کسی بگوید یک اسکریپت cron بنویسیم که هر شب لاگ‌ها را از همهٔ سرورها به یک سرور مرکزی کپی کند و مشکل حل شد. این رویکرد در نگاه اول منطقی به نظر می‌رسد، اما در عمل با پنج محدودیت جدی روبه‌رو می‌شود.
اول، تأخیر. اسکریپت cron هر شب اجرا می‌شود، یعنی لاگ‌ها با ۲۴ ساعت تأخیر می‌رسند. اگر حمله‌ای ساعت ۳ بامداد رخ دهد، تا شب بعد هیچ‌کس خبر ندارد و در امنیت، ۲۴ ساعت تأخیر یعنی فاجعه.
دوم، حجم. کپی کردن چند ترابایت لاگ از ۲۰۰ سرور، هر شب، پهنای باند شبکه را می‌بلعد و ساعت‌ها طول می‌کشد. اگر شبکه در میانهٔ کپی قطع شود، کار باید از اول شروع شود.
سوم، قالب. اسکریپت cron، لاگ‌ها را همان‌طور که هستند کپی می‌کند و هیچ نرمال‌سازی انجام نمی‌دهد. نتیجه یک انبار بزرگ از فایل‌های ناهمگون است که هنوز قابل جست‌وجو نیستند.
چهارم، اطمینان. اسکریپت cron نمی‌داند که آیا همهٔ سرورها واقعاً لاگ فرستاده‌اند یا نه. اگر سروری به‌دلیل خطای پیکربندی لاگ نفرستد، هیچ هشداری صادر نمی‌شود و شما در حالی که یک حفرهٔ نامرئی دارید، فکر می‌کنید همه‌چیز را دارید.
پنجم، مقیاس‌پذیری. اسکریپت cron برای ۱۰ سرور کار می‌کند. برای ۱۰۰۰ سرور باید ده‌ها اسکریپت موازی بنویسید و مدیریت کنید و این کار در عمل به یک پروژهٔ مهندسی کامل تبدیل می‌شود، بدون آن‌که حتی یکی از مزایای یک راه‌حل تخصصی را داشته باشد.
پاسخ واقعی یک اسکریپت cron نیست، بلکه معماری‌ای طراحی‌شده است: لایه‌های حمل، جمع‌آوری، پردازش، ذخیره‌سازی و تحلیل که هرکدام وظیفهٔ خودشان را دارند. معماری دقیق این لایه‌ها موضوع بخش ۳ است.
مفهوم «منبع حقیقت واحد»
همهٔ مشکلات پیشین در نهایت به یک مفهوم بنیادین برمی‌گردند: منبع حقیقت واحد یا همان Single Source of Truth. در هر سیستم پیچیده، وقتی داده در چند جای مختلف ذخیره می‌شود، سه پرسش پیش می‌آید: کدام نسخه درست است؟ کدام نسخه جدیدتر است؟ و آیا اصلاً همهٔ نسخه‌ها را داریم؟
منبع حقیقت واحد یعنی یک جای مشخص که همه قبول دارند نسخهٔ مرجع آنجاست. در لاگ، این یعنی یک سرور مرکزی که همهٔ لاگ‌ها در آن جمع می‌شوند و هر تحلیل و تصمیمی بر اساس آن گرفته می‌شود. اگر تحلیلگر بخواهد بداند دیروز چه اتفاقی افتاده است، به یک جا نگاه می‌کند، نه به ۲۰۰ جا.
مرکز امنیت سایبری کانادا در راهنمای خود تأکید می‌کند که معماری لاگ باید نمایی واحد از همهٔ رویدادها فراهم کند تا تشخیص توزیع‌شده و تحلیل پس از حادثه ممکن شود. بدون این نمای واحد، هر تحلیلی روی تکه‌ای ناقص از داده انجام می‌شود و نتیجه‌اش قابل اعتماد نیست.
این مفهوم فقط یک ایدهٔ معماری نیست، بلکه یک نیاز عملیاتی است. معماری زیر، همزمان به هر پنج مشکل پاسخ می‌دهد: منابع پراکنده در یک نقطه همگرا می‌شوند، قالب و ساعت یکدست می‌شوند، داده از سرور مبدأ جدا می‌ماند و قواعد، همان کاری را برای تحلیلگر انسانی می‌کنند که او از پسش برنمی‌آید.
جمع‌بندی
پنج مشکل بنیادین وجود دارد که لاگ پراکنده را در شبکه‌های بزرگ از کار می‌اندازد:
| مشکل | چه اتفاقی می‌افتد | مرکزیت چه می‌کند |
|---|---|---|
| مقیاس | جمع کردن لاگ از صدها سرور دستی و غیرممکن می‌شود | یک نقطهٔ جمع‌آوری طراحی‌شده برای حجم |
| زمان | اختلاف ساعت، ترتیب رویدادها را به هم می‌ریزد | مرجع زمان واحد و ثبت زمان دریافت |
| قالب | هر دستگاه زبان خودش را دارد | نرمال‌سازی به ساختار واحد |
| عمر داده | لاگ محلی با ری‌استارت یا پر شدن دیسک از بین می‌رود | جداسازی محل تولید از محل نگهداری |
| ظرفیت انسانی | تحلیلگر نمی‌تواند میلیون‌ها رویداد را دستی بررسی کند | اتوماسیون و فیلتر هوشمند |
مرکزیت، پاسخ به هر پنج مشکل است. اما مرکزیت یک ابزار واحد نیست؛ یک خانوادهٔ کامل از ابزارهاست که هرکدام بخشی از این پاسخ را فراهم می‌کنند. بخش بعد، خانوادهٔ سرورهای لاگ مرکزی را معرفی می‌کند.
بخش قبل: بخش ۰ — مقدمه · بخش بعد: بخش ۲ — خانوادهٔ سرورهای لاگ مرکزی · فهرست بخش‌ها