spring boot opentelemetry

حماية الربيع أوبنت

المقاييس

يوفر SPRING BOOT Actuator إدارة التبعية وتكوين تلقائي للميكرومتر ، والذي يوفر واجهة مريحة على العديد من أنظمة المراقبة المختلفة. واحد منهم هو قياس الأوبنتيل.

يمكن لمطوري SPRING BOOT تمكين تطبيقاتهم من مقاييس التصدير عبر بروتوكول OTLP إلى الواجهة الخلفية لقياس الأوبنتيل عن طريق إضافة مشغل التمهيد الربيعي والاعتماد المخصص لقياس الأوبنتر من ميكرومتر إلى مشاريعهم.

dependencies {
    implementation ' org.springframework.boot:spring-boot-starter-actuator '
    runtimeOnly ' io.micrometer:micrometer-registry-otlp '
    .. .
}

يعد المصدر الذي يوفره سجل Microlder OTLP مصدرًا لـ HTTP ويمكن تكوينه عبر الخصائص بفضل التكوين التلقائي لقياس الأوبنتيل.

 management :
  otlp :
    metrics :
      export :
        url : http://localhost:4318/v1/metrics
        step : 5s

يدعم OpentEleMetry أزواج مفتاح/قيمة إضافية (تسمى resource attributes ) ليتم تضمينها في بيانات القياس عن بعد. يوفر مشغل Boot Spring تكوين تلقائي لهؤلاء ويجعل من الممكن إضافة سمات موارد جديدة عبر الخصائص.

 management :
  opentelemetry :
    resource-attributes :
      cluster : local
      " service.name " : ${spring.application.name}

لقد قدمت تطبيقًا تجريبيًا لعرض هذا الإعداد.

المشكلة: لا يمكن تكوين مصدر مقاييس OTLP عبر قياس الأوبنتيل

تستخدم وحدة سجل Microlder OTLP عميل HTTP متوافق مع OTLP لتصدير المقاييس إلى الواجهة الخلفية لقياس الأوبنتيل. داخليًا ، يستخدم OtlpMeterRegistry كائن HttpSender خاص لتكوين عميل HTTP. تتمثل فائدة هذا النهج في أن الوحدة خفيفة الوزن ولا تحتاج إلى أي اعتماد على SDK القياس. لا يستخدم سوى مكتبة io.opentelemetry.proto التي توفر تكوين protobuf لقياس الأوبنتيل.

من ناحية أخرى ، فإن مثل هذا النهج يعني:

• لا يمكن تكوين مصدر المقاييس عبر تكوين القياس القياسي للسمات الأوبنتيل ؛
• لا يمكن تكوين الضغط ؛
• لا يمكن مشاركة تكوين قياس الأوبنتيل في الحذاء الربيعي بين المقاييس والآثار.

تشييد OpenTelemetryAutoConfiguration في الربيع 3.2 تلقائيات تلقائية من فول OpenTelemetry ويجعل من الممكن تكوين حبة SdkMeterProvider . ماذا لو كان بإمكان ميكرومتر استخدام ذلك لإعداد مصدر مقاييس أوبنتميتر؟

الحلول الممكنة:

• قم بتحديث وحدة سجل Microlder الحالية OTLP لتنفيذ MeterRegistry التي تقبل كائن OpenTelemetry للتكوين (على غرار OpenTelemetryMeterRegistry المستخدمة من قبل مكتبة أدوات OpentEleMetry Java). إذا كان التوافق المتخلف ضروريًا ، فسوف يحتاج التنفيذ الجديد إلى التعايش مع السلط الحالي (ربما يمكن أن يتحول علامة الميزة بين الاثنين؟) ؛
• قم بإنشاء وحدة قياس OpentEleMetry الجديدة لتنفيذ ما هو موضح في النقطة السابقة ، ولكن دون وجود مشكلات مع التوافق المتخلف.

لقد قمت بتقديم مشكلة إلى مشروع Micrometer وشاركت هذه الاقتراحات. إن بناء (أو تحديث) من شأن هذه الوحدة أن يجعل من الممكن إعادة استخدام نفس OpenTelemetryAutoConfiguration التي تم تقديمها في SPRING BOOT 3.2 لكل من المقاييس والآثار (وفي المستقبل ، للسجلات أيضًا).

• توجد مشكلة بالفعل في مشروع Boot Spring لإجراء تكوين تلقائي على حبة SdkMeterProvider ، وبشكل عام ، لاستخدام المقاييس مع قياس الأوبنتيل. لكننا نفتقد دعم الميكرومتر قبل ذلك.
• من الممكن أيضًا تبديل تطبيق العميل بين HTTP و GRPC باستخدام نهج قياس الأوبنتيل القياسي (أي تكوين إما OtlpHttpMetricExporter أو OtlpGrpcMetricExporter ).
• أخيرًا ، سيجعل الأمر أسهل للمطورين الذين يستخدمون ميكرومتر في التطبيقات مع عامل Java OpenTelemetry أو بشكل عام ، أجهزة قياس الأوبنتيلميتر Java. تحافظ هذه المشاريع حاليًا على Shim بين الميكرومتر وقياس الأوبنتيل. ربما لم تعد هناك حاجة إلى شيم. لذلك ، فإن مثل هذا التغيير من شأنه أن يقلل أيضًا من عبء العمل على الحفاظ على أجهزة قياس الأوبنتيلومتر Java متوافق مع الميكرومتر.

لمزيد من السياق حول التحديات الحالية ، راجع هذه المشكلة في مشروع Boot Spring.

