أساسيات EventBridge

يستطيع تنبيه CloudWatch إعادة تشغيل الخادم الواحد الذي تشير إليه أبعاده. ولا يستطيع هذا: حين يدخل أي خادم يحمل الوسم Environment=prod حالة stopped، افتح OpsItem في Systems Manager، وابدأ دليل تشغيل يلتقط مخرجات الطرفية، وأبلغ الفريق المالك. لا يوجد رقم تضع له عتبة هنا. لا شيء يرتفع ولا ينخفض. حدث شيء ما، مرة واحدة، لمورد واحد، ويجب أن تجري أشياء عدة بسببه.

هذه هي الفجوة التي يملؤها EventBridge. وهو الموجّه الذي يقف بين ما يحدث في حسابك وما يجب أن يعمل استجابةً لذلك.

الأحداث وقائع، والمقاييس أرقام

يستحق هذا الحد أن تضبطه قبل أي شيء آخر، لأن نصف الأسئلة التشخيصية في هذا المجال تدور حوله.

المقياس سلسلة زمنية من الأرقام. CPUUtilization على خادم يساوي 4% عند الساعة 09:00 و71% عند 09:01. والتنبيهات موجودة لتراقب تلك السلسلة وتقرّر متى ساءت الأرقام مدة تكفي لتستحق التصرّف.

الحدث مستند JSON يصف شيئاً وقع، ويُسلَّم مرة واحدة قرب لحظة وقوعه. تغيّرت حالة خادم. اكتملت لقطة EBS. استدعى أحدهم AuthorizeSecurityGroupIngress. فُتح إشعار AWS Health لمنطقة. لا شيء من هذا رقم، فلا يستطيع أي تنبيه مراقبته.

اختبر نفسك بقاعدة سريعة: إن كان الإنسان سيصف الموقف بفعل في الماضي، فهو حدث. وإن كان سيصفه برقم ومقارنة، فهو مقياس.

والاثنان يلتقيان، والاختبار يحب هذا الالتقاء. فتغيّر حالة تنبيه CloudWatch هو نفسه حدث على الناقل الافتراضي (aws.cloudwatch، وقيمة detail-type هي CloudWatch Alarm State Change). ولهذا فإن جواب «تنبيهي يحتاج إلى تشغيل إصلاح من خمس خطوات» يكاد يكون دائماً: أبقِ التنبيه، ودع EventBridge يطابق حدث تغيّر حالته ويبدأ سير العمل.

غلاف الحدث

كل حدث يحمل البنية الخارجية نفسها، وتتداخل الحمولة الخاصة بالخدمة داخل detail. وهذا حدث حقيقي لتغيّر حالة خادم EC2:

{
  "version": "0",
  "id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "111122223333",
  "time": "2017-12-22T18:43:48Z",
  "region": "us-west-1",
  "resources": [
    "arn:aws:ec2:us-west-1:123456789012:instance/i-1234567890abcdef0"
  ],
  "detail": {
    "instance-id": "i-1234567890abcdef0",
    "state": "terminated"
  }
}

الحقلان اللذان ستكتب أنماطك عليهما باستمرار هما source (أي خدمة أو تطبيق أصدر هذا، وتبدأ خدمات AWS بـ aws.*) وdetail-type (أي نوع من الأحداث هذا داخل ذلك المصدر). وكل ما يخصّ الحدث تحديداً يعيش تحت detail، وشكله تحدّده الخدمة المُصدِرة.

وتفصيلان في resources يوقعان الناس. أحداث استدعاءات API القادمة من CloudTrail كثيراً ما لا تحمل شيئاً في resources إطلاقاً، فالنمط الذي يرشّح عليه لن يطابق أبداً. والخدمات العالمية مثل IAM وRoute 53 تعيش في منطقة US East (N. Virginia) وحدها، فأحداث استدعاءات الـ API الخاصة بها متاحة في تلك المنطقة فقط. والقاعدة الجالسة في eu-west-1 بانتظار تغيّر سياسة IAM ستنتظر إلى الأبد.

نواقل الأحداث: الافتراضي والمخصص والشريك

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

