تعليمات القياس المفتوح والدعم والملاحظات

توفر هذه المقالة خيارات التعليمات والدعم والملاحظات ل OpenTelemetry على Azure Monitor Application Insights لتطبيقات .NET وJava Node.js وPython.

• مراجعة الأسئلة المتداولة
• اتخاذ خطوات استكشاف الأخطاء وإصلاحها
• الحصول على الدعم
• تقديم الملاحظات

الأسئلة الشائعة

ما هو OpenTelemetry؟

إنه معيار مفتوح المصدر جديد لقابلية الملاحظة. تعرف على المزيد في OpenTelemetry.

لماذا تستثمر Microsoft Azure Monitor في OpenTelemetry؟

تستثمر Microsoft في OpenTelemetry للأسباب التالية:

• إنه محايد للمورد ويوفر واجهات برمجة تطبيقات/SDKs متسقة عبر اللغات.
• مع مرور الوقت، نعتقد أن OpenTelemetry سيمكن عملاء Azure Monitor من مراقبة التطبيقات المكتوبة بلغات تتجاوز لغاتنا المدعومة.
• فهو يوسع أنواع البيانات التي يمكنك جمعها من خلال مجموعة غنية من مكتبات الأجهزة.
• تميل مجموعات تطوير برامج OpenTelemetry (SDKs) إلى أن تكون أكثر أداء على نطاق واسع من أسلافها، وهي Application Insights SDKs.
• يتوافق OpenTelemetry مع استراتيجية Microsoft لتبني مصدر مفتوح.

ما هي حالة OpenTelemetry؟

راجع حالة OpenTelemetry.

ما هو Azure Monitor OpenTelemetry Distro؟

يمكنك التفكير في الأمر على أنه برنامج تضمين رفيع يجمع معا جميع مكونات OpenTelemetry للحصول على تجربة من الدرجة الأولى على Azure. يسمى هذا التضمين أيضا التوزيع في OpenTelemetry.

لماذا يجب استخدام Azure Monitor OpenTelemetry Distro؟

هناك العديد من المزايا لاستخدام Azure Monitor OpenTelemetry Distro على OpenTelemetry الأصلي من المجتمع:

• تقليل جهد التمكين
• مدعوم من قبل Microsoft
• يجلب ميزات خاصة ب Azure مثل:
  • أخذ العينات المتوافق مع Application Insights SDKs الكلاسيكي
  • مصادقة Microsoft Entra
  • التخزين غير المتصل وإعادة المحاولة التلقائية
  • Statsbeat
  • مقاييس Application Insights القياسية
  • الكشف عن بيانات تعريف المورد لملء اسم دور السحابة ومثيل دور السحابة تلقائيا في بيئات Azure المختلفة
  • القياسات المباشرة

بروح OpenTelemetry، صممنا توزيعة لتكون مفتوحة وقابلة للتوسعة. على سبيل المثال، يمكنك إضافة:

• مصدر بروتوكول القياس المفتوح (OTLP) وإرساله إلى وجهة ثانية في وقت واحد
• مكتبات الأجهزة الأخرى غير المضمنة في توزيعة الأجهزة

نظرا لأن Distro يوفر توزيع OpenTelemetry، يدعم Distro أي شيء يدعمه OpenTelemetry. على سبيل المثال، يمكنك إضافة المزيد من معالجات بيانات تتبع الاستخدام أو المصدرين أو مكتبات الأجهزة، إذا كان OpenTelemetry يدعمها.

إشعار

يقوم Distro بتعيين العينة إلى عينة مخصصة ذات معدل ثابت ل Application Insights. يمكنك تغيير هذا إلى عينة مختلفة، ولكن القيام بذلك قد يعطل بعض القدرات المضمنة في Distro. لمزيد من المعلومات حول أداة أخذ العينات المدعومة، راجع قسم تمكين أخذ العينات في تكوين القياس المفتوح ل Azure Monitor.

بالنسبة للغات التي لا تحتوي على مصدر OpenTelemetry مستقل معتمد، فإن Azure Monitor OpenTelemetry Distro هو الطريقة الوحيدة المدعومة حاليا لاستخدام OpenTelemetry مع Azure Monitor. بالنسبة للغات التي لديها مصدر OpenTelemetry مستقل معتمد، لديك خيار استخدام إما Azure Monitor OpenTelemetry Distro أو مصدر OpenTelemetry المستقل المناسب اعتمادا على سيناريو القياس عن بعد. لمزيد من المعلومات، راجع متى يجب استخدام مصدر Azure Monitor OpenTelemetry؟.

