اللاخوادم والعمليات المدفوعة بالأحداث

المراقبة في البيئات بلا خوادم

18 دقيقة الدرس 7 من 28

المراقبة في البيئات بلا خوادم

تفترض المراقبة التقليدية وجود عمليات طويلة الأمد: تُرفق وكيلاً، وتبثّ مقاييس مستمرة، وتربط آثار الطلبات عبر خدمات تعمل في حاويات أو أجهزة افتراضية تتحكم فيها. تُحطّم البيئات اللاخادمية هذه الافتراضات كلياً. وظيفة Lambda تحيا من أجزاء من الثانية إلى دقائق، وتعمل في بيئة معزولة لا تراها، وقد تعمل مئات النسخ منها بالتوازي في آنٍ واحد. لا يمكنك الاتصال بها عبر SSH، ولا إرفاق محلل أداء، والمنصة تتلف حالتها المحلية فور انتهاء الاستدعاء. ومع ذلك تظل بحاجة إلى معرفة ما جرى بالضبط، ولماذا كان بطيئاً، وما كلفته. المراقبة في البيئات اللاخادمية هي بناء هذه الرؤية من الخارج إلى الداخل — عبر السجلات المنظمة، والتتبع الموزع، والمقاييس الواعية بالتكلفة — دون تعديل المنصة ذاتها.

الركائز الثلاث في سياق اللاخادمية

السجلات هي إشارتك الأساسية. تستوعب CloudWatch Logs كل سطر يُكتب في stdout/stderr من أي استدعاء Lambda. لكن عبارات الطباعة الخام تنتج نصاً غير منظم يصعب الاستعلام عنه ويستحيل ربطه عبر الاستدعاءات على نطاق واسع. المعيار في الإنتاج هو تسجيل JSON منظم — كائن JSON واحد لكل حدث، يحمل مجموعة ثابتة من الحقول تُمكّن الأدوات من الفهرسة والتصفية والتجميع دون أي تحليل نصي.

الآثار تمنحك مسار الطلب عبر حدود الوظائف. قد يُشغّل إجراء مستخدم واحد خمس وظائف Lambda، ويلمس جدولين في DynamoDB، ويضع رسالة في SQS، ويستدعي واجهة برمجية خارجية. بدون التتبع الموزع ترى النتيجة لكن لا تستطيع تحديد أي خطوة أضافت 800 ملي ثانية. AWS X-Ray وOpenTelemetry هما النهجان السائدان وهما متوافقان بشكل متزايد.

المقاييس على مستوى Lambda متاحة مجاناً من CloudWatch: الاستدعاءات، والأخطاء، والمدة، والتقييد، والتنفيذات المتزامنة، وعمر المؤشر (للمصادر المتدفقة). الفجوة تكمن في المقاييس التجارية ومقاييس التكلفة — تلك يجب أن تُرسلها صراحةً.

التسجيل المنظم على نطاق الإنتاج

النهج المعياري لـ Lambda مع Python هو AWS Lambda Powertools. يُضمّن Logger الخاص بـ Powertools غلافاً قياسياً (اسم الوظيفة، الإصدار، علامة البداية الباردة، معرّف الطلب، معرّف الربط) في كل سجل تلقائياً. تُضيف حقول النطاق وتتكفل المكتبة بالتسلسل وتصفية مستوى السجل.

# requirements.txt
aws-lambda-powertools==2.38.0

# handler.py
from aws_lambda_powertools import Logger, Tracer, Metrics
from aws_lambda_powertools.metrics import MetricUnit

logger  = Logger(service="order-processor")
tracer  = Tracer(service="order-processor")
metrics = Metrics(namespace="ECommerce", service="order-processor")

@logger.inject_lambda_context(log_event=True, correlation_id_path="headers.X-Correlation-Id")
@tracer.capture_lambda_handler
@metrics.log_metrics(capture_cold_start_metric=True)
def handler(event, context):
    order_id = event["detail"]["orderId"]
    logger.info("Processing order", extra={"order_id": order_id, "amount": event["detail"]["amount"]})

    try:
        result = process_order(order_id)
        metrics.add_metric(name="OrdersProcessed", unit=MetricUnit.Count, value=1)
        logger.info("Order processed successfully", extra={"order_id": order_id, "duration_ms": result.elapsed_ms})
        return {"statusCode": 200}
    except InsufficientInventoryError as e:
        logger.warning("Inventory shortfall", extra={"order_id": order_id, "sku": e.sku})
        metrics.add_metric(name="InventoryShortfalls", unit=MetricUnit.Count, value=1)
        return {"statusCode": 409}
    except Exception as e:
        logger.exception("Unhandled error processing order", extra={"order_id": order_id})
        raise

كل سجل يُصدره هذا المعالج هو JSON صالح يحتوي حقولاً مثل level، وmessage، وservice، وfunction_name، وcold_start، وcorrelation_id، وأي حقول إضافية تُلحقها. يستطيع CloudWatch Logs Insights بعدها الاستعلام عبر ملايين الاستدعاءات في ثوانٍ باستخدام أسماء هذه الحقول مباشرةً.

