چرا این موضوع مهم است؟
Loki به‌جای full-text index گسترده، metadata/label streamها را index می‌کند و محتوای log را در chunkها نگه می‌دارد. این مدل هزینهٔ index را کم می‌کند، اما کیفیت query به انتخاب label و محدودکردن stream وابسته است.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع معماری log aggregation در Grafana Loki و طراحی label سالم، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
label را برای dimensionهای کم‌کاردینالیتی مثل service، namespace و environment نگه دارید. request ID یا user ID را label نکنید و آن‌ها را داخل log line نگه دارید. retention و object storage را متناسب با نیاز audit طراحی کنید.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
label با cardinality بالا می‌تواند تعداد streamها را منفجر کند. همچنین تصور اینکه Loki یک SIEM کامل یا search engine عمومی است، query pattern نامناسب و هزینهٔ غیرضروری ایجاد می‌کند.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
یک workload کوچک با چند service به Loki بفرستید، یک label پرکاردینالیتی اضافه کنید و تفاوت تعداد stream و query behavior را قبل و بعد مقایسه کنید.
برای هر مرحله timestamp و خروجی را ذخیره کنید. یک failure کنترل‌شده ایجاد کنید تا مطمئن شوید monitoring واقعاً failure را می‌بیند. سپس سیستم را به baseline برگردانید و زمان recovery را ثبت کنید.
عیب‌یابی بر پایهٔ Evidence
Troubleshooting را با تغییر config شروع نکنید. اول محل دقیق failure را پیدا کنید: آیا ورودی وارد سیستم می‌شود؟ آیا state مورد انتظار ساخته شده؟ آیا policy اجازه می‌دهد؟ آیا خروجی از component خارج می‌شود؟ log، packet capture، metric و state API باید به یک timeline مشترک وصل شوند. نبودن event نیز evidence است؛ اگر request قبل از یک component دیده می‌شود و بعد از آن نه، دامنهٔ مسئله کوچک شده است.
Performance و ظرفیت
عملکرد را فقط با average نسنجید. p95/p99 latency، saturation، queue depth، retry و resource pressure تصویر بهتری می‌دهند. تغییری که در lab کوچک سریع است ممکن است زیر concurrency یا dataset واقعی bottleneck متفاوتی نشان دهد. capacity limitها را قبل از rollout بزرگ شناسایی کنید و alert را به thresholdهای قابل اقدام وصل کنید.
Production readiness
قبل از rollout نهایی، owner، change window، blast radius، success metric و rollback trigger باید مشخص باشند. اگر dependency خارجی دارید، رفتار هنگام timeout یا unavailable شدن آن را تست کنید. اگر config به چند host می‌رود، rollout مرحله‌ای و inventory دقیق لازم است. یک تغییر خوب باید observable، explainable و reversible باشد.
Runbook و انتقال دانش
در مستندسازی، فقط «چه دستورهایی اجرا شد» را ننویسید. سؤال، فرضیه، evidence مورد انتظار، نتیجه و دلیل تصمیم را ثبت کنید. اگر همکار دیگری بتواند با همان ورودی آزمایش را تکرار کند و به نتیجهٔ مشابه برسد، runbook ارزش عملیاتی دارد. اگر فقط نویسنده می‌داند چرا مرحله‌ای لازم است، دانش هنوز منتقل نشده است.
قبل از Production چه چیزی را اعتبارسنجی کنیم؟
نتیجهٔ Lab را مستقیم به Production تعمیم ندهید. یک change plan کوتاه بسازید که در آن دامنهٔ تغییر، owner، زمان اجرا، dependencyها، success metric و rollback trigger مشخص باشد. ابتدا روی canary یا درصد کوچکی از workload اجرا کنید و حداقل یک چرخهٔ واقعی restart، credential rotation یا deploy دوم را ببینید؛ بسیاری از خطاها در اولین اجرای سالم ظاهر نمی‌شوند. رفتار هنگام unavailable شدن dependency خارجی، پر شدن disk، timeout شبکه و ورودی نامعتبر را نیز بررسی کنید. اگر feature امنیتی است، test منفی باید نشان دهد مسیر غیرمجاز واقعاً بسته است؛ اگر feature performance است، benchmark باید با load و dataset نزدیک به واقعیت اجرا شود. در پایان، تصمیم rollout را با evidence ثبت کنید، نه با جملهٔ مبهم «به‌نظر خوب است».
نگهداری بلندمدت و بازبینی دوره‌ای
معماری بعد از deploy ثابت نمی‌ماند. نسخهٔ سیستم‌عامل، dependency، policy سازمان، certificate، endpoint و حجم workload تغییر می‌کنند. برای همین باید بازبینی دوره‌ای تعریف شود: نسخه‌های پشتیبانی‌نشده را پیدا کنید، exceptionهای قدیمی را ببندید، alertهای بی‌ارزش را حذف کنید و recovery را دوباره تمرین کنید. اگر configuration در Git نگهداری می‌شود، drift میان state واقعی و repository را اندازه بگیرید. اگر ابزار SaaS یا سرویس خارجی است، تغییر API، pricing، limit و مدل permission را دنبال کنید. مستندات باید تاریخ review داشته باشند تا تیم بداند کدام فرض‌ها هنوز معتبرند. نگهداری خوب یعنی سیستم بعد از شش ماه هم قابل توضیح و قابل بازیابی باشد، نه اینکه فقط روز اول deploy موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ معماری log aggregation در Grafana Loki و طراحی label سالم ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از Grafana Loki انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
طراحی برچسب با یک مثال واقعی
فرض کنید برنامه سفارش در سه محیط و چند نسخه اجرا می‌شود. محیط، نام سرویس و سطح اهمیت رویداد می‌توانند نقاط شروع مناسبی برای انتخاب جریان باشند. شناسه سفارش در مقابل برای هر درخواست تغییر می‌کند و برچسب‌گذاری آن تعداد جریان‌ها را بسیار افزایش می‌دهد. اگر هر سفارش یک جریان مستقل بسازد، هزینه نگهداری و پردازش با ارزش عملی داده تناسب نخواهد داشت. بهتر است این شناسه در متن ساخت‌یافته رویداد بماند و پس از محدود کردن دامنه زمانی و سرویس، هنگام جست‌وجو استخراج شود.
این تصمیم به معنی حذف جزئیات نیست؛ محل استفاده از جزئیات را تغییر می‌دهد. اپراتور ابتدا محیط تولید و سرویس سفارش را انتخاب می‌کند، بازه مشکل را کوتاه می‌کند و سپس پیام‌های مرتبط با شماره سفارش را بررسی می‌کند. چنین ترتیبی هم سؤال را روشن‌تر می‌کند و هم از جست‌وجوی گسترده در داده نامرتبط جلوگیری می‌کند. اگر کاربران همیشه مجبورند بدون دانستن سرویس در متن تمام سازمان جست‌وجو کنند، طراحی تجربه جست‌وجو و انتخاب ابزار باید دوباره ارزیابی شود.
تفاوت مدل ذخیره‌سازی با انتظار از جست‌وجو
Loki برچسب‌ها را برای یافتن جریان‌های مرتبط به کار می‌گیرد و متن رویدادها در قطعه‌ها نگهداری می‌شود. نتیجه عملی این است که انتخاب برچسب و بازه زمانی در هزینه جست‌وجو نقش پررنگی دارد. مقایسه با Elasticsearch نباید به یک جمله درباره سریع‌تر بودن ختم شود. اگر نیاز اصلی جست‌وجوی پیچیده متن آزاد در مجموعه بزرگ است، آزمون باید همان الگو را بسنجد. اگر بیشتر سؤال‌ها از نام سرویس و زمان حادثه شروع می‌شوند، مدل جریان می‌تواند با نیاز تیم هماهنگ‌تر باشد.
برای ارزیابی، چند پرسش واقعی از حوادث گذشته جمع کنید. مثلاً یافتن خطاهای یک نسخه، شمارش پیام مشخص در یک ساعت و دنبال کردن یک شناسه درخواست. داده آزمایش باید توزیع و تنوع برچسب مشابه محیط واقعی داشته باشد. اجرای یک جست‌وجوی ساده روی فایل کوچک، ظرفیت سامانه را نشان نمی‌دهد. علاوه بر زمان پاسخ، حجم خوانده‌شده، منابع مصرفی و رفتار با چند کاربر هم‌زمان را بررسی کنید تا هزینه تجربه کاربر روشن شود.
کیفیت ورودی و زمان رویداد
اگر برنامه زمان را بدون منطقه زمانی بنویسد یا جمع‌آورنده زمان دریافت را جای زمان وقوع قرار دهد، ترتیب رویدادها در حادثه مبهم می‌شود. نمونه‌ای از هر برنامه بردارید و زمان تولید، دریافت و نمایش را مقایسه کنید. رویداد چندخطی مانند رد پشته نیز باید به صورت یک واحد منطقی پردازش شود؛ شکستن آن به چند خط مستقل جست‌وجو و شمارش خطا را منحرف می‌کند. تغییر قالب رویداد در یک انتشار برنامه باید مانند تغییر قرارداد داده آزمایش شود.
جمع‌آورنده نیز ممکن است هنگام چرخش فایل، قطعی شبکه یا توقف ناگهانی با داده تکراری یا از دست‌رفته مواجه شود. یک فایل آزمایشی با شماره ترتیبی رویدادها تولید کنید و چرخش فایل را اجرا کنید. سپس شماره‌های موجود در مقصد را با ورودی مقایسه کنید. این آزمایش ساده مشخص می‌کند آیا مسیر واقعاً داده را کامل منتقل می‌کند یا فقط در شرایط آرام کار می‌کند. نتیجه باید همراه با تنظیمات صف و محل ذخیره موقعیت خواندن ثبت شود.
نگهداری و مرز دسترسی
رویدادهای برنامه ممکن است اطلاعات شخصی، نشانی داخلی یا جزئیات خطا داشته باشند. پاک‌سازی در مسیر ورود و محدود کردن دسترسی دو کنترل جدا هستند. حذف از صفحه داشبورد معادل حذف از ذخیره‌ساز نیست؛ سیاست نگهداری باید برای محل ذخیره واقعی تعریف شود. همچنین باید معلوم باشد چه کسی می‌تواند دامنه مستأجر یا محیط را انتخاب کند. اگر مرز چندمستأجری به یک هدر وابسته است، آن هدر باید در نقطه مورد اعتماد تعیین شود و کاربر عادی نتواند آن را دلخواه تغییر دهد.