كيف يمكنني اختبار Azure Monitor OpenTelemetry Distro؟

تحقق من مستندات التمكين الخاصة بنا ل .NET وJava وJavaScript (Node.js) وPython.

هل يجب استخدام OpenTelemetry أو Application Insights SDK؟

نوصي باستخدام OpenTelemetry Distro ما لم تكن بحاجة إلى ميزة متوفرة فقط مع الدعم الرسمي في Application Insights SDK.

يؤدي اعتماد OpenTelemetry الآن إلى منع الاضطرار إلى الترحيل في وقت لاحق.

متى يجب استخدام مصدر Azure Monitor OpenTelemetry؟

بالنسبة إلى ASP.NET Core وJava Node.js وPython، نوصي باستخدام Azure Monitor OpenTelemetry Distro. إنه سطر واحد من التعليمات البرمجية للبدء.

بالنسبة لجميع سيناريوهات .NET الأخرى، بما في ذلك ASP.NET الكلاسيكية وتطبيقات وحدة التحكم وWindows Forms (WinForms) وما إلى ذلك، نوصي باستخدام مصدر .NET Azure Monitor OpenTelemetry: Azure.Monitor.OpenTelemetry.Exporter.

بالنسبة لسيناريوهات بيانات تتبع الاستخدام Python الأكثر تعقيدا التي تتطلب تكوينا متقدما، نوصي باستخدام مصدر بيانات تتبع الاستخدام المفتوح ل Python Azure Monitor.

ما هي حالة الإصدار الحالية للميزات داخل Azure Monitor OpenTelemetry Distro؟

يقسم المخطط التالي دعم ميزة OpenTelemetry لكل لغة.

ميزة	.NET	Node.js	Python	Java
التتبع الموزع	✅	✅	✅	✅
مقاييس مخصصة	✅	✅	✅	✅
المقاييس القياسية	✅	✅	✅	✅
أخذ العينات بمعدل ثابت	✅	✅	✅	✅
التخزين دون اتصال وإعادة المحاولة التلقائية	✅	✅	✅	✅
الإبلاغ عن الاستثناء	✅	✅	✅	✅
مجموعة السجلات	✅	⚠️	✅	✅
أحداث مخصصة	⚠️	⚠️	⚠️	✅
مصادقة Microsoft Entra	✅	✅	✅	✅
المقاييس المباشرة	✅	✅	✅	✅
تصفية المقاييس المباشرة	✅	❌	❌	❌
الكشف عن سياق الموارد ل VM/VMSS وخدمة التطبيقات	✅	❌	✅	✅
الكشف عن سياق الموارد لخدمة Azure Kubernetes (AKS) والوظائف	❌	❌	❌	✅
أحداث اختبار التوفر التي تم إنشاؤها باستخدام واجهة برمجة تطبيقات تتبع التوفر	❌	❌	❌	✅
تصفية الطلبات والتبعيات والسجلات والاستثناءات حسب معرف المستخدم المجهول والمصدر الاصطناعي	❌	❌	❌	✅
تصفية التبعيات والسجلات والاستثناءات حسب اسم العملية	❌	❌	❌	✅
أخذ العينات التكيفية	❌	❌	❌	✅
منشئ ملفات التعريف	❌	❌	❌	⚠️
Snapshot Debugger	❌	❌	❌	❌

المفتاح

• ✅ تتوفر هذه الميزة لجميع العملاء الذين لديهم دعم رسمي.
• ⚠️ تتوفر هذه الميزة كمعاينة عامة. راجع شروط الاستخدام التكميلية لمعاينات Microsoft Azure.
• ❌ هذه الميزة غير متوفرة أو غير قابلة للتطبيق.

هل يمكن استخدام OpenTelemetry لمستعرضات الويب؟

نعم، لكننا لا نوصي به ولا يدعمه Azure. تم تحسين OpenTelemetry JavaScript بشكل كبير Node.js. بدلا من ذلك، نوصي باستخدام Application Insights JavaScript SDK.

متى يمكننا توقع توفر OpenTelemetry SDK للاستخدام في مستعرضات الويب؟

لا يحتوي OpenTelemetry web SDK على مخطط زمني محدد للتوفر. من المحتمل أن نكون على بعد عدة سنوات من متصفح SDK الذي يعد بديلا قابلا للتطبيق Insights JavaScript SDK.

