برنامههای .NET مدرن در Azure اغلب سیستمهای ساده و تکفرآیندی نیستند. آنها معمولاً شامل چندین سرویس، کارهای پسزمینه، صفهای پیام و وابستگیهای شخص ثالث هستند. هنگامی که مشکلی پیش میآید، تقریباً هرگز در یک مکان وجود ندارد. یک درخواست کند ممکن است از مرورگر شروع شود، از طریق یک API عبور کند، در یک صف منتظر بماند، به یک پایگاه داده ضربه بزند و دقایقی بعد در یک کار پسزمینه شکست بخورد. بدون قابلیت مشاهده، تیمها مجبور به حدس زدن هستند که کدام بخش از این زنجیره خراب شده است.
قابلیت مشاهده به شما این امکان را میدهد که یک درخواست را در حین حرکت در سیستم دنبال کنید و درک کنید چه اتفاقی افتاده است، کجا کند شده است و چرا شکست خورده است. تغییر از SDK وراثت Application Insights به OpenTelemetry (OTel) به طور اساسی نحوه برخورد تیمها با این مشکل را تغییر میدهد. به جای ابزارسازی کد برای یک فروشنده واحد، تیمها اکنون با استفاده از استانداردهای باز ابزارسازی میکنند و بعداً تصمیم میگیرند که این تلهمتری باید به کجا برود. Azure Monitor به عنوان یک مقصد عمل میکند - نه خود ابزارسازی.
Microsoft با پذیرش OpenTelemetry، به واقعیت سیستمهای دنیای واقعی توجه میکند که چندزبانه هستند. یک راه حل واحد ممکن است شامل APIهای .NET، سرویسهای داده مبتنی بر Java، فرانتاند Node.js، کارهای پایتون و سرویسهای مدیریت Azure باشد. نگهداری SDKهای تلهمتری خاص فروشنده برای هر زمان اجرا مقیاسپذیر نیست. OTel یک زبان مشترک برای تلهمتری در تمام این محیطها فراهم میکند.
مشاهده مطلب اصلی