ناقل الأحداث الافتراضي موجود في كل حساب وكل منطقة، وهو المكان الذي تسلّم إليه خدمات AWS أحداثها. وهذا غير قابل للضبط. فحين يغيّر خادم EC2 حالته، يذهب ذلك الحدث إلى الناقل الافتراضي لذلك الحساب، ولا نقاش.

الناقل المخصص ناقل تنشئه أنت. تنشر إليه تطبيقاتك عبر PutEvents، وتستطيع تمرير الأحداث من ناقل إلى آخر (بما في ذلك عبر الحسابات والمناطق) بجعل الناقل هدفاً لقاعدة. والنواقل المخصصة موجودة كي لا تضطر أحداث تطبيقاتك إلى مشاركة فضاء القواعد مع ضجيج خدمات AWS، وكي تستطيع إرفاق سياسة مبنية على المورد تسمح لحسابات محدّدة أخرى بالنشر إليه.

ناقل الشريك يستقبل الأحداث من مزوّد SaaS عبر مصدر أحداث شريك تربطه به.

والاعتقاد الخاطئ الذي يجب قتله الآن: إنشاء ناقل مخصص لا ينقل أحداث خدمات AWS إليه. فإن قال السيناريو «اعزل أحداث تطبيقنا عن ضجيج خدمات AWS»، فالناقل المخصص صحيح. وإن قال «استقبل أحداث S3 على ناقلنا المخصص»، فالجواب الأمين أنها تصل إلى الناقل الافتراضي ثم تمرّرها أنت.

وحصص تستحق الحفظ: 100 ناقل أحداث لكل حساب في كل منطقة، و300 قاعدة لكل ناقل أحداث في معظم المناطق، و5 أهداف لكل قاعدة (وهذا الأخير غير قابل للتعديل).

القواعد: النمط هو المرشّح

للقاعدة مرشّح وقائمة أهداف. والمرشّح إما نمط حدث (يطابق الأحداث بمحتواها) وإما تعبير جدولة (يُطلق وفق تعبير cron أو rate). أحدهما لا كلاهما.

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

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["terminated"]
  }
}

ثلاثة شروط منفصلة، ويجب أن تتحقق كلها.

كيف تعمل مطابقة الأنماط فعلياً

أربع قواعد تحكم كل نمط ستكتبه أو تصلحه. أتقنها هنا، فتصير معظم مشكلات «قاعدتي لا تُطلق» تشخيصاً من 30 ثانية.

المطابقة اختبار احتواء. كل حقل تسمّيه يجب أن يطابق. وكل حقل تحذفه يُتجاهل. فالنمط {"source": ["aws.ecs"]} يطابق كل أحداث ECS على الناقل. وهذه هي الآلية وراء القواعد التي تتضح لاحقاً أنها تُطلق مئات المرات يومياً: النمط ناقص التحديد لا خاطئ.

المصفوفة تعني OR. فـ "state": ["stopped", "terminated"] يطابق أياً من القيمتين. ولاشتراط شرطين معاً تسمّي حقلين، وهذا AND ضمني. وهنا فخ قريب: إن كتبت المفتاح نفسه مرتين في نمط واحد، يستخدم EventBridge الإشارة الأخيرة وحدها ويتجاهل الأولى بصمت.

المطابقة حرفية، حرفاً بحرف. معظم خدمات AWS تعامل : و/ في معرّف ARN بوصفهما متكافئين. وEventBridge لا يفعل. فإن حمل الحدث instance/i-0abc وقال نمطك instance:i-0abc، فلا شيء يطابق، ولا شيء يخبرك بالسبب.

معاملات المقارنة تعمل على العقد الطرفية فقط. و$or وanything-but هما الاستثناءان.

وتلك المعاملات هي النصف الثاني من إتقان الأنماط:

وقيدان على الأخيرين. wildcard مدعوم في قواعد ناقل الأحداث وغير مدعوم في مرشّحات Pipes، ولا يسمح كل ناقل أحداث بأكثر من 30 قاعدة تحتوي رموزاً شاملة، وهي حصة لا يمكن رفعها. و$or الذي يتوسّع إلى أكثر من 1,000 تركيبة قاعدة يُرفض بالخطأ InvalidEventPatternException، وعدد التركيبات هو حاصل ضرب أعداد وسائط كل مصفوفة $or في النمط.

وحجم نمط الحدث محدود افتراضياً بـ 2,048 حرفاً.

وأنفع عادة تشخيصية هنا هي EventBridge Sandbox في وحدة التحكم (أو واجهة TestEventPattern). ألصق حدثاً حقيقياً، وألصق نمطك، واحصل على نعم أو لا. لا يكلّف شيئاً ويحسم نقاشات تستهلك بعد ظهر يوم كامل.

الأهداف ونموذجا الصلاحيات

حتى 5 أهداف لكل قاعدة. والقائمة طويلة، والمهم منها للمعالجة هو Lambda، وSNS، وSQS، وStep Functions، وSystems Manager Automation، وSystems Manager Run Command، وSystems Manager OpsItem، وخطط الاستجابة في Incident Manager، ومهام ECS، ووجهات API، ونواقل أحداث أخرى. وبعض الأهداف لا يستقبل الحدث إطلاقاً: عمليات EC2 وهي RebootInstances وStopInstances وTerminateInstances تعامل الحدث محفّزاً لاستدعاء الـ API لا أكثر.

والصلاحيات تعمل بإحدى طريقتين، ومعرفة أيهما ينطبق على أي هدف مادة اختبار.

دور تنفيذ IAM. تضبط RoleArn على الهدف، وتسمح سياسة الثقة في الدور لـ events.amazonaws.com بتقمّصه، وتمنح سياسة صلاحياته العملية التي يحتاجها الهدف. هكذا تعمل معظم الأهداف، وهو الخيار الوحيد لأهداف مثل Systems Manager Automation وECS.

سياسة مبنية على المورد الهدف. مع Lambda وSNS وSQS، إن لم يُضبط دور تنفيذ، يرتد EventBridge إلى سياسة على المورد الهدف نفسه تمنح events.amazonaws.com صلاحية الاستدعاء أو النشر.

وهذه هي النتيجة العملية، وهي سيناريو مفضّل. أنشئ القاعدة من وحدة التحكم فتعمل، لأن وحدة التحكم ترفق السياسة المبنية على المورد نيابة عنك. وأنشئ القاعدة نفسها بـ PutTargets فلا يُستدعى الهدف أبداً، لأن لا شيء أرفق تلك السياسة. يُظهر مقياس TriggeredRules أن القاعدة أُطلقت، ولا يُظهر Invocations وصول أي شيء. وهناك صورتان أخريان من الشكل نفسه: طابور SQS أو موضوع SNS مشفّر يحتاج إلى منح kms:Decrypt وkms:GenerateDataKey لـ events.amazonaws.com في سياسة المفتاح، ولا يستطيع EventBridge استخدام طابور SQS مشفّر بمفتاح مملوك لـ AWS إطلاقاً.

تحويل المدخلات: إعادة تشكيل الحدث

بعض الأهداف يحتاج إلى الحدث كما هو. وبعضها يحتاج إلى بنية محدّدة، أو إلى سطر يقرأه إنسان. ومحوّل المدخلات (input transformer) يعالج هذا على جزأين.

مسار المدخلات يعرّف متغيّرات من الحدث بمسارات JSON:

{
  "timestamp": "$.time",
  "instance": "$.detail.instance-id",
  "state": "$.detail.state"
}

وقالب المدخلات هو ما يستقبله الهدف فعلاً:

{
  "instance": <instance>,
  "state": <state>,
  "note": "instance \"<instance>\" is in <state>"
}

ولك حتى 100 متغيّر، ومعها متغيّرات محجوزة لا تحتاج إلى تعريفها: aws.events.rule-arn، وaws.events.rule-name، وaws.events.event.ingestion-time، وaws.events.event.json للحمولة الأصلية كاملة.