هل يمكنني اختبار OpenTelemetry في مستعرض ويب اليوم؟

تعد بيئة الاختبار المعزولة للويب OpenTelemetry نسخة المستودع المصممة لجعل OpenTelemetry تعمل في مستعرض. لا يمكن بعد إرسال بيانات تتبع الاستخدام إلى Application Insights. لا تحدد SDK أحداث العميل العامة.

هل يتم دعم تشغيل Application Insights جنبا إلى جنب مع وكلاء منافسين مثل AppDynamics وDataDog و NewRelic؟

هذه الممارسة ليست شيئا نخطط لاختباره أو دعمه، على الرغم من أن Distros الخاصة بنا تسمح لك بالتصدير إلى نقطة نهاية OTLP جنبا إلى جنب مع Azure Monitor في وقت واحد.

هل يمكنني استخدام ميزات المعاينة في بيئات الإنتاج؟

لا نوصي بذلك. راجع شروط الاستخدام التكميلية لمعاينات Microsoft Azure.

ما الفرق بين الأجهزة اليدوية والتلقائية؟

راجع نظرة عامة على OpenTelemetry.

هل يمكنني استخدام OpenTelemetry Collector؟

يستخدم بعض العملاء OpenTelemetry Collector كبديل للعامل، على الرغم من أن Microsoft لا تدعم رسميا نهجا يستند إلى عامل لمراقبة التطبيق حتى الآن. في هذه الأثناء، ساهم مجتمع المصدر المفتوح بمصدر OpenTelemetry Collector Azure Monitor الذي يستخدمه بعض العملاء لإرسال البيانات إلى Azure Monitor Application Insights. هذا غير معتمد من قبل Microsoft.

ما الفرق بين OpenCensus وOpenTelemetry؟

OpenCensus هو مقدمة OpenTelemetry. ساعدت Microsoft في الجمع بين OpenTracing وOpenCensus لإنشاء OpenTelemetry، وهو معيار واحد للمراقبة للعالم. تستند Python SDK الحالية الموصى بها للإنتاج ل Azure Monitor إلى OpenCensus. تلتزم Microsoft بإجراء Azure Monitor استنادا إلى OpenTelemetry.

في Grafana، لماذا أرى Status: 500. Can't visualize trace events using the trace visualizer؟

قد تحاول تصور سجلات النص الخام بدلا من تتبعات OpenTelemetry.

في Application Insights، يخزن جدول "Traces" سجلات النصوص الأولية لأغراض التشخيص. وهي تساعد في تحديد التتبعات المرتبطة بطلبات المستخدم والأحداث الأخرى وتقارير الاستثناءات وربطها. ومع ذلك، لا يساهم جدول "التتبعات" مباشرة في عرض المعاملة الشاملة (المخطط الانحداري) في أدوات التصور مثل Grafana.

مع الاعتماد المتزايد للممارسات السحابية الأصلية، هناك تطور في جمع المصطلحات وبيانات تتبع الاستخدام. أصبح OpenTelemetry معيارا لجمع بيانات تتبع الاستخدام ووضع الأجهزة لها. في هذا السياق، اتخذ مصطلح "التتبعات" معنى جديدا. بدلا من السجلات الأولية، تشير "التتبعات" في OpenTelemetry إلى شكل أغنى ومنظم لبيانات تتبع الاستخدام يتضمن امتدادات، والتي تمثل وحدات عمل فردية. هذه الامتدادات ضرورية لإنشاء طرق عرض مفصلة للمعاملات، ما يتيح مراقبة وتشخيص أفضل للتطبيقات الأصلية على السحابة.

استكشاف الأخطاء وإصلاحها

ASP.NET Core

الخطوة 1: تمكين التسجيل التشخيصي

يستخدم مصدر Azure Monitor EventSource لتسجيل الدخول الداخلي الخاص به. تتوفر سجلات المصدر لأي EventListener عن طريق الاشتراك في المصدر المسمى OpenTelemetry-AzureMonitor-Exporter. للحصول على خطوات استكشاف الأخطاء وإصلاحها، راجع استكشاف أخطاء OpenTelemetry وإصلاحها على GitHub.

الخطوة 2: اختبار الاتصال بين مضيف التطبيق وخدمة الاستيعاب

