الـ Observability اللي تنقذك الساعة 3 الفجر: Logs وTraces وشو اللي فعلاً يهم

الأعمدة الثلاثة غلط

كل محاضرة عن Observability تبدأ بـ "الأعمدة الثلاثة: اللوقات، المقاييس، والتتبعات." هذا التأطير ناقص. يقلك شو تجمع لكن ما يقلك شو تسوي فيه. السؤال الحقيقي الساعة 3 الفجر مش "عندي لوقات؟" السؤال هو: "أقدر ألاقي سطر اللوق الواحد اللي يفسر ليش طلبية هالعميل فشلت، عبر 7 سيرفسات، بأقل من دقيقتين؟"

نشغّل أنظمة إنتاج فيها عدة سيرفسات، وBackground Workers، وMessage Queues، وخطوط أنابيب ذكاء اصطناعي. هالمقال يغطي شو اللي فعلاً يساعد لما الأمور تنكسر. لأنماط التطبيق الخاصة بـ OpenTelemetry، شوف دليل OpenTelemetry. لـ Observability خاصة بالذكاء الاصطناعي، شوف دليل مراقبة الذكاء الاصطناعي.

Structured Logging: الصيغة اللي تنقذك

اللوقات غير المنظمة ما تنفع على نطاق واسع. console.log('Processing order ' + orderId) يصير ضوضاء في نظام ينتج 10,000 سطر لوق بالدقيقة.

اللوقات المنظمة قابلة للاستعلام، والفلترة، والتنبيه:

// غير منظم (ما ينفع على نطاق واسع)
console.log('Processing order 12345 for customer sara@beispiel.de');

// منظم (قابل للاستعلام، خالي من PII)
logger.info('order_processing_started', {
    order_id: 'ord_12345',
    customer_id: 'cust_abc',  // ID، مش إيميل
    channel: 'web',
    tenant_id: 'tenant_acme',
    items_count: 3,
    total_cents: 15900,
});

انضباط مستوى اللوق

الإنتاج لازم يشتغل على مستوى info. الـ debug يولد حجم كبير جداً. error و warn لازم دايماً يفعّلوا مراجعة (إذا مش تنبيهات).

لا PII في اللوقات

مجمّع اللوقات (Datadog، CloudWatch، Loki، Elasticsearch) يفهرس كل شي. إذا اللوقات تحتوي على إيميلات أو أسماء أو أرقام تلفونات، بنية اللوقات عندك تصير خاضعة لـ GDPR.

// سيء: PII في اللوقات
logger.info('Email sent to sara.mustermann@beispiel.de about order 12345');

// جيد: IDs بس
logger.info('notification_sent', {
    recipient_id: 'cust_abc',
    notification_type: 'order_confirmation',
    order_id: 'ord_12345',
    channel: 'email',
});

لمعمارية حماية PII الكاملة، شوف دليل منع تسريب البيانات.

Correlation IDs: تتبع طلب عبر السيرفسات

طلب مستخدم واحد ممكن يمر على API Gateway، وسيرفس مصادقة، وسيرفس منتجات، وسيرفس دفع، وWorker إشعارات، ومفهرس بحث. بدون Correlation ID، إيجاد كل إدخالات اللوق لطلب واحد يحتاج تخمين Timestamps و grep.

// التوليد عند الحافة (API Gateway أو أول سيرفس)
const correlationId = crypto.randomUUID();

// التمرير عبر كل سيرفس من خلال الهيدرات
const response = await httpClient.post('/api/orders', body, {
    headers: { 'X-Correlation-Id': correlationId },
});

// التضمين في كل إدخال لوق
logger.info('order_created', {
    correlation_id: correlationId,
    order_id: order.id,
    tenant_id: ctx.tenantId,
});

// التضمين في كل رسالة تُرسل للـ Queues
await queue.add('send_confirmation', {
    orderId: order.id,
    correlationId,
});

عند التصحيح، استعلم بالـ Correlation ID:

correlation_id = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"

كل إدخال لوق من كل سيرفس لهذا الطلب يظهر. السلسلة الكاملة مرئية. هذي أكثر أداة تصحيح مؤثرة في الأنظمة الموزعة.

إرهاق التنبيهات: تنبيهات أقل، تنبيهات أفضل

المقاربة الافتراضية: نبّه على كل شي. Error Rate > 0؟ تنبيه. الكمون > 500ms؟ تنبيه. Queue Depth > 10؟ تنبيه. النتيجة: 200 تنبيه باليوم، كلهم يتجاهلوهم.

