الأعمدة الثلاثة للملاحظة

الملاحظة الحديثة تقوم على ثلاثة أعمدة: المقاييس، السجلات، والتتبعات. فهم كيف يُكمّلون بعضهم أمر ضروري.

الملاحظة مقابل المراقبة

المراقبة	الملاحظة
تُخبرك متى شيء خاطئ	تساعدك على فهم لماذا
أسئلة ولوحات محددة مسبقاً	استكشف المجهولات المجهولة
نبّه عند تجاوز العتبة	تحقق من المشاكل الجديدة
"هل النظام سليم؟"	"لماذا هذا الطلب بطيء؟"

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

┌─────────────────────────────────────────────────────────┐
│                      الملاحظة                            │
├─────────────────┬─────────────────┬─────────────────────┤
│    المقاييس     │    السجلات      │      التتبعات       │
├─────────────────┼─────────────────┼─────────────────────┤
│ ماذا يحدث       │ ماذا حدث        │ كيف حدث            │
│ (مجمّع)         │ (مفصّل)         │ (تدفق موزع)        │
├─────────────────┼─────────────────┼─────────────────────┤
│ Prometheus      │ ELK/Loki        │ Jaeger/Zipkin       │
│ Datadog         │ Splunk          │ OpenTelemetry       │
│ Grafana         │ CloudWatch      │ AWS X-Ray           │
└─────────────────┴─────────────────┴─────────────────────┘

المقاييس: "ماذا"

بيانات رقمية مجمّعة مع الوقت:

# مقاييس عالية العناصر (احذر)
http_requests_total{user_id="123"}  # سيء - قيم كثيرة جداً

# نهج أفضل
http_requests_total{endpoint="/api/users", method="GET"}  # جيد

متى تستخدم المقاييس

حالة الاستخدام	مثال
التنبيه	معدل الأخطاء > 5%
اللوحات	اتجاهات الحركة
تخطيط السعة	CPU يتجه للأعلى
تتبع SLO	نسبة التوفر

السجلات: "ماذا حدث"

أحداث منظمة مع سياق:

{
  "timestamp": "2025-01-04T10:30:00Z",
  "level": "ERROR",
  "service": "payment-api",
  "trace_id": "abc123",
  "span_id": "def456",
  "user_id": "user-789",
  "message": "فشلت معالجة الدفع",
  "error": "البطاقة مرفوضة: رصيد غير كافٍ",
  "duration_ms": 234,
  "metadata": {
    "card_type": "visa",
    "amount": 99.99
  }
}

أفضل ممارسات التسجيل

الممارسة	لماذا
التسجيل المنظم (JSON)	قابل للتحليل آلياً
أضف trace/span IDs	الربط مع التتبعات
مستويات السجل (DEBUG → ERROR)	التصفية حسب الشدة
تجنب PII في السجلات	الامتثال، الأمان
سجّل السياق، ليس الأسرار	أضف request ID، user ID

استعلامات السجلات (Loki LogQL)

# ابحث عن الأخطاء في خدمة الدفع
{service="payment-api"} |= "ERROR"

# حلل JSON وصفّي
{service="payment-api"} | json | level="ERROR" | duration_ms > 1000

# عد الأخطاء حسب endpoint
sum by (endpoint) (count_over_time({service="api"} |= "ERROR" [5m]))

التتبعات: "كيف"

تدفق الطلب الموزع عبر الخدمات:

[طلب المستخدم]
      │
      ▼
┌───────────┐    250ms إجمالي
│ API Gateway│───────────────────────────────┐
└─────┬─────┘                                │
      │                                      │
      ▼                                      │
┌───────────┐    150ms                       │
│   Auth    │─────────────┐                  │
└─────┬─────┘             │                  │
      │                   │                  │
      ▼                   ▼                  │
┌───────────┐    ┌───────────┐              │
│  Service A│    │   Redis   │              │
│   80ms    │    │   20ms    │              │
└─────┬─────┘    └───────────┘              │
      │                                      │
      ▼                                      │
┌───────────┐                               │
│ Database  │                               │
│   50ms    │                               │
└───────────┘                               │

بنية التتبع

التتبع (الطلب من البداية للنهاية)
├── Span: API Gateway (span الجذر)
│   ├── Span: Auth Service
│   │   └── Span: بحث Redis
│   └── Span: Service A
│       └── Span: استعلام قاعدة البيانات

OpenTelemetry (المعيار)

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider

# تهيئة المتتبع
trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)

# إنشاء spans
with tracer.start_as_current_span("process_payment") as span:
    span.set_attribute("payment.amount", 99.99)
    span.set_attribute("user.id", "user-123")

    # Span متداخل
    with tracer.start_as_current_span("validate_card"):
        # منطق التحقق
        pass

ربط الأعمدة الثلاثة

المفتاح هو ربط المقاييس، السجلات، والتتبعات:

1. التنبيه ينطلق (المقاييس)
   "معدل الأخطاء > 5% لـ payment-api"

2. التحقيق بالسجلات
   بحث: {service="payment-api"} |= "ERROR" | آخر 5 دقائق

3. تتبع طلب محدد
   ابحث عن trace_id من السجل، اعرض في Jaeger
   انظر بالضبط أي خدمة/استعلام فشل

Exemplars: ربط المقاييس بالتتبعات

# Prometheus histogram مع exemplar
histogram_quantile(0.99,
  rate(http_request_duration_seconds_bucket[5m])
) # انقر على نقطة البيانات → انظر trace_id → اعرض التتبع

أسئلة المقابلة

س: "مستخدم يشتكي من بطء الدفع. كيف تحقق؟"

1. المقاييس: تحقق من زمن p99 لـ endpoint الدفع
2. السجلات: ابحث عن طلبات ذلك المستخدم في الفترة الزمنية
3. التتبعات: ابحث عن التتبع البطيء، انظر أي span استغرق أطول
4. السبب الجذري: استعلام قاعدة بيانات؟ API خارجي؟ تنافس موارد؟

س: "كيف ستُنفذ الملاحظة لخدمة مصغرة جديدة؟"

# الحد الأدنى للملاحظة القابلة للتطبيق:
1. المقاييس:
   - معدل الطلبات، معدل الأخطاء، الزمن (RED)
   - استخدام الموارد
   - مقاييس الأعمال (الطلبات/الدقيقة)

2. السجلات:
   - تنسيق JSON منظم
   - أضف trace_id وspan_id
   - مستويات السجل: INFO للعادي، ERROR للفشل

3. التتبعات:
   - تكامل OpenTelemetry SDK
   - أدرج تلقائياً عملاء HTTP
   - Spans مخصصة لمنطق الأعمال

4. اللوحات:
   - نظرة عامة على الخدمة (الإشارات الذهبية)
   - خريطة التبعيات
   - تحليل الأخطاء

5. التنبيهات:
   - عتبة معدل الأخطاء
   - تدهور الزمن
   - فشل التبعيات

التالي، سنغوص في SLOs وميزانيات الأخطاء—أساس إدارة موثوقية SRE. :::