الممارسة الأساسية: أدرج دائماً correlation_id (أو trace_id) ينتشر من نقطة الدخول الأولى — API Gateway أو EventBridge أو SQS — عبر كل وظيفة تالية. بدونه يصبح إعادة بناء تدفق متعدد الوظائف في CloudWatch Logs مجرد تخمين. يُضمّن Powertools هذا المعرّف من ترويسة JMESPath قابلة للتهيئة تلقائياً.

التتبع الموزع مع X-Ray وOpenTelemetry

AWS X-Ray هو الخيار الأصلي. يُضمّن SDK تلقائياً AWS SDK لـ Python/Node/Java، فيظهر كل استدعاء DynamoDB وكل عملية S3 وكل إرسال SQS كشريحة فرعية مُتتبَّعة تحمل المدة وعلامات الأعطال. تبدأ Lambda الشريحة الجذرية تلقائياً عند تفعيل التتبع النشط على الوظيفة — دون أي تهيئة SDK.

طلب مستخدم واحد مُتتبَّع عبر وظيفتي Lambda وشرائحهما الفرعية. واجهة الطرف الثالث عند 64 ملي ثانية هي نقطة تأخر الأداء.

للفرق التي تعتمد OpenTelemetry معياراً، توفر AWS طبقة Lambda المسماة AWS Distro for OpenTelemetry (ADOT). تُشغّل OTEL Collector كامتداد Lambda في عملية مرافقة، تجمع شرائح OTEL من وظيفتك وتُرسلها إلى X-Ray أو Jaeger أو Grafana Tempo أو أي نقطة نهاية OTLP متوافقة. يتجنب نهج ADOT الارتباط بمزوّد واحد وهو التوصية المتزايدة للخدمات الجديدة.

# تفعيل التتبع النشط لـ X-Ray عبر Terraform
resource "aws_lambda_function" "order_processor" {
  function_name = "order-processor"
  handler       = "handler.handler"
  runtime       = "python3.12"
  filename      = data.archive_file.lambda_zip.output_path

  tracing_config {
    mode = "Active"   # PassThrough = أخذ عينات فقط؛ Active = أخذ عينة دائماً
  }

  environment {
    variables = {
      POWERTOOLS_SERVICE_NAME      = "order-processor"
      POWERTOOLS_TRACER_CAPTURE_RESPONSE = "true"
      LOG_LEVEL                    = "INFO"
    }
  }
}

CloudWatch Logs Insights للتحقيق العملياتي

عند وقوع حادثة، يتيح CloudWatch Logs Insights الاستعلام عبر السجلات المنظمة لجميع الاستدعاءات في نافزة زمنية دون تصدير البيانات. إتقان عدد من أنماط الاستعلام يُحوّل تحقيقاً يستغرق ساعتين إلى عشر دقائق.

# البحث عن جميع أحداث الخطأ في آخر 30 دقيقة مع order_id و correlation_id
fields @timestamp, level, message, order_id, correlation_id, @requestId
| filter level = "ERROR"
| sort @timestamp desc
| limit 50

# تحليل مدة P99 لكل إصدار وظيفة (Lambda تُصدر سطور REPORT تلقائياً)
filter @type = "REPORT"
| stats
    count()              as invocations,
    avg(duration)        as avg_ms,
    pct(duration, 99)    as p99_ms,
    max(duration)        as max_ms,
    sum(billedDuration)  as total_billed_ms
  by functionVersion
| sort p99_ms desc

# رصد البدايات الباردة ومدتها
filter @type = "REPORT" and @initDuration > 0
| stats
    count()                as cold_starts,
    avg(@initDuration)     as avg_init_ms,
    pct(@initDuration, 99) as p99_init_ms
  by bin(5m)

# ربط جميع سطور سجل طلب واحد
fields @timestamp, level, message, order_id
| filter correlation_id = "req-abc123"
| sort @timestamp asc

ممارسة إنتاجية: احفظ استعلامات CloudWatch Logs Insights لأكثر ثلاثة تحقيقات عملياتية شيوعاً (معدل الخطأ، عبء البداية الباردة، P99 لكل إصدار). اعرضها على لوحة معلومات CloudWatch لفريقك. في أثناء الحوادث تحتاج إلى تشغيل تلك الاستعلامات في أقل من 30 ثانية، لا إلى كتابتها من الذاكرة تحت الضغط.

المراقبة الواعية بالتكلفة

فاتورة Lambda مباشرة: تدفع مقابل غيغابايت-ثانية (الذاكرة المخصصة × المدة بالثواني) بالإضافة إلى تكلفة لكل استدعاء. خلافاً لـ EC2 حيث التكلفة فاتورة شهرية ثابتة، تكلفة Lambda دالة لحظية على كفاءة كودك. تراجع 10% في متوسط المدة يعني ارتفاعاً مباشراً 10% في التكلفة. على نطاق واسع هذا مهم: وظيفة تُستدعى 50 مليون مرة يومياً بذاكرة 128 ميغابايت ومتوسط 200 ملي ثانية تُكلّف نحو 130 دولاراً شهرياً؛ تراجع الذاكرة إلى 256 ميغابايت عند 250 ملي ثانية يرفع التكلفة إلى 653 دولاراً — خمسة أضعاف بسبب نشر واحد فقط.