ترسل مجموعات تطوير برامج Application Insights (SDKs) والوكلاء بيانات تتبع الاستخدام للحصول على استيعابها كمكالمات REST في نقاط نهاية الاستيعاب لدينا. لاختبار الاتصال من خادم الويب أو الكمبيوتر المضيف للتطبيق إلى نقاط نهاية خدمة الاستيعاب، استخدم أوامر cURL أو طلبات REST الأولية من PowerShell. لمزيد من المعلومات، راجع استكشاف أخطاء بيانات تتبع استخدام التطبيق المفقودة وإصلاحها في Azure Monitor Application Insights.

المشكلات المعروفة

العناصر التالية هي مشكلات معروفة لمصدري القياس المفتوح ل Azure Monitor:

• اسم العملية مفقود من القياس عن بعد للتبعية. يتسبب اسم العملية المفقود في حدوث حالات فشل ويؤثر سلبا على تجربة علامة تبويب الأداء.

• نموذج الجهاز مفقود من بيانات تتبع الاستخدام للطلب والتبعية. يؤثر نموذج الجهاز المفقود سلبا على تحليل مجموعة الأجهزة.

NET.

الخطوة 1: تمكين التسجيل التشخيصي

يستخدم مصدر Azure Monitor EventSource لتسجيل الدخول الداخلي الخاص به. تتوفر سجلات المصدر لأي EventListener عن طريق الاشتراك في المصدر المسمى OpenTelemetry-AzureMonitor-Exporter. للحصول على خطوات استكشاف الأخطاء وإصلاحها، راجع استكشاف أخطاء OpenTelemetry وإصلاحها على GitHub.

الخطوة 2: اختبار الاتصال بين مضيف التطبيق وخدمة الاستيعاب

ترسل Application Insights SDKs والوكلاء بيانات تتبع الاستخدام للحصول على استيعابها كمكالمات REST في نقاط نهاية الاستيعاب لدينا. لاختبار الاتصال من خادم الويب أو الكمبيوتر المضيف للتطبيق إلى نقاط نهاية خدمة الاستيعاب، استخدم أوامر cURL أو طلبات REST الأولية من PowerShell. لمزيد من المعلومات، راجع استكشاف أخطاء بيانات تتبع استخدام التطبيق المفقودة وإصلاحها في Azure Monitor Application Insights.

المشكلات المعروفة

العناصر التالية هي مشكلات معروفة لمصدري القياس المفتوح ل Azure Monitor:

• اسم العملية مفقود من القياس عن بعد للتبعية. يتسبب اسم العملية المفقود في حدوث حالات فشل ويؤثر سلبا على تجربة علامة تبويب الأداء.

• نموذج الجهاز مفقود من بيانات تتبع الاستخدام للطلب والتبعية. يؤثر نموذج الجهاز المفقود سلبا على تحليل مجموعة الأجهزة.

Java

الخطوة 1: تمكين التسجيل التشخيصي

بشكل افتراضي، يتم تمكين التسجيل التشخيصي في Azure Monitor Application Insights. لمزيد من المعلومات، راجع دليل استكشاف الأخطاء وإصلاحها: Azure Monitor Application Insights ل Java.

الخطوة 2: اختبار الاتصال بين مضيف التطبيق وخدمة الاستيعاب

ترسل Application Insights SDKs والوكلاء بيانات تتبع الاستخدام للحصول على استيعابها كمكالمات REST في نقاط نهاية الاستيعاب لدينا. لاختبار الاتصال من خادم الويب أو الكمبيوتر المضيف للتطبيق إلى نقاط نهاية خدمة الاستيعاب، استخدم أوامر cURL أو طلبات REST الأولية من PowerShell. لمزيد من المعلومات، راجع استكشاف أخطاء بيانات تتبع استخدام التطبيق المفقودة وإصلاحها في Azure Monitor Application Insights.

المشكلات المعروفة

• إذا قمت بتنزيل مكتبة عميل Application Insights للتثبيت من مستعرض، في بعض الأحيان يكون ملف JAR الذي تم تنزيله تالفة وهو حوالي نصف حجم الملف المصدر. إذا واجهت هذه المشكلة، فبادر بتنزيل ملف JAR عن طريق تشغيل الأمر curl أو wget ، كما هو موضح في مثال استدعاءات الأوامر التالية:

  curl --location --output applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
  

  wget --output-document=applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
  

  إشعار

  ينطبق مثال استدعاءات الأمر على Application Insights ل Java الإصدار 3.4.11. للعثور على رقم الإصدار وعنوان URL للإصدار الحالي من Application Insights ل Java، راجع https://github.com/microsoft/ApplicationInsights-Java/releases.