آثار

يوفر SPRING BOOT Actuator إدارة التبعية وتكوين تلقائي لتتبع الميكرومتر ، والذي يوفر واجهة مريحة على عدد قليل من الخلفية المتطرفة الموزعة المختلفة. واحد منهم هو قياس الأوبنتيل.

يمكن لمطوري Boot Spring تمكين تطبيقاتهم من آثار التصدير عبر بروتوكول OTLP إلى الواجهة الخلفية لقياس الأوبنتيل عن طريق إضافة مشغل التمهيد الربيعي ، وتتبع الميكرومتر والاعتماد على قياس الأوبنتيل من الميكرومتر إلى مشاريعها.

dependencies {
    implementation ' org.springframework.boot:spring-boot-starter-actuator '
    implementation ' io.micrometer:micrometer-tracing-bridge-otel '
    implementation ' io.opentelemetry:opentelemetry-exporter-otlp '
    .. .
}

إن المصدر الذي يوفره تلقائي AutoConfiguration AutoConfiguration هو مصدر HTTP (حبة OtlpHttpSpanExporter ) ويمكن تكوينها عبر خصائص بفضل تكوين التتبع في تكوين OtlpAutoConfiguration .

 management :
  otlp :
    tracing :
      endpoint : http://localhost:4318/v1/traces

يدعم OpentEleMetry أزواج مفتاح/قيمة إضافية (تسمى resource attributes ) ليتم تضمينها في بيانات القياس عن بعد. يوفر مشغل Boot Spring تكوين تلقائي لهؤلاء ويجعل من الممكن إضافة سمات موارد جديدة عبر الخصائص. يتم تكوين سمة موارد service.name القياسية. Name تلقائيًا إلى قيمة spring.application.name (إذا تم تعريفها) أو إلى قيمة application افتراضية.

 management :
  opentelemetry :
    resource-attributes :
      cluster : local

لقد قدمت تطبيقًا تجريبيًا لعرض هذا الإعداد.

إصدار تصدير آثار عبر GRPC

في هذه المسألة في مشروع Boot Spring ، تمت إضافة تلقائي للحبوب OtlpHttpSpanExporter إلى آثار التصدير عبر HTTP.

من المتطلبات الشائعة تصدير آثار عبر GRPC (النهج الأكثر استخدامًا في قياس الأوبنتيل). في الوقت الحالي ، يمكن للمطورين تكوين BEAN OtlpGrpcSpanExporter بأنفسهم. سيكون من الرائع أن يوفر مشغل التمهيد الربيعي التكوين التلقائي لذلك ، مما يعزز OtlpAutoConfiguration الحالي.

هناك بالفعل مشكلة في مشروع SPRING BOOT لإضافة هذا التكوين التلقائي.

ملخص

بشكل عام ، هذه هي القضايا والاقتراحات التي وصفتها حتى الآن.

الحد الأدنى من التغييرات المقترحة لتوحيد دعم قياس الأوبنتيل في الربيع للمقاييس والآثار

ميكرومتر

• تقديم تطبيق MeterRegistry مبني على أعلى قياس الأوبنتيل وقابل للتكوين من خلال أساليبه القياسية ، بحيث يمكن مشاركة التكوين بين المقاييس والآثار.

مشغل التمهيد الربيع

• إدخال التكوين التلقائي لمقاييس قياس الأوبنتيل. يمكن إعادة استخدام OpenTelemetry Resource من تكوين قياس الأوبنتيل. إلى جانب ذلك ، يجب أن تحدد التكوين التلقائي الإعدادات الافتراضية لـ SdkMeterProvider و OtlpHttpMetricExporter و OtlpGrpcMetricExporter .
• إدخال التكوين التلقائي لتصدير آثار قياس الأوبنتيل عبر GRPC من خلال تحديد حبة OtlpGrpcSpanExporter .
• توحيد فصول التكوين التلقائي OpentElemetry عبر المقاييس والآثار. يمكن استخدام تكوين OpentEleMetryAutoconfiguration الحالي للتكوين المشترك. إلى جانب ذلك ، هناك حاجة إلى فئات التكوين التلقائي المخصص لتكوين المصدرين المحددين لكل نوع من أنواع القياس عن بعد. آثار لها بالفعل في تكوين OTLPautoconfiguration.

الربيع initializr

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

تغييرات إضافية لتمديد دعم قياس الأوبنتيل في الربيع إلى سجلات

مشغل التمهيد الربيع

• إدخال التكوين التلقائي لسجلات قياس الأوبنتيل. يمكن إعادة استخدام OpenTelemetry Resource من تكوين قياس الأوبنتيل. إلى جانب ذلك ، يجب أن تحدد التكوين التلقائي الإعدادات الافتراضية لـ SdkLoggerProvider و OtlpHttpLogRecordExporter و OtlpGrpcLogRecordExporter .
• أضف دعمًا للازغام (افتراضي) و Log4J2. للإلهام ، يوفر OpentElemetry Java أدوات التذييلات للازغام و Log4J2.
• ربما قضية ذات صلة في مشروع Boot Spring.

مزيد من التحسينات

• تم فتح مشكلة للتحقيق في كيفية الحد من عدد الفاصوليا القابلة للتكوين المتوفرة حاليًا في تتبع التكوين OpenTelemetryAutoConfiguration (قد يتم النظر في هذه المشكلة لتكوين OpenTelemetryAutoConfiguration العالمي بمجرد حذف التتبع المحدد).