چرا این موضوع مهم است؟
eBPF برنامه‌های محدود و verifierشده را در نقاط مشخص kernel اجرا می‌کند. tracepoint، kprobe و network hook هرکدام visibility متفاوت دارند. ابزارهایی مانند BCC abstraction آماده روی این primitiveها می‌سازند.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع مشاهدهٔ kernel و شبکه با eBPF/BCC، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
از سؤال شروع کنید: کدام syscall کند است؟ retransmission کجاست؟ process روی چه I/O منتظر است؟ بعد ابزار کم‌دامنه انتخاب کنید و window جمع‌آوری کوتاه نگه دارید.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
جمع‌آوری همهٔ eventها روی production می‌تواند overhead و data flood بسازد. interpretation kernel event بدون context application هم ممکن است root cause کاذب بدهد.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
یک workload با disk یا network delay مصنوعی بسازید، یک ابزار BCC/eBPF مرتبط اجرا کنید و timeline kernel event را با latency application مقایسه کنید.
برای هر مرحله 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 موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ مشاهدهٔ kernel و شبکه با eBPF/BCC ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از Red Hat انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
از شکایت کاربر به سؤال قابل اندازه‌گیری برسید
فرض کنید کاربران می‌گویند بارگذاری صفحه گاهی چند ثانیه طول می‌کشد، در حالی که مصرف متوسط پردازنده پایین است. این توصیف هنوز انتخاب ابزار را تعیین نمی‌کند. ابتدا بازه زمانی درخواست کند، میزبان، فرایند و مسیر درخواست را مشخص کنید. سپس فرضیه‌ها را جدا کنید: انتظار برای خواندن دیسک، توقف در صف زمان‌بندی، اتصال شبکه یا قفل داخلی برنامه. ابزار رهگیری زمانی مفید است که بتواند میان این فرضیه‌ها تفاوت ایجاد کند، نه اینکه صرفاً تعداد زیادی رویداد تولید کند.
اگر فرضیه انتظار دیسک است، توزیع تأخیر عملیات ورودی و خروجی را در همان بازه بررسی کنید. اگر شبکه مظنون است، تأخیر اتصال و رخدادهای ارسال مجدد را با درخواست‌های کند مقایسه کنید. مشاهده هم‌زمان دو قله به معنای اثبات علت نیست؛ ممکن است هر دو نتیجه فشار دیگری باشند. برای نزدیک شدن به علت، یک متغیر را در آزمایشگاه تغییر دهید و ببینید آیا همان نشانه و همان اثر کاربردی دوباره ظاهر می‌شود یا خیر.
تفاوت نقطه اتصال و معنای رویداد
Tracepoint یک نقطه مشاهده تعریف‌شده در هسته است، در حالی که اتصال به تابع داخلی هسته می‌تواند به جزئیات پیاده‌سازی حساس‌تر باشد. انتخاب میان آنها تنها مسئله راحتی نوشتن برنامه نیست؛ پایداری ابزار در نسخه‌های مختلف نیز اهمیت دارد. نام تابعی که در یک هسته وجود دارد ممکن است در محیط دیگر در دسترس نباشد یا رفتار متفاوتی داشته باشد. پیش از توزیع ابزار سفارشی، سازگاری آن را با هسته‌های واقعاً موجود در ناوگان بررسی کنید.
رویداد در سطح هسته نیز الزاماً همان مفهوم تجاری درخواست نیست. یک عملیات فایل ممکن است به درخواست کاربر، کار پس‌زمینه یا چرخش گزارش تعلق داشته باشد. برای تفسیر درست، شناسه فرایند، فضای نام، نام سرویس و زمان را با داده برنامه ارتباط دهید. در محیط کانتینری، شناسه دیده‌شده روی میزبان ممکن است با شناسه داخل کانتینر یکسان نباشد. بدون این ترجمه، احتمال نسبت دادن فعالیت به سرویس اشتباه وجود دارد.
تجمیع در محل و محدود کردن خروجی
اگر هدف شناخت توزیع زمان است، ارسال تک‌تک رویدادها به فضای کاربر همیشه لازم نیست. شمارنده یا هیستوگرام می‌تواند حجم خروجی را کاهش دهد و خواندن نتیجه را آسان‌تر کند. البته این انتخاب جزئیات هر نمونه را حذف می‌کند؛ بنابراین باید از ابتدا بدانید به شواهد موردی احتیاج دارید یا به تصویر آماری. در یک بررسی مرحله‌ای، ابتدا نمای کلی بگیرید و سپس فقط برای فرایند یا بازه مشکوک جزئیات بیشتری جمع کنید.
فیلتر را تا حد امکان به هدف آزمایش محدود کنید. ثبت همه عملیات همه فرایندها روی میزبان پرترافیک می‌تواند هم هزینه ایجاد کند و هم اطلاعات حساس در نام فایل یا آرگومان‌ها آشکار سازد. اندازه بافر، رخدادهای ازدست‌رفته و زمان اجرای جمع‌آوری را ثبت کنید. اگر ابزار اعلام می‌کند نمونه‌هایی حذف شده‌اند، نتیجه را به عنوان شمارش کامل رخدادها ارائه نکنید. این محدودیت بخشی از گزارش فنی است، نه نقصی که باید از خواننده پنهان شود.
وقتی ابزار اجرا نمی‌شود چه کنیم؟
شکست بارگذاری برنامه می‌تواند از امکانات هسته، سیاست دسترسی، تنظیمات ساخت یا محدودیت محیط ناشی شود. پیام verifier را با خطای مجوز اشتباه نگیرید؛ اولی ممکن است به شیوه دسترسی برنامه به حافظه مربوط باشد و دومی به اختیارات فرایند. دادن دسترسی مدیریتی گسترده بدون فهم خطا راه مناسبی برای راه‌اندازی ابزار نیست. نسخه ابزار، هسته، پیکربندی لازم و پیام کامل غیرحساس را کنار هم بررسی کنید.
پس از پایان بررسی، اتصال‌های رهگیری و فرایند جمع‌آوری را متوقف کنید و مطمئن شوید ابزار موقتی به سرویس دائمی تبدیل نشده است. گزارش نهایی باید سؤال اولیه، دامنه مشاهده، مدت نمونه‌گیری، محدودیت داده و نتیجه قابل اقدام را شامل شود. مثلاً بیان کنید کدام دسته عملیات با تأخیر هم‌بستگی داشته و برای اثبات علت چه آزمایش دیگری لازم است. چنین گزارشی از یک تصویر جذاب ولی بدون زمینه، برای تیم توسعه و عملیات بسیار مفیدتر خواهد بود.