Java الأصلي

تنطبق الخطوات التالية على تطبيقات Spring Boot الأصلية.

الخطوة 1: تحقق من إصدار OpenTelemetry

قد تلاحظ الرسالة التالية أثناء بدء تشغيل التطبيق:

WARN  c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>

في هذه الحالة، يجب عليك استيراد فواتير المواد OpenTelemetry باتباع وثائق OpenTelemetry في بداية Spring Boot.

الخطوة 2: تمكين التشخيص الذاتي

إذا لم يعمل شيء ما كما هو متوقع، يمكنك تمكين التشخيص الذاتي على DEBUG المستوى للحصول على بعض الرؤى. للقيام بذلك، قم بتعيين مستوى التشخيص الذاتي إلى ERRORأو DEBUGTRACE WARNINFOباستخدام APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL متغير البيئة.

لتمكين التشخيص الذاتي على DEBUG المستوى عند تشغيل حاوية docker، قم بتشغيل الأمر التالي:

docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>

إشعار

استبدل <image-name> باسم صورة docker وفقا لذلك.

إخلاء المسؤولية عن معلومات الجهات الخارجية

لا تقدم Microsoft أي ضمان، ضمني أو غير ذلك، حول أداء أو موثوقية منتجات الجهات الخارجية المستقلة هذه.

Node.js

الخطوة 1: تمكين التسجيل التشخيصي

يستخدم مصدر Azure Monitor مسجل OpenTelemetry API للسجلات الداخلية. لتمكين المسجل، قم بتشغيل القصاصة البرمجية التالية:

const { diag, DiagConsoleLogger, DiagLogLevel } = require("@opentelemetry/api");
const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");

const provider = new NodeTracerProvider();
diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ALL);
provider.register();

الخطوة 2: اختبار الاتصال بين مضيف التطبيق وخدمة الاستيعاب

ترسل Application Insights SDKs والوكلاء بيانات تتبع الاستخدام للحصول على استيعابها كمكالمات REST في نقاط نهاية الاستيعاب لدينا. لاختبار الاتصال من خادم الويب أو الكمبيوتر المضيف للتطبيق إلى نقاط نهاية خدمة الاستيعاب، استخدم أوامر cURL أو طلبات REST الأولية من PowerShell. لمزيد من المعلومات، راجع استكشاف أخطاء بيانات تتبع استخدام التطبيق المفقودة وإصلاحها في Azure Monitor Application Insights.

المشكلات المعروفة

العناصر التالية هي مشكلات معروفة لمصدري القياس المفتوح ل Azure Monitor:

• اسم العملية مفقود من القياس عن بعد للتبعية. يتسبب اسم العملية المفقود في حدوث حالات فشل ويؤثر سلبا على تجربة علامة تبويب الأداء.

• نموذج الجهاز مفقود من بيانات تتبع الاستخدام للطلب والتبعية. يؤثر نموذج الجهاز المفقود سلبا على تحليل مجموعة الأجهزة.

• اسم خادم قاعدة البيانات مفقود من اسم التبعية. نظرا لعدم تضمين اسم خادم قاعدة البيانات، يقوم مصدرو OpenTelemetry بتجميع الجداول التي لها نفس الاسم بشكل غير صحيح على خوادم مختلفة.

Python

تمكين التسجيل التشخيصي

يستخدم مصدر مراقبة Microsoft Azure مكتبة تسجيل Python القياسية للتسجيل الداخلي الخاص به. يتم تعيين OpenTelemetry API وسجلات مصدر Azure Monitor مستوى WARNING خطورة أو ERROR للنشاط غير المنتظم. INFO يتم استخدام مستوى الخطورة للنشاط العادي أو الناجح.

بشكل افتراضي، تعين مكتبة تسجيل Python مستوى الخطورة إلى WARNING. لذلك، يجب تغيير مستوى الخطورة لمشاهدة السجلات ضمن إعداد الخطورة هذا. يوضح مثال التعليمات البرمجية التالي كيفية إخراج سجلات من جميع مستويات الخطورة إلى وحدة التحكم وملف:

...
import logging

logging.basicConfig(format = "%(asctime)s:%(levelname)s:%(message)s", level = logging.DEBUG)