مبادئ تصميم التنبيهات

مستويات التنبيهات

الهدف: تنبيهات P1 تطلق أقل من مرة بالأسبوع. إذا تطلق يومياً، إما إعداداتها غلط أو النظام عنده مشاكل موثوقية جوهرية.

إدارة التكاليف

الـ Observability غالية. استيعاب اللوقات، تخزين المقاييس، حفظ الـ Traces، واستضافة الداشبوردات تتجمع بسرعة.

تقليل حجم اللوقات بدون خسارة الإشارة

// لا تسجل كل Health Check
if (req.path === '/health' || req.path === '/ready') {
    return next(); // تخطي التسجيل
}

// عيّنات من العمليات المفصلة
if (req.path.startsWith('/api/search') && Math.random() > 0.1) {
    ctx.skipLogging = true; // سجل بس 10% من طلبات البحث
}

// دائماً سجل الأخطاء، أحداث الأعمال، والطلبات البطيئة
logger.info('request_completed', {
    path: req.path,
    status: res.statusCode,
    duration_ms: duration,
    // حقول مفصلة بس للطلبات البطيئة أو اللي فيها أخطاء
    ...(duration > 1000 || res.statusCode >= 400 ? {
        query_params: sanitize(req.query),
        response_size: res.contentLength,
    } : {}),
});

نموذج نضج الـ Observability

أغلب الفرق عند L1-L2. الـ L3 (Correlation IDs) هي أكبر تحسين فردي. الـ L4 (تنبيهات جيدة) تمنع الاحتراق الوظيفي. الـ L5 طموح لكن قابل للتحقيق.

الأخطاء الشائعة

1. لوقات غير منظمة. console.log مع دمج النصوص هو ضوضاء على نطاق واسع. استخدم JSON منظم مع حقول مصنفة.

2. PII في اللوقات. مجمّع اللوقات يصير خاضع لـ GDPR. سجّل IDs، مش قيم.

3. التنبيه على كل شي. 200 تنبيه باليوم يعني صفر تنبيهات تُقرأ. درّج التنبيهات حسب الخطورة والتأثير التجاري.

4. Labels مقاييس عالية الكاردينالية. استخدام User IDs أو Request IDs كـ Labels للمقاييس ينشئ ملايين السلاسل الزمنية. استخدم Labels محدودة (Status Code، Endpoint، Tenant).

5. بدون Correlation IDs. بدونها، تصحيح طلب عبر 7 سيرفسات يحتاج تخمين Timestamps ودعاء.

6. بدون Log Sampling. تسجيل كل Health Check وطلب بحث بالتفصيل الكامل يضاعف فاتورة اللوقات. عيّن من العمليات المفصلة، سجّل الأخطاء دائماً.

7. بدون ميزانية تكلفة للـ Observability. إنفاق الـ Observability لازم يكون 5-15% من إنفاق البنية التحتية. تتبعه. حسّنه.

8. داشبوردات محد يشوفها. إذا داشبورد ما انشاف من 30 يوم، احذفه. انتشار الداشبوردات يزيد التكاليف والارتباك.

النقاط الرئيسية

• Structured Logging مش قابل للتفاوض. JSON مع حقول مصنفة. قابل للاستعلام، للفلترة، للتنبيه. أبداً دمج نصوص.

• Correlation IDs أكثر أداة تصحيح مؤثرة. ولّدها عند الحافة، مررها عبر كل سيرفس وكل Queue. استعلم بالـ Correlation ID عشان تشوف سلسلة الطلب الكاملة.

• لا PII في اللوقات. أبداً. سجّل IDs العملاء، مش إيميلات العملاء. سجّل IDs الطلبيات، مش محتويات الطلبيات. بنية اللوقات لازم ما تصير مسؤولية حماية بيانات.

• تنبيهات أقل، تنبيهات أفضل. تنبيهات P1 لازم تطلق أقل من مرة بالأسبوع. كل تنبيه لازم يكون قابل للتنفيذ. ضمّن التأثير التجاري في رسالة التنبيه.

• حط ميزانية للـ Observability. حجم اللوقات، كاردينالية المقاييس، Trace Sampling، وسياسات الحفظ كلها تأثر على التكلفة. تتبع إنفاق الـ Observability كنسبة من إنفاق البنية التحتية.

نبني Observability بكل نظام ننشره سواء خدمات ذكاء اصطناعي، أو بنية تحتية سحابية، أو برمجيات مخصصة. إذا تحتاج مساعدة بـ Observability للإنتاج، تواصل مع فريقنا أو اطلب عرض سعر.