أعادت Atlassian بناء منصة المقاييس لديها حول OpenTelemetry Collector من دون مطالبة فرق الخدمات بتغيير طريقة إرسال المقاييس في البداية. وبدلاً من إزالة خط الأنابيب القديم ثم إعادة تهيئة آلاف الخدمات، أبقت الشركة على واجهة StatsD عبر UDP، وبدّلت طبقات التجميع والمعالجة والتوجيه خلفها تدريجياً.
كانت المنصة السابقة تعتمد طوال معظم العقد الماضي على gostatsd، وهو تطبيق StatsD مفتوح المصدر تطوره Atlassian، ويعمل كوكيل جانبي على المضيفات وكطبقة تجميع في الطرف الآخر. وكانت المنصة تتعامل مع المقاييس القادمة من نحو 100 ألف مضيف موزعة على 14 منطقة، وفق هدف مستوى خدمة بلغ 99.95% وزمن تأخير منخفض.
تغيير المحرك مع إبقاء العقد ثابتاً
رأت فرق Atlassian أن إعادة تهيئة كل خدمة لاستخدام OpenTelemetry SDK قبل تغيير البنية التحتية ستكون عملية متعددة السنوات، وتحمل احتمال فقدان البيانات التي تعتمد عليها التنبيهات. لذلك فُصلت واجهة المنصة عن مكوناتها الداخلية: تواصلت الخدمات مع العنوان نفسه وبصيغة StatsD، بينما استُبدلت الطبقات الداخلية بتوزيعات مخصصة من OpenTelemetry Collector.
اعتمد التصميم أربع مراحل مستقلة هي الجمع، والاستقبال، والتجميع، والتوجيه. كما جعلت طبقة الجمع قادرة على استقبال StatsD وOTLP في الوقت نفسه. وبذلك أمكن بدء الترحيل من دون إلزام الفرق بتبديل مكتبات العملاء، مع فتح الطريق أمام المقاييس المنشأة أصلاً باستخدام OpenTelemetry.
ما الذي تغير عملياً؟
في مرحلة الجمع، استُبدل وكيل gostatsd الجانبي بتوزيعة OpenTelemetry Collector المستخدمة سابقاً لدى فريق التتبع، مع إبقاء التطبيقات على سلوكها السابق. سمح ذلك بدمج المقاييس والتتبع في وكيل جانبي واحد بدلاً من تشغيل وكيلين على كل مضيف.
تقول Atlassian إن هذا الدمج خفّض استهلاك CPU بمتوسط يقارب 3.9% لكل خدمة ضمن خدمات Micros الأعلى كلفة، وهو ما يعادل خفضاً يقارب 30% في تكلفة الوكلاء الجانبيين على مستوى الأسطول. كما أُضيف مستقبل OTLP كي تتمكن طبقة الجمع من استقبال مقاييس OpenTelemetry وإعادة توجيهها مباشرة.
أما في مرحلة الاستقبال، فكانت المشكلة الأساسية مرتبطة بحالة السلاسل الزمنية. كان يتعين إرسال كل نقطة بيانات تخص السلسلة نفسها إلى مجمّع واحد. واعتمد النظام القديم، عبر وكيل داخلي يسمى nomad، تجزئة تعتمد على زوج الخدمة والبيئة. لكن تفاوت أحجام الخدمات أدى إلى ظهور مجمّعات ساخنة وأخرى قليلة الاستخدام.
عالجت Atlassian ذلك باستخدام مكوّن loadbalancingexporter من مستودع OpenTelemetry، مع التجزئة وفق streamID، أي هوية السلسلة الزمنية الفردية. سمح هذا الأسلوب بتوزيع بيانات الخدمة الكبيرة على مجموعة المجمّعات، مع إبقاء السلسلة الواحدة على المجمّع نفسه. ونتيجة لذلك أصبح توزيع CPU بين المجمّعات أكثر توازناً، وتحسنت قدرة التوسع التلقائي وتراجعت إنذارات الحمل المرتفع.
خفض البيانات والتكلفة في طبقة التجميع
تتعامل طبقة التجميع مع نحو 4.8 مليارات نقطة بيانات في الدقيقة، لكنها تخزن نحو 220 مليون نقطة فقط، أي خفض يقارب 96%. وبما أن معظم المقاييس تستخدم delta temporality، ولم تكن المكونات السابقة تجمع هذه الفروقات بالطريقة التي يتوقعها المستخدمون، طورت Atlassian معالجاً خاصاً لتجميع دلتا المقاييس ونشرته مفتوح المصدر تحت نطاق atlassian-labs.
بعد الانتقال، أصبحت طبقة التجميع تحتاج إلى نحو نصف CPU السابق تقريباً. ويربط المصدر هذا التحسن بعدة عوامل، منها التخلص من تحليل صيغة gostatsd، وتوزيع الحمل بصورة أفضل، والاستفادة من تحسينات مجتمع OpenTelemetry.
وفي المرحلة الأخيرة، استُبدل موجه داخلي مخصص بتوزيعة Collector عديمة الحالة أطلقت عليها الشركة اسم metrics-gateway. وتعتمد هذه التوزيعة على المصدّرات upstream لدعم الإرسال إلى وجهات متعددة مثل SignalFx وS3، مع إمكانات إعادة المحاولة والطوابير والتحكم في الضغط العكسي. وبحسب التصميم المعلن، تصبح إضافة وجهة جديدة تغييراً في الإعدادات بدلاً من مشروع تكامل مستقل.
دروس الترحيل التدريجي
- ابدأ بالفرق المناسبة: اختارت Atlassian بيئات التطوير والاختبار والخدمات التي كانت تعاني أكثر من المشكلات، للحصول على ملاحظات مبكرة ضمن نطاق أقل حساسية.
- راقب الإنتاج باستمرار: كشفت عملية profiling تحت أحمال الإنتاج سلوك المكونات وتكلفتها بصورة لم توفرها الاختبارات الصغيرة أو المعايير الاصطناعية.
- حافظ على تماثل التشغيل: لأن الترحيل قد يستمر أشهراً أو سنوات مع تشغيل النظامين بالتوازي، أوصت الشركة بالإبقاء على الأدوات والإجراءات التشغيلية المشتركة قدر الإمكان.
- وسّع النطاق على مراحل: اتبعت عملية النشر نسباً متدرجة تبدأ من 1% ثم 10% و50% وصولاً إلى 100%، مع اختبار المشكلات في الخدمات الأقل حساسية قبل المسارات الحرجة.
لماذا يهم هذا النهج؟
توضح التجربة أن تبني معيار جديد في البنية التحتية لا يتطلب بالضرورة تغيير واجهات جميع المستهلكين في اللحظة نفسها. فالحفاظ على العقد الخارجي حوّل الترحيل من مشروع تنظيمي يشمل كل الفرق إلى مشروع تقوده منصة البنية التحتية، مع فتح المجال تدريجياً أمام OTLP ومكونات OpenTelemetry.
وتشير Atlassian إلى أن gostatsd وnomad كانا يمثلان معاً نحو 38% من طلبات CPU في عناقيد المقاييس، بينما كان nomad وحده يمثل نحو 13% من إجمالي الموارد. لذلك لا يقتصر أثر الانتقال على توحيد الأدوات؛ بل يرتبط أيضاً بإزالة مكونات مخصصة مكلفة وتقليل عدد الأجزاء التي تحتاج إلى صيانة داخلية.
مع ذلك، لا يعني هذا أن الترحيل اكتمل على مستوى instrumenting الخدمات. فالخطوة التالية التي ذكرتها الشركة هي نقل أدوات instrumenting نفسها إلى OpenTelemetry SDK، والتخلي تدريجياً عن عملاء Datadog وDogStatsD ومكتبات StatsD الداخلية التي ما زالت مستخدمة. كما تبقى نتائج الأداء والأرقام الواردة هنا وصفاً لتجربة Atlassian على بيئتها، وليست ضماناً بأن القيم نفسها ستتكرر في كل بنية مراقبة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.