logger = logging.getLogger(__name__)
file = logging.FileHandler("example.log")
stream = logging.StreamHandler()
logger.addHandler(file)
logger.addHandler(stream)
...

اختبار الاتصال بين مضيف التطبيق وخدمة الاستيعاب

ترسل Application Insights SDKs والوكلاء بيانات تتبع الاستخدام للحصول على استيعابها كمكالمات REST في نقاط نهاية الاستيعاب لدينا. لاختبار الاتصال من خادم الويب أو الكمبيوتر المضيف للتطبيق إلى نقاط نهاية خدمة الاستيعاب، استخدم أوامر cURL أو طلبات REST الأولية من PowerShell. لمزيد من المعلومات، راجع استكشاف أخطاء بيانات تتبع استخدام التطبيق المفقودة وإصلاحها في Azure Monitor Application Insights.

تجنب بيانات تتبع الاستخدام المكررة

غالبا ما يحدث تكرار القياس عن بعد إذا قمت بإنشاء مثيلات متعددة من المعالجات أو المصدرين. تأكد من تشغيل مصدر ومعالج واحد فقط في كل مرة لكل عمود بيانات تتبع الاستخدام (السجلات والمقاييس والتتبع الموزع).

تصف الأقسام التالية السيناريوهات التي يمكن أن تسبب بيانات تتبع الاستخدام المكررة.

سجلات التتبع المكررة في Azure Functions

إذا رأيت زوجا من الإدخالات لكل سجل تتبع داخل Application Insights، فربما قمت بتمكين الأنواع التالية من أدوات التسجيل:

• أدوات التسجيل الأصلية في Azure Functions
• azure-monitor-opentelemetry أدوات التسجيل داخل التوزيع

لمنع التكرار، يمكنك تعطيل تسجيل التوزيع، ولكن اترك أدوات التسجيل الأصلية في Azure Functions ممكنة. لتحقيق هذا الهدف، قم بتعيين OTEL_LOGS_EXPORTER متغير البيئة إلى None.

بيانات تتبع الاستخدام المكررة في وظائف Azure "Always On"

إذا تم تعيين الإعداد Always On في Azure Functions إلى On، فإن Azure Functions تحتفظ ببعض العمليات قيد التشغيل في الخلفية بعد اكتمال كل تشغيل. على سبيل المثال، افترض أن لديك دالة مؤقت مدتها خمس دقائق تستدعي configure_azure_monitor في كل مرة. بعد 20 دقيقة، قد يكون لديك أربعة مصدرين متريين يعملون في نفس الوقت. قد يكون هذا الموقف مصدر القياس عن بعد للمقاييس المكررة.

في هذه الحالة، قم إما بتعيين الإعداد Always On إلى Off، أو حاول إيقاف تشغيل الموفرين يدويا بين كل configure_azure_monitor مكالمة. لإيقاف تشغيل كل موفر، قم بتشغيل استدعاءات إيقاف التشغيل لكل مقياس وتتبع وموفر مسجل حالي، كما هو موضح في التعليمات البرمجية التالية:

get_meter_provider().shutdown()
get_tracer_provider().shutdown()
get_logger_provider().shutdown()

مصنفات Azure ودفاتر ملاحظات Jupyter

قد تحافظ مصنفات Azure ودفاتر ملاحظات Jupyter على تشغيل عمليات المصدر في الخلفية. لمنع بيانات تتبع الاستخدام المكررة، قم بإلغاء تحديد ذاكرة التخزين المؤقت قبل إجراء المزيد من الاستدعاءات إلى configure_azure_monitor.

بيانات تتبع الاستخدام للطلبات المفقودة من تطبيقات FastAPI أو Flask

إذا كنت تفتقد بيانات جدول الطلبات ولكن ليس فئات أخرى، فمن المحتمل أن إطار عمل http الخاص بك لا يتم وضع علامة عليه. يمكن أن يحدث هذا في تطبيقات FastAPI وFlask باستخدام مكتبة عميل Azure Monitor OpenTelemetry Distro ل Python إذا لم تقم ببناء إعلاناتك import بشكل صحيح. قد تقوم باستيراد fastapi.FastAPI أو flask.Flask على التوالي قبل استدعاء الدالة configure_azure_monitor لوضع علامة على مكتبات FastAPI وFlask. على سبيل المثال، لا تنجح التعليمات البرمجية التالية في استخدام تطبيقي FastAPI وFlask:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor
from fastapi import FastAPI

configure_azure_monitor()

