لينكدإن تبني منصة قياس عن بعد (telemetry) قائمة على OpenTelemetry لربط ما يفعله الأعضاء في تطبيقاتها على iOS وأندرويد والويب بالخدمات الخلفية التي تعالج تلك التفاعلات. تاريخياً، كان ربط هذه الرؤى يتطلب من المهندسين ربط أنظمة منفصلة. يتيح نهج لينكدإن تتبع تفاعل العضو من العميل عبر الخدمات الأمامية والخلفية وصولاً إلى مخازن البيانات الأساسية.
يمكن لصفحة واحدة أن تولد العديد من الطلبات، وقد يمر كل منها عبر خدمات متعددة. أدخلت لينكدإن معرف pageForestId لتوفير سياق أعلى من التتبعات الموزعة الفردية. يحتفظ كل طلب بمعرف تتبع OpenTelemetry الخاص به (traceId)، بينما يمكن ربط الطلبات ذات الصلة من نفس سياق الصفحة من خلال pageForestId. وبالتالي، يمكن للمهندسين التحقيق في طلب فردي والنشاط الأوسع الذي ساهم في تجربة العضو. هذا مهم لأن التتبع الموزع التقليدي يتبع طلباً واحداً بشكل عام، في حين أن رحلة العضو يمكن أن تتضمن العديد من الطلبات ذات الصلة.
تعمل لينكدإن على مجموعة تقنيات متنوعة تشمل عملاء الأجهزة المحمولة والويب إلى جانب خدمات خلفية مكتوبة بلغات Java و Python و Go و Rust. يوفر OpenTelemetry نموذجاً مشتركاً للأدوات وسياق التتبع والاتفاقيات الدلالية عبر تلك البيئات.
كيف يتم جمع ونقل بيانات القياس عن بعد؟
قامت لينكدإن ببناء أغلفة وامتدادات خاصة بها حول حزم تطوير برمجيات OpenTelemetry القياسية (SDKs)، مما يسمح لفرق المنتجات باستخدام أدوات متسقة بينما تتعامل المنصة مع أمور مثل دورة حياة الأجهزة المحمولة، والتصدير، والبيانات الوصفية الخاصة بلينكدإن. تولد تطبيقات العميل والخدمات الخلفية نطاقات OpenTelemetry (spans)، مع نشر سياق التتبع مع انتقال الطلبات عبر النظام. تقوم أطر عمل HTTP و gRPC المشتركة تلقائياً بتجهيز مسارات الطلبات الشائعة، بينما يمكن للفرق إضافة نطاقات صريحة حول عمليات الأعمال المهمة.
يتم نقل بيانات القياس عن بعد عبر Apache Kafka وتخزينها في ClickHouse، مع توفير pageForestId و traceId والطوابع الزمنية كمفاتيح للربط. يتيح ذلك للمهندسين البدء بتفاعل يواجهه العضو والتعمق في التنفيذ الخلفي المسؤول عنه.
ما هي التحديات وكيف تتعامل لينكدإن معها؟
إن التقاط كل نطاق (span) سيولد كمية هائلة من بيانات القياس عن بعد، مما يجعل أخذ العينات (sampling) أساسياً للهندسة المعمارية. تستخدم لينكدإن أخذ عينات الرأس المنسق (coordinated head sampling) بحيث يتلقى نشاط العميل والخادم ذو الصلة قرار أخذ عينات متسقاً. يساعد معرف عضو مستعار (pseudonymised member identifier) في الحفاظ على هذا الاتساق عبر الرحلة، مما يمنع أخذ عينات من العميل بينما يتم تجاهل تتبع الخدمة الخلفية المقابل، أو العكس.
تميز الشركة أيضاً بين بيانات القياس عن بعد القيمة المتعلقة بجودة التجربة (quality-of-experience) ومعلومات التصحيح الأقل قيمة. تقدر لينكدإن أن ما يصل إلى 90% من حجم بعض تتبعات الخدمات الخلفية يمكن اعتباره بيانات على مستوى التصحيح.
تفرض مراقبة جانب العميل قيوداً إضافية. يمكن تعليق تطبيقات الأجهزة المحمولة أو إنهاؤها قبل إرسال بيانات القياس عن بعد، لذلك تقوم لينكدإن بتجميع النطاقات (spans) ولكن يمكنها تفريغ بيانات القياس عن بعد عندما ينتقل التطبيق إلى الخلفية. تطبق المنصة أيضاً ضوابط حول البيانات التي يمكن أن تدخل التتبعات، بما في ذلك قوائم السماح والرفض للسمات (attribute allowlists, denylists) وإخفاء البيانات (redaction). هذا مهم لأن التتبعات الموزعة يمكن أن تصبح بخلاف ذلك قناة غير مقصودة للمعلومات الحساسة للتطبيق أو العضو.
تركز أدوات التتبع الموزع التقليدية مثل Jaeger و Grafana Tempo بشكل أساسي على تتبع الطلبات عبر الخدمات الخلفية. تجمع المنصات التجارية مثل Datadog و New Relic أيضاً التتبع الموزع مع مراقبة المستخدم الحقيقي والتطبيق. لا يتعلق نهج لينكدإن بتقديم قدرة لا تستطيع هذه المنصات توفيرها، بل يتعلق بجعل OpenTelemetry الأساس المشترك الذي يربط بيانات القياس عن بعد للعميل والخدمات الخلفية. يمنح هذا أيضاً لينكدإن سيطرة أكبر على مكدس المراقبة الخاص بها ويتجنب جعل أدوات التطبيق تعتمد على خدمة خلفية تجارية معينة.
لا يختبر العضو معرف تتبع (traceId)؛ بل يختبر صفحة تُحمّل ببطء، أو إجراء يفشل، أو ميزة تتصرف بشكل غير متوقع. ربط هذه التجارب بالأنظمة الموزعة وراءها يمنح المهندسين مساراً مباشراً أكثر بكثير من تأثير المستخدم إلى السبب التقني.
