الموجز
خدمة صغيرة تأخذ حمولة إشعار وتنشرها إلى Slack وDiscord وTelegram من نقطة واحدة. تستخدمها بقية المنصة: ContentForge يستدعيها لموجّه المراجعة اليومي، FB-Media يستدعيها لتنبيهات خط الإنتاج، لوحة homelab تستدعيها لتجاوزات العتبات.
كان الموجز بسيطًا: استبدال ثلاثة عملاء إشعار مختلفين (واحد لكل قناة) بنقطة HTTP واحدة تفعل ما يجب. تقليل عدد بيانات الاعتماد التي يجب أن يعرفها كل مشروع من ثلاث إلى واحدة.
المعمارية
نقطة Fastify واحدة (POST /notify) على Node، تعمل في CT 209 على عقدة Proxmox للخدمات. الحمولة هي مظروف رفيع:
{
"message": { "title": "...", "body": "...", "source": "..." },
"severity": "info | success | warning | error | critical"
}المعالج يختار التنسيق حسب القناة (مرفق Slack مع لون، embed Discord مع أيقونة خطورة، Telegram Markdown مع emoji) من جدول بحث واحد, إضافة قناة رابعة لاحقًا تعني إدخالًا واحدًا، لا switch لكل قناة.
نقطة ثانية (POST /telegram/webhook) تستمع لرسائل Telegram الواردة وتردّ عبر backend دردشة ثنائية الاتجاه صغير موجّه إلى حاوية Ollama على محطة العمل. الدردشة محفوظة بعيدًا عن الوصول العام عبر قائمة سماح بوت Telegram (فقط معرّفات الدردشة المقترنة تتلقّى ردودًا).
النتائج
- 3 قنوات (Slack، Discord، Telegram) قابلة للوصول عبر نقطة HTTP واحدة.
- مخطّط حمولة موحّد واحد, كل مشروع يستدعي يستخدم نفس المظروف.
- دردشة Telegram ثنائية الاتجاه مع backend Ollama على محطة العمل، بلا تكلفة API لكل رسالة.
- صفر انقطاعات غير مخطّطة منذ الإطلاق, الخدمة تعمل كوحدة systemd واحدة مع إعادة تشغيل تلقائي.
ما هو التالي
عنصران على قائمة التكرار التالي:
- توحيد الربط بين الخطورة والتنسيق-حسب-القناة في جدول بحث صغير منذ اليوم الأول, switch لكل قناة الحالي ممتاز عند ثلاث قنوات لكنه سيصبح مشكلة عند ست. إعادة الهيكلة بجدول البحث في الطابور.
- مستقبل webhook لـ Prometheus AlertManager, المنصة تشغّل بالفعل Prometheus + Grafana؛ المستهلك الطبيعي التالي لـ
/notifyهو AlertManager المُطلَق على تجاوزات عتبات Grafana.