app = FastAPI()

# Flask

from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask

configure_azure_monitor()

app = Flask(__name__)

بدلا من ذلك، نوصي باستيراد الوحدات النمطية fastapi أو flask ككل، ثم استدعاء configure_azure_monitor لتكوين OpenTelemetry لاستخدام Azure Monitor قبل الوصول إلى fastapi.FastAPI أو flask.Flask:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor
import fastapi

configure_azure_monitor()

app = fastapi.FastAPI(__name__)

# Flask

from azure.monitor.opentelemetry import configure_azure_monitor
import flask

configure_azure_monitor()

app = flask.Flask(__name__)

بدلا من ذلك، يمكنك الاتصال configure_azure_monitor قبل الاستيراد fastapi.FastAPI أو flask.Flask:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor

configure_azure_monitor()

from fastapi import FastAPI

app = FastAPI(__name__)

# Flask

from azure.monitor.opentelemetry import configure_azure_monitor

configure_azure_monitor()

from flask import Flask

app = Flask(__name__)

يدعم

حدد علامة تبويب للغة التي تختارها لاكتشاف خيارات الدعم.

ASP.NET Core

• بالنسبة إلى مشكلات دعم Azure، افتح تذكرة دعم Azure.
• بالنسبة إلى مشكلات القياس عن بُعد المفتوح، اتصل بمجتمع القياس عن بُعد المفتوح مباشرة.
• للحصول على قائمة بالمشكلات المفتوحة المتعلقة بمصدر Azure Monitor، راجع صفحة مشكلات GitHub.

NET.

• بالنسبة إلى مشكلات دعم Azure، افتح تذكرة دعم Azure.
• بالنسبة إلى مشكلات القياس عن بُعد المفتوح، اتصل بمجتمع القياس عن بُعد المفتوح مباشرة.
• للحصول على قائمة بالمشكلات المفتوحة المتعلقة بمصدر Azure Monitor، راجع صفحة مشكلات GitHub.

Java

• بالنسبة إلى مشكلات دعم Azure، افتح تذكرة دعم Azure.
• للحصول على تعليمات حول استكشاف الأخطاء وإصلاحها، راجع خطوات استكشاف الأخطاء وإصلاحها.
• بالنسبة إلى مشكلات القياس عن بُعد المفتوح، اتصل بمجتمع القياس عن بُعد المفتوح مباشرة.
• للحصول على قائمة بالمشكلات المفتوحة المتعلقة ب Azure Monitor Java Autoinstrumentation، راجع صفحة مشكلات GitHub.

Java الأصلي

• بالنسبة إلى مشكلات دعم Azure، افتح تذكرة دعم Azure.
• بالنسبة إلى مشكلات القياس عن بُعد المفتوح، اتصل بمجتمع القياس عن بُعد المفتوح مباشرة.
• للحصول على قائمة بالمشكلات المفتوحة مع تطبيقات Spring Boot الأصلية، راجع صفحة مشكلات GitHub.
• للحصول على قائمة بالمشكلات المفتوحة مع تطبيقات Quarkus الأصلية، راجع صفحة مشكلات GitHub.

Node.js

• بالنسبة إلى مشكلات دعم Azure، افتح تذكرة دعم Azure.
• بالنسبة إلى مشكلات القياس عن بُعد المفتوح، اتصل بمجتمع القياس عن بُعد المفتوح مباشرة.
• للحصول على قائمة بالمشكلات المفتوحة المتعلقة بمصدر Azure Monitor، راجع صفحة مشكلات GitHub.

Python

• بالنسبة إلى مشكلات دعم Azure، افتح تذكرة دعم Azure.
• بالنسبة إلى مشكلات القياس عن بُعد المفتوح، اتصل بمجتمع القياس عن بُعد المفتوح مباشرة.
• للحصول على قائمة بالمشكلات المفتوحة المتعلقة ب Azure Monitor Distro، راجع صفحة مشكلات GitHub.

ملاحظات OpenTelemetry

لتقديم التعليقات:

• املأ استطلاع آراء العملاءفي مجتمع القياس عن بُعد المفتوح.
• أخبر Microsoft قليلاً عن نفسك من خلال الانضمام إلى مجتمع المستخدم المبكر للتطبيقات لـ OpenTelemetry.
• التفاعل مع مستخدمي Azure Monitor الآخرين في Microsoft Tech Community.
• قدم طلب ميزة في منتدى ملاحظات Azure.