خط الأنابيب المدفوع بالأحداث
يعالج AuroraSOC الأحداث الأمنية عبر مسار متعدد المراحل يعتمد على الأحداث، ويستخدم ثلاثة أنظمة مراسلة متكاملة. الهدف من هذا التصميم هو ضمان الموثوقية، والقدرة على التوسع، والحفاظ على ترتيب المعالجة.
نظرة عامة على المسار
في النشر الافتراضي يعتمد AuroraSOC على Python API وPython MQTT consumer لتطبيع
الأحداث والتحقق منها قبل نشرها إلى Redis Streams. فعّل --profile rust-core فقط
إذا كنت تريد المسار السريع الاختياري للأحمال العالية أو لأعمال الاعتماد العتادي.
لماذا ثلاثة أنظمة مراسلة؟
لكل نظام دور مختلف:
| النظام | الغرض | النمط | المتانة |
|---|---|---|---|
| Redis Streams | ناقل الأحداث الداخلي | Consumer groups | In-memory + AOF |
| NATS JetStream | الفيدرالية بين المواقع | Pub/Sub + persistence | Disk-backed |
| MQTT | تواصل أجهزة IoT | Pub/Sub + QoS | تعتمد على الوسيط |
Redis Streams: الحافلة الداخلية
Redis Streams هو ناقل الأحداث الأساسي داخل كل نشر منفرد لـ AuroraSOC:
لماذا Redis Streams؟
- Consumer groups لتوزيع الحمل ومعالجة كل رسالة مرة واحدة عمليًا.
- Message acknowledgment للسماح بإعادة معالجة الرسائل الفاشلة.
- Stream trimming لتنظيف الرسائل القديمة تلقائيًا.
- زمن وصول منخفض جدًا مناسب للتنبيهات الفورية.
- بنية موجودة أصلًا لأن Redis مستخدم أيضًا في caching.
بنية عامل مهام الوكلاء
يشغل AuroraSOC عاملًا مخصصًا في aurorasoc/workers/agent_task_worker.py لتنفيذ
المهام المصطفة ونشر النتائج المرتبطة.
مجموعات المستهلكين المستخدمة في الإنتاج:
| الـ stream | مجموعة المستهلكين | المستهلك الأساسي |
|---|---|---|
aurora:agent:tasks | aurora-agents | AgentTaskWorker |
aurora:agent:results | api-agent-results | FastAPI result correlator |
aurora:alerts | api-ws-alerts | WebSocket alert broadcaster |
aurora:audit | api-ws-thoughts | WebSocket reasoning broadcaster |
مقاييس تأخر التدفقات
يجب على Prometheus متابعة التأخر والإنتاجية لمسار task/result:
| المقياس | الوصف | اقتراح التنبيه |
|---|---|---|
aurora_agent_tasks_pending_total | الرسائل المعلقة في مجموعة aurora:agent:tasks | تحذير إذا تجاوزت 200 لمدة 5 دقائق |
aurora_agent_task_retry_total | عدد المهام التي أعيدت إلى الطابور | تحذير عند النمو المستمر |
aurora_agent_dead_letter_total | عدد المهام المنقولة إلى dead letter | تنبيه فوري عند أي ارتفاع غير صفري |
aurora_agent_result_correlation_latency_ms | زمن Publish إلى future resolution | تحذير إذا تجاوز p95 حاجز 5000 ms |
aurora_agent_results_unmatched_total | نتائج لا تملك future منتظرًا | تحتاج تحقيقًا إذا استمرت بالارتفاع |
NATS JetStream: الفيدرالية بين المواقع
للمؤسسات التي تملك أكثر من نشر واحد لـ AuroraSOC:
يحتوي stream المسمى AURORA على الموضوعات التالية:
AURORA.alertsلاتحاد التنبيهات.AURORA.ioc_sharingلمشاركة IOCs.AURORA.agent_resultsلمشاركة نتائج التحقيق.AURORA.auditلمسار التدقيق بين المواقع.
لماذا NATS JetStream؟
- Persistent delivery بحيث تبقى الرسائل بعد إعادة التشغيل.
- Exactly-once semantics تقريبية عبر acknowledgment وإزالة التكرار.
- توزيع جغرافي يناسب البيئات متعددة المواقع.
- خفيف الموارد مقارنة بخيارات أثقل.
MQTT: اتصال أجهزة IoT الطرفية
يربط MQTT أجهزة IoT محدودة الموارد بالنظام:
لماذا MQTT؟
- Overhead منخفض مناسب للأجهزة المقيدة.
- QoS levels للتسليم الموثوق رغم الاتصال المتقطع.
- Topic wildcards لالتقاط جميع telemetry الخاصة بالأجهزة.
- معيار صناعي واسع الانتشار في عالم IoT.
- TLS support لتأمين القناة بين الجهاز والوسيط.
ضمانات المعالجة
| الضمان | آلية التنفيذ |
|---|---|
| At-least-once delivery | acknowledgment وإعادة التسليم عند انتهاء المهلة |
| Ordering | ترتيب كل stream داخل Redis Streams |
| Deduplication | إزالة تكرار مبنية على SHA-256 داخل scheduler بنافذة 5 دقائق |
| Backpressure | consumer groups توفر ضغطًا عكسيًا طبيعيًا |
| Dead letter | نقل المهام الفاشلة بعد 3 retries إلى aurora:agent:dead_letter |
يتبع AuroraSOC فلسفة "نقاط نهاية ذكية وأنابيب بسيطة". أنظمة المراسلة هنا مسؤولة عن النقل فقط، بينما منطق الأعمال الحقيقي يعيش في API والوكلاء والـ scheduler.
مثال كامل لتدفق التنبيه
وعند تفعيل --profile rust-core تستطيع خدمة Rust تنفيذ خطوة التطبيع السريعة قبل
النشر إلى Redis Streams نفسها الموضحة أعلاه.