الأدوات العملية هي:

ضبط الذاكرة مع Lambda Power Tuning: آلة حالة Step Functions مفتوحة المصدر تُشغّل وظيفتك على كل إعداد ذاكرة من 128 ميغابايت إلى 10 غيغابايت وترسم التكلفة في مقابل المدة. الإعداد الأمثل نادراً ما يكون الذاكرة الدنيا — الذاكرة الأعلى تمنح Lambda قدراً أكبر من vCPU نسبياً، كثيراً ما يُنصّف المدة مما يُعوّض زيادة تكلفة الذاكرة.
تنبيهات مقياس المدة المُفوترة: أنشئ تنبيه CloudWatch على مقياس P99 لـ BilledDuration لكل وظيفة. ارتفاع مفاجئ في المدة المُفوترة هو أولى إشارات تراجع الأداء — كثيراً ما يسبق ملاحظة المستخدمين لزيادة الكمون.
كشف شذوذات تكلفة AWS: اضبط مراقباً مُحدَّداً لخدمة Lambda يستخدم ML لرصد الارتفاعات المفاجئة في التكلفة التي تتجاوز نمطك التاريخي ويُرسل تنبيهاً عبر SNS. في المؤسسات الكبيرة يُمسك هذا بحلقات إعادة المحاولة الجامحة قبل وصول الفاتورة الشهرية.

# Lambda Power Tuning — نشر SAR app مرة واحدة للحساب ثم التنفيذ:
aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:powerTuningStateMachine \
  --input '{
    "lambdaARN": "arn:aws:lambda:us-east-1:123456789012:function:order-processor",
    "powerValues": [128, 256, 512, 1024, 1769, 3008],
    "num": 10,
    "payload": "{\"detail\":{\"orderId\":\"test-123\",\"amount\":49.99}}",
    "parallelInvocation": true,
    "strategy": "cost"
  }'

# تنبيه CloudWatch على BilledDuration P99 (Terraform)
resource "aws_cloudwatch_metric_alarm" "billed_duration_p99" {
  alarm_name          = "order-processor-billed-duration-p99"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 3
  metric_name         = "Duration"
  namespace           = "AWS/Lambda"
  period              = 60
  extended_statistic  = "p99"
  threshold           = 3000    # 3 ثوانٍ — اضبطها وفق SLO الخاص بك
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    FunctionName = aws_lambda_function.order_processor.function_name
  }
}

المقاييس المخصصة ولوحات المعلومات

يستخدم وحدة Metrics في Lambda Powertools صيغة Embedded Metric Format (EMF) — مخطط JSON من CloudWatch Logs يستخرجه CloudWatch تلقائياً إلى CloudWatch Metrics الحقيقية دون أي تكلفة إضافية لاستدعاء PutMetricData. تُرسل المقاييس التجارية (الطلبات المعالجة، نقص المخزون، فشل الدفع) كسطور سجل منظمة، ويُنشئ CloudWatch السلاسل الزمنية بشفافية تامة. هذا أرخص بمراتب من استدعاء put_metric_data مباشرةً من كل استدعاء على نطاق عالٍ.

فخ إنتاجي — تآكل عمر المؤشر الصامت: بالنسبة لوظائف Lambda التي تستهلك تدفقات Kinesis أو DynamoDB Streams، مقياس IteratorAge (التأخر بين إنشاء السجل ومعالجة Lambda له) هو أهم إشارة صحية — ولا يُنشئ CloudWatch تنبيهاً له افتراضياً. عمر مؤشر يرتفع من 500 ملي ثانية إلى 45 دقيقة يعني أن وظيفتك لا تستطيع مواكبة التدفق. اضبط تنبيه CloudWatch على قيمة IteratorAge القصوى بعتبة 60 ثانية. بدون هذا التنبيه تتراكم متأخرات تُمتد لساعات قبل أن يلاحظها أحد.

المراقبة كحلقة تغذية راجعة للتكلفة والمعمارية

على المستوى المتقدم، بيانات المراقبة ليست مجرد أداة تشخيص — بل تقود القرارات المعمارية. أثر يُظهر أن 70% من وقت الوظيفة يُقضى في انتظار استدعاء DynamoDB متزامن يقترح التخزين المؤقت أو المعالجة الدفعية. تحليل تكلفة يكشف أن 40% من الاستدعاءات أقل من 100 ملي ثانية وتدفع كلٌّ منها الحد الأدنى للاستدعاء يقترح دمجها في وظائف أطول أو التحول إلى SQS batching. مقياس P99 للبداية الباردة من استعلامات Logs Insights يخبرك إن كانت Provisioned Concurrency تستحق تكلفتها لوظيفة بعينها. في البيئات اللاخادمية، بيانات المراقبة هي بيانات تخطيط الطاقة — الاثنان لا ينفصلان.