والعطل المتوقع: لا يتحقّق EventBridge من مسارات المدخلات لحظة حفظ القاعدة. والمسار الذي لا يطابق شيئاً ينتج لا متغيّر، ويختفي ذلك الحقل من المخرج. لا خطأ ولا تحذير، فقط هدف يستقبل أقل مما قصدت.

القواعد المجدولة وEventBridge Scheduler

تستطيع القاعدة أن تُطلق وفق جدول بدل نمط، باستخدام rate(...) أو cron(...). وحقيقتان عن القواعد المجدولة تدور عليهما الأسئلة: التعبير يُقيَّم بتوقيت UTC، وأدق دقة هي دقيقة واحدة، ويقع الاستدعاء في مكان ما داخل تلك الدقيقة لا عند الثانية المحدّدة بالضبط.

وEventBridge Scheduler خدمة منفصلة بُنيت للجدولة تحديداً، وهي الجواب الصحيح كلما شدّد السيناريو على الحجم أو المرونة لكل جدول. يتعامل مع ملايين الجداول، ويدعم الاستدعاء لمرة واحدة والاستدعاء المتكرر، ويفهم المناطق الزمنية، ويقدّم نوافذ زمنية مرنة لتوزيع الحمل، ويصل إلى أكثر من 270 خدمة عبر معامل الهدف الشامل. أما القواعد المجدولة فمقيّدة بحصة القواعد لكل ناقل وبحد الأهداف الخمسة لكل قاعدة، وScheduler ليس كذلك.

مفتاح لغوي: «آلاف الجداول لكل عميل» أو «لمرة واحدة» أو «بالتوقيت المحلي للعميل» تشير إلى Scheduler. و«استجب حين تفعل خدمة AWS شيئاً» تشير إلى قاعدة.

نصائح للاختبار

• ابحث في نص السؤال عن فعل ماضٍ. «حين يُنهى خادم» و«حين تكتمل لقطة» و«حين يغيّر أحدهم سياسة» كلها EventBridge. أما «حين يتجاوز استخدام المعالج 80% لعشر دقائق» فهو تنبيه.
• القاعدة التي تُطلق أكثر بكثير من المتوقع نمطها ناقص التحديد. والقاعدة التي لا تُطلق أبداً سببها غالباً أحد ثلاثة: نمط بعلامات ترقيم خاطئة في ARN، أو حدث خدمة عالمية يُنتظر خارج us-east-1، أو ترشيح على حقل resources الذي تتركه أحداث CloudTrail فارغاً.
• قيمة TriggeredRules أكبر من صفر مع Invocations عند صفر تعني أن التوجيه نجح وأن الصلاحيات فشلت. وهذا سؤال السياسة المبنية على المورد بصيغة مقاييس.
• التنبيهات المركّبة لا تستطيع تنفيذ إجراءات EC2 ولا Auto Scaling. وحين يحتاج السيناريو إلى شرط مركّب يقود إصلاحاً متعدد الخطوات، يُشعر التنبيه المركّب وتطابق قاعدة EventBridge حدث تغيّر حالته.
• النواقل المخصصة لا تستقبل أحداث خدمات AWS مباشرة أبداً. وأي خيار يزعم غير ذلك يُستبعد.
• احفظ الأرقام الثلاثة الصلبة: 5 أهداف لكل قاعدة (غير قابل للتعديل)، و300 قاعدة لكل ناقل أحداث، و100 ناقل أحداث لكل حساب في كل منطقة.

النموذج الذهني الذي تحمله معك: الناقل لا يختار وجهة. كل قاعدة مرتبطة بناقل ترى كل حدث يصل، وتقرّر وحدها إن كانت تطابقه، وتسلّم إلى أهدافها هي. فإضافة قاعدة تعني إضافة مستهلك دون لمس أي شيء يعمل أصلاً، وهذا هو معنى «الاقتران المرن» هنا عملياً. وبعد ذلك ستنظر في Pipes، الذي يعالج الحالة التي يكون الناقل خاطئاً لها: تدفّق واحد محدّد تحتاج سجلاته إلى ترشيح، وإثراء بعملية بحث، وتسليم إلى وجهة واحدة بالضبط.