چرا این موضوع مهم است؟
OpenTelemetry یک backend monitoring نیست؛ مجموعه‌ای از API، SDK، semantic convention و protocol برای تولید و انتقال telemetry است. Trace رابطهٔ spanها را می‌دهد، metric روند عددی را و log رخداد متنی را؛ context propagation آن‌ها را به درخواست واحد وصل می‌کند.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع استانداردسازی telemetry با OpenTelemetry، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
instrumentation را با سؤال عملی شروع کنید. همه‌چیز را collect نکنید. Collector را مرز پردازش/فیلتر/ارسال قرار دهید و resource attributes را استاندارد کنید.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
cardinality کنترل‌نشده هزینه را انفجاری می‌کند. قرار دادن user ID یا URL خام در label metric نمونهٔ رایج است. trace بدون propagation درست نیز فقط مجموعه‌ای span جداست.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
یک API دو سرویسی بسازید، trace context را عبور دهید، Collector راه‌اندازی کنید و یک latency مصنوعی ایجاد کنید. سپس trace کند را از frontend تا backend دنبال کنید.
برای هر مرحله 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 موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ استانداردسازی telemetry با OpenTelemetry ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از OpenTelemetry انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
یک درخواست خرید را چگونه قابل پیگیری کنیم؟
در یک فروشگاه فرضی، درخواست ابتدا وارد درگاه وب می‌شود، سپس سرویس سبد خرید، سرویس موجودی و در پایان پرداخت را درگیر می‌کند. اگر فقط زمان کل پاسخ ثبت شود، مشخص نیست تأخیر در کدام مرز ایجاد شده است. برای هر کار معنادار یک span ایجاد می‌کنیم و رابطه والد و فرزند را حفظ می‌کنیم. هدف تکثیر رویداد برای هر خط کد نیست؛ مرز شبکه، عملیات پایگاه داده و کارهای مهم تجاری معمولاً نقطه شروع بهتری هستند. نام عملیات باید قابل جمع‌بندی باشد؛ قرار دادن شماره سفارش در نام span تحلیل تعداد زیادی درخواست را دشوار می‌کند.
شناسه ردیابی باید در عبور از مرز سرویس حفظ شود. اگر یک سرویس از پروتکل انتقال زمینه پشتیبانی نکند، ممکن است ادامه همان درخواست به شکل ردیابی جدا دیده شود. در ارتباط صف نیز زمان تولید پیام و زمان پردازش آن یکی نیست. تیم باید تصمیم بگیرد کدام رابطه برای مدل کاری مناسب است و در مصرف‌کننده زمینه پیام را استخراج کند. اختلاف ساعت میزبان‌ها هم بررسی شود؛ نمودار عجیب زمانی همیشه نشان‌دهنده فراخوانی غیرعادی برنامه نیست و گاهی ناشی از زمان‌بندی نادرست سیستم است.
انتخاب صفت‌هایی که بعداً قابل استفاده باشند
نام سرویس، محیط اجرا و نسخه برنامه معمولاً برای مقایسه تغییرها ارزشمندند. شناسه کاربر، متن کامل درخواست و توکن دسترسی چنین وضعیتی ندارند. بعضی از این داده‌ها حساس‌اند و بعضی تعداد ترکیب‌های ممکن را به شدت افزایش می‌دهند. برای هر صفت، سؤال عملی مشخص کنید: آیا برای جدا کردن نسخه خراب لازم است، یا فقط چون در دسترس بوده جمع‌آوری شده است؟ فهرست مجاز صفت‌ها به همراه محدودیت طول مقدار، از ورود تصادفی بدنه‌های بزرگ یا اطلاعات شخصی جلوگیری می‌کند.
در متریک، این موضوع اهمیت ویژه دارد. اگر شماره سفارش به برچسب متریک تبدیل شود، به جای یک روند قابل استفاده مجموعه بزرگی از سری‌های کم‌عمر ساخته می‌شود. برای سنجش خطای پرداخت، گروه خطا و نام سرویس کافی است؛ جزئیات یک سفارش می‌تواند در ردیابی یا رویداد دارای دسترسی محدود بررسی شود. همین تفکیک به تیم اجازه می‌دهد داشبورد عمومی عملیاتی داشته باشد، بدون اینکه دسترسی به اطلاعات مشتری را به تمام مشاهده‌کنندگان آن داشبورد بدهد.
Collector به عنوان نقطه کنترل هزینه و جریان داده
قرار دادن Collector میان برنامه و مقصد، امکان تغییر مقصد یا پردازش مرکزی را فراهم می‌کند، اما این جزء نیز ظرفیت و نقطه شکست دارد. اگر مقصد کند شود، باید بدانیم صف ارسال چه اندازه است و چه زمانی داده حذف می‌شود. زیاد کردن صف بدون توجه به حافظه و دیسک تنها شکل خرابی را تغییر می‌دهد. در آزمایش، مقصد را برای مدتی از دسترس خارج کنید و هم رفتار برنامه و هم میزان داده از دست رفته را اندازه بگیرید. ثبت تله‌متری نباید بی‌دلیل مسیر اصلی پاسخ مشتری را متوقف کند.
نمونه‌برداری نیز انتخاب درباره اطلاعاتی است که نگه می‌داریم. کاهش نرخ نمونه‌برداری می‌تواند هزینه را کم کند، ولی رخداد نادر ممکن است دیده نشود. اگر تصمیم بر اساس نتیجه کامل ردیابی گرفته شود، اجزای لازم باید فرصت دریافت و ارتباط دادن spanها را داشته باشند. برای سرویس کم‌ترافیک، انتخاب متفاوتی نسبت به درگاه پرترافیک منطقی است. این تصمیم را با نرخ خطا و ارزش تشخیصی داده بسنجید، نه فقط با درصدی که در نمونه تنظیمات دیده‌اید.
آزمایش صحت مشاهده‌پذیری
یک درخواست با تأخیر عمدی در سرویس موجودی و یک درخواست با خطای پرداخت بسازید. بررسی کنید آیا نمودار ردیابی محل تأخیر را نشان می‌دهد، متریک خطا افزایش می‌یابد و رویداد ثبت‌شده شناسه همان ردیابی را دارد. سپس یکی از مسیرهای انتقال زمینه را عمداً حذف کنید تا تیم شکل یک ردیابی شکسته را بشناسد. داشتن سه ابزار مجزا کافی نیست؛ ارزش ارتباط داده‌ها زمانی روشن می‌شود که بتوان از هشدار عددی به درخواست نمونه و از آن به علت نزدیک شد.
