استضافة Superlog ذاتياً: المتطلبات والقيود الفعلية

ما الذي يثبّته Superlog فعلياً عند استضافته ذاتياً

لاستضافة Superlog ذاتياً، تستنسخ المستودع، وتشغّل Postgres وClickHouse وجامع OpenTelemetry باستخدام Docker Compose، وتنفّذ عملية ترحيل واحدة لقاعدة البيانات، ثم تشغّل أربع خدمات Node من المصدر. ترسل تطبيقاتك التتبعات والسجلات والمقاييس وفق بروتوكول OTLP (OpenTelemetry) إلى منفذ استقبال. ينشئ Superlog بصمة لهذه البيانات، ويجمع المتكرر منها في حادثة واحدة، ثم يكتب وكيل أول مسودة لعملية الفرز. يستغرق التثبيت فترة بعد الظهر. أما البصمة التشغيلية والحدود الفعلية، فهما الجزءان اللذان يستحقان القراءة قبل البدء.

يخضع Superlog لترخيص Apache 2.0، ويوجد في github.com/superloglabs/superlog. حتى August 2026، لديه نحو 1.2k نجمة، وحوالي 460 عملية commit على main، ولا يملك أي وسوم إصدارات على الإطلاق. تؤثر النقطة الأخيرة في عملية التثبيت: لا يحتوي git checkout v1.0.0 على شيء يمكن سحبه، لذلك عليك تثبيت commit بنفسك، أو تشغيل الإصدار الذي كان موجوداً في main صباح اليوم الذي استنسخت فيه المستودع.

ما الذي يجيب عنه Superlog ولا تجيب عنه Uptime Kuma وLangfuse

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

• تختبر Uptime Kuma نقاط النهاية من خارج الشبكة وتجيب عن سؤال واحد: هل الخدمة متاحة.
• تراقب Zabbix المضيفات والخدمات على Ubuntu 24.04، مع تتبّع المعالج والذاكرة والقرص وحالة الخدمة مقارنةً بالحدود التي تحددها.
• تتتبّع Langfuse استدعاءات LLM، وتسجّل prompt والنموذج والرموز المميزة ومدة الاستجابة والتكلفة لكل استدعاء.
• يحوّل Superlog بيانات القياس التي تُصدرها خدماتك العادية بالفعل إلى حوادث عند تكرار حالات الفشل.

يجيب Superlog عن سؤال مختلف: ما الذي تعطل، وما سبب التعطل. لا يتعامل مع استدعاءات LLM، ولا يختبر خادمك من الخارج. يستقبل OTLP من شيفرة التطبيق العادية، ويضع agent في خطوة الفرز الأولي، وهي أول عملية ينفذها مسؤول المناوبة عادةً.

الفرق المهم عند حساب ميزانية VPS هو التخزين. تعمل Uptime Kuma بسلاسة مع 1 GB من الذاكرة لأنها تخزّن بضعة آلاف من نتائج الاختبار. أما Superlog فيستخدم column store، لأن بيانات القياس تُكتب مرة واحدة ثم يُستعلم عنها حسب النطاق الزمني عبر ملايين الصفوف. لهذا الغرض يُستخدم ClickHouse، بينما لا يناسبه Postgres. يظل Postgres جزءاً من المكدس، ويخزّن البيانات العلائقية الصغيرة: المشاريع والمستخدمين والحوادث ومفاتيح ingest.

ما الذي يشغّله الأمر docker compose up -d فعلياً؟

ثلاث حاويات، ولا واحدة منها هي Superlog. يفاجئ ذلك من يتوقع تثبيتاً بأمر واحد.

• postgres:16، مع نشره على المنفذ 5434 في المضيف
• clickhouse/clickhouse-server:26.1، على المنفذ 8123 لـ HTTP والمنفذ 9000 للبروتوكول الأصلي
• otel/opentelemetry-collector-contrib:0.150.1، على المنفذ 4317 لـ gRPC والمنفذ 4318 لـ OTLP عبر HTTP

تعمل تطبيقات Superlog على المضيف من الشيفرة المصدرية، ويبدأ تشغيلها pnpm dev. لا يوجد ملف compose مخصص للإنتاج في المستودع حتى August 2026. لذلك يتطلب التثبيت طويل الأمد إنشاء وحدات systemd الخاصة بك حول برنامج start النصي لكل تطبيق، أو استخدام ملفات Dockerfile الخاصة بكل تطبيق والموجودة في شجرة المستودع.

احتفظ في ذهنك بالمسار الذي تسلكه الـspan، لأن كل فشل أدناه يعني انقطاع إحدى حلقاته. يرسل تطبيقك OTLP إلى وكيل استقبال Superlog. يصادق الوكيل على الطلب باستخدام مفتاح الإدخال الخاص بك، ويضيف إليه معرّف المشروع، ثم يمرره إلى collector. يزيل collector أي سمات superlog.* حاول العميل تعيينها، ويضيف superlog.project_id من الرأس الذي زوّده به الوكيل، ثم يجمع البيانات على دفعات ويكتبها في ClickHouse. يقرأ تطبيق الويب وواجهة API بيانات القياس عن بُعد من ClickHouse، ويقرآن كل البيانات الأخرى من Postgres.

إزالة هذه السمات إجراء فعلي للتحكم في تعدد المستأجرين، وليست مجرد تنسيق. من دونها، يمكن لأي شخص يملك مفتاح إدخال صالحاً تعيين superlog.project_id بنفسه والكتابة في بيانات مشروع آخر.

ما الحجم المطلوب لـVPS؟

خطّط لاستخدام 4 vCPU و8 GB من RAM و40 GB من SSD لتثبيت عقدة واحدة عند انخفاض حجم الإدخال. هذا حدّ تخطيط أولي وليس قياساً فعلياً، لذلك اعتبره حجماً ابتدائياً وقارنه بحركة الشبكة لديك.

تُستخدم الذاكرة في أربعة مواضع. صُمّم ClickHouse للعمل على أجهزة تحتوي على قدر كبير من RAM، وتفترض إعداداته الافتراضية ذلك. أما Postgres 16 فاستهلاكه محدود هنا، لأنه يحتفظ بالبيانات الوصفية بدلاً من بيانات القياس عن بُعد. واستهلاك collector محدود أيضاً. لكن عمليات Node الأربع ليست كذلك: إذ تحتفظ خادم تطوير Vite وثلاث عمليات tsx watch أخرى كل منها بمئات الميغابايت، ولذلك يصبح تشغيل pnpm dev على جهاز بسعة 2 GB من RAM مرهقاً.

القرص هو المشكلة الأقل وضوحاً. يؤدي pnpm install في هذا المستودع الأحادي إلى تنزيل AWS SDK وعميل ClickHouse وOpenTelemetry SDK وسلسلة أدوات React قبل إدخال span واحد. ثم يزداد حجم ClickHouse مع حركة الشبكة لديك. قِس الأمرين معاً:

df -h /
free -m
docker stats --no-stream
docker compose exec clickhouse clickhouse-client --database superlog --query "SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active AND database = 'superlog' GROUP BY table ORDER BY sum(bytes_on_disk) DESC"

عند انخفاض الحجم، عندما ترسل مجموعة صغيرة من الخدمات بضع مئات من spans في الدقيقة، يبقى الجهاز هادئاً ويظل ClickHouse خاملاً معظم الوقت. أما الحمل المسبب للمشكلة فهو الارتفاع المفاجئ: قد يؤدي نشر سيئ واحد إلى إنتاج آلاف الأخطاء المتطابقة في الدقيقة. يجمع fingerprinting هذه الأخطاء في حادثة واحدة للقارئ، لكن ClickHouse يظل يكتب كل صف في الخلفية.

تحدد أنت مدة الاحتفاظ. ينشئ مصدّر ClickHouse في collector الجداول، وotel_traces وotel_logs، وجدولاً واحداً لكل نوع من أنواع المقاييس، ولا يطبّق مدة صلاحية إلا إذا ضبطت الإعدادات في infra/collector/config.yaml مدةً لها. لا تنتهي صلاحية أي بيانات تلقائياً، لذلك قد يؤدي شهر مزدحم إلى امتلاء القرص ما لم تخطط لذلك.

التثبيت من commit محدد

git clone https://github.com/superloglabs/superlog.git
cd superlog
git tag -l
git log -1 --format='%H %cs %s'

git tag -l إن عدم طباعة أي شيء هو النتيجة المتوقعة اعتباراً من August 2026. اختر commit الذي اختبرته والتزم به:

git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1e

بعد ذلك، تحقّق من toolchain:

node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -v

يعرّف package.json ‏engines.node بوصفه >=20.0.0، ويعرّف packageManager بوصفه pnpm@9.12.0. إذا شغّلت التثبيت على إصدار أقدم من Node، فسيتوقف pnpm مع ERR_PNPM_UNSUPPORTED_ENGINE، مع ذكر الإصدار المطلوب. حزمة nodejs في أرشيف Ubuntu 24.04 أقدم من 20، لذلك ثبّت Node 20 أو إصداراً أحدث من NodeSource أو باستخدام nvm. يتضمن المستودع ملف .nvmrc، لذلك يختار nvm use الإصدار المقصود إذا كان nvm مثبتاً لديك.

pnpm install
docker compose up -d
docker compose ps

انتظر فحوصات الصحة بدلاً من اعتبار up -d دليلاً على أن الخدمة جاهزة. يعرّف كل من Postgres وClickHouse فحصاً في ملف compose:

curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgres

يستجيب ClickHouse على Ok.، ويستجيب pg_isready على accepting connections. يعني رفض الاتصال على 8123 أن الحاوية ما زالت قيد التشغيل أو أنها توقفت. يوضح docker compose logs clickhouse أي الحالتين حدثت، بينما يبلّغ docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled عن true عندما ينهي kernel العملية بسبب نقص الذاكرة. يشير ذلك إلى أن الخادم صغير جداً، لا إلى وجود خطأ في إعداداتك.

بعد ذلك نفّذ عملية الترحيل وشغّل التطبيقات:

pnpm --filter @superlog/db db:migrate
pnpm dev

انتبه إلى المنفذ: 5434، وليس 5432. ينشر ملف compose Postgres على المنفذ 5434 حتى لا يتعارض مع Postgres مثبت مسبقاً على الخادم المضيف. وتتوافق ملفات التطبيق .env.example، مع DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog. إذا وجّهت عملية الترحيل إلى 5432 على خادم يشغّل Postgres مسبقاً، فقد تحصل على رفض للاتصال، أو ما هو أسوأ، قد تُطبَّق عملية الترحيل على قاعدة البيانات الخطأ.

يشغّل pnpm dev العمليات الأربع المدرجة في Procfile الخاص بالمستودع: api وweb وworker وproxy. ينسخ كل منها مخرجاته إلى tmp/logs/، لذلك راقب ingest في tail -f tmp/logs/proxy.log. يضع README تطبيق الويب على http://localhost:5173، وواجهة API على http://localhost:4100، ونقطة استقبال OTLP على http://localhost:4101.

تحقق مما استمع فعلياً على المنافذ قبل توجيه أي شيء إليه:

ss -lntp | grep -E '4100|4101|5173'
curl -sS http://127.0.0.1:4101/health

سيصبح ذلك مهماً لاحقاً. يقرأ proxy منفذه الخاص من متغير البيئة PORT، ويستخدم 4000 احتياطياً عندما يكون PORT غير مضبوط. يضبطه development stack تلقائياً. أما systemd unit التي تكتبها بنفسك فلا تضبطه، لذلك يفشل exporter الموجّه إلى 4101 إذا كان proxy يستمع على 4000، مع رفض الاتصال ومن دون أي مؤشر آخر على السبب.

أرسل أثراً واحداً، وأنشئ خطأً واحداً، وشاهد حادثة واحدة

أنشئ مشروعاً في تطبيق الويب وانسخ مفتاح الإدخال الخاص به. تُصادق نقطة الإدخال على كل طلب باستخدام هذا المفتاح، لذلك لا تصل بيانات القياس المرسلة بدونه إلى ClickHouse.

وجّه أي OpenTelemetry SDK إلى نقطة الإدخال باستخدام متغيرات البيئة القياسية:

export OTEL_SERVICE_NAME=checkout-api
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4101
export OTEL_EXPORTER_OTLP_HEADERS='x-api-key=YOUR_INGEST_KEY'

تقرأ نقطة الإدخال المفتاح من ترويسة x-api-key، وتقبل أيضاً authorization: bearer YOUR_INGEST_KEY إذا كان ضبط المُصدِّر بهذه الطريقة أسهل. وهي توفّر مسارات OTLP القياسية الثلاثة، /v1/traces و/v1/logs و/v1/metrics، بالإضافة إلى /health.

توجد نقطة شائعة للخطأ تستحق التوضيح. OTEL_EXPORTER_OTLP_ENDPOINT هو عنوان URL أساسي، ويضيف SDK مسار الإشارة إليه. أما المتغيرات الخاصة بالإشارات، مثل OTEL_EXPORTER_OTLP_TRACES_ENDPOINT، فتُستخدم كما هي، من دون إضافة مسار. إذا ضبطت المتغير الخاص بالإشارة على http://127.0.0.1:4101، فسترسل كل عملية تصدير طلباً إلى /، وهذا ليس مساراً. لذلك لن تصل أي بيانات، وسيسجل SDK فشل التصدير بينما يبدو تطبيقك سليماً.

بالنسبة إلى خدمة Node، يكفي المسار الذي لا يتطلب تعديلات برمجية لإثبات عمل خط الأنابيب:

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.js

عطّل شيئاً عمداً الآن. يكفي استخدام أي مسار يُلقي خطأً:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/boom

تحقق من المراحل بالترتيب، لأن أول فجوة تحدد المرحلة التي فشلت:

tail -n 50 tmp/logs/proxy.log
docker compose exec clickhouse clickhouse-client --database superlog --query 'SELECT count() FROM otel_traces'

يشير ارتفاع العدد في otel_traces مع بقاء تطبيق الويب فارغاً إلى عدم تطابق المشروع. تحقق من المشروع الذي ينتمي إليه مفتاح الإدخال. أما ثبات العدد مع وجود نشاط في سجل الوكيل العكسي، فيشير إلى مشكلة في الجامع أو في الكتابة إلى ClickHouse، لذلك اقرأ docker compose logs collector. ويعني غياب النشاط تماماً في سجل الوكيل العكسي أن المُصدِّر لم يصل إلى نقطة الإدخال: ربما يكون المنفذ أو المسار خاطئاً، أو رُفض المفتاح.

تظهر هذه الإخفاقات المتكررة في تطبيق الويب كحادثة واحدة، لا كسجل مستقل لكل طلب. ينشئ Superlog بصمات للإشارات الواردة ويجمع الإشارات المتطابقة، وهذا هو الفرق بين صندوق وارد يحتوي على 4,000 خطأ متطابق وصفحة تحتوي على خطأ واحد. ثم يكتب الوكيل تحريه فوق هذه المجموعة.

تستدعي خطوة التحري نموذجاً، لذلك يحتاج العامل إلى ضبط موفّر نموذج. خذ أسماء هذه المتغيرات من ملف .env.example داخل مجلد كل تطبيق في الالتزام الذي ثبّتَّه، لا من أي شرح خارجي، لأنها تتغير مع main. وينطبق الأمر نفسه على تكاملَي GitHub وSentry، إذ يحتوي كل منهما على وثائق الإعداد الخاصة به في docs/github-app-setup.md وdocs/sentry-app-setup.md، مع توثيق حمولات webhook في docs/webhooks.md.

اجعل نقطة الاستقبال خاصة، واجعل الوكيل للقراءة فقط

ينشر Docker منافذ الحاويات على 0.0.0.0 افتراضياً. وتتجاوز هذه المنافذ المنشورة ufw، لأن Docker يكتب قواعده الخاصة في سلسلة `DOCKER-USER، وتُقيَّم هذه القواعد قبل أن يرى ufw الحزمة. على VPS ذي عنوان IP عام، يضع ملف compose كما هو مُسلَّم ClickHouse HTTP على المنفذ 8123 وPostgres على المنفذ 5434، ما يجعل الوصول إليهما ممكناً من الإنترنت. بيانات الاعتماد في هذا الملف هي الإعدادات الافتراضية للتطوير: مستخدم ClickHouse هو default من دون كلمة مرور، وPostgres يستخدم postgres` اسم مستخدم وكلمة مرور معاً.

اربطهما بواجهة loopback. يأخذ كل منفذ منشور في ملف compose جانب المضيف من متغير بيئة. لذلك يكفي إنشاء ملف `.env` في جذر المستودع:

POSTGRES_HOST_PORT=127.0.0.1:5434
CLICKHOUSE_HTTP_HOST_PORT=127.0.0.1:8123
CLICKHOUSE_TCP_HOST_PORT=127.0.0.1:9000
COLLECTOR_GRPC_HOST_PORT=127.0.0.1:4317
COLLECTOR_HTTP_HOST_PORT=127.0.0.1:4318

تحقق من النتيجة قبل الاعتماد عليها، ثم أعد إنشاء الحاويات:

docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'

يطبع `docker compose config الملف بعد حل القيم، ولذلك يمكنك قراءة 127.0.0.1:5434:5432 بدلاً من التخمين. يجب أن يعرض ss بعد ذلك 127.0.0.1:5434، وألا يعرض 0.0.0.0:5434 مطلقاً. لا تحاول إصلاح ذلك باستخدام ملف override لـcompose يعيد تعريف ports`، لأن Compose يضم قوائم المنافذ من الملفات بدلاً من استبدالها. وهكذا ينتهي بك الأمر إلى الربطين معاً، ويبقى الربط العام مفتوحاً.

تحتاج نقطة الاستقبال إلى العناية نفسها. ينتقل مفتاح الإدخال في ترويسة، ولذلك يحتاج إلى TLS (أمان طبقة النقل) أمامه. أنهِ TLS في nginx أو Caddy قبل الـproxy، أو أبقِ الإدخال داخل شبكة خاصة أو نفق WireGuard. أما تطبيق الويب على المنفذ 5173 فهو خادم تطوير Vite، ولا ينبغي أن يكون مكشوفاً على الإنترنت إطلاقاً.

ثم يأتي الوكيل نفسه. تقوم فكرة Superlog على أن الوكيل يحقق في المشكلة ويقترح إصلاحاً. والكلمة المهمة هنا هي «يقترح». أبقه للقراءة فقط على بيئة الإنتاج إلى أن تراقب عمله في عدة حوادث حقيقية. امنح GitHub App نطاقات وصول للقراءة، واسمح له بفتح pull requests تراجعها أنت. الوكيل الذي يقرأ بيانات المراقبة ويكتب patch مفيد. أما الوكيل القادر على إعادة تشغيل خدماتك فيمثل مستوى مختلفاً من المخاطر. ويجب أن يكون ذلك قراراً تتخذه عمداً، لا إعداداً افتراضياً ترثه. تستحق التكلفة الانتباه نفسه، لأن كل تحقيق هو استدعاء لنموذج: ضع ميزانية للإنفاق على الوكيل في VPS قبل توجيهه إلى نظام إنتاج كثير الضوضاء، واحتفظ بـسجل لما فعله الوكيل فعلياً حتى يكون لأي pull request مفاجئ أثر تدقيق واضح.

الأخطاء التي ستواجهها، والنصوص التي تسميها

• ظهور ERR_PNPM_UNSUPPORTED_ENGINE أثناء pnpm install يعني أن Node أقدم من 20. يؤكد node -v ذلك في سطر واحد.
• ظهور ECONNREFUSED 127.0.0.1:5434 أثناء الترحيل يعني أن مكدس compose متوقف، أو أن DATABASE_URL يحدد المنفذ الخطأ.
• إعادة تشغيل ClickHouse في حلقة تعني عادةً وجود مشكلة في الذاكرة. اقرأ docker compose logs clickhouse، ثم تحقّق من الحاوية لمعرفة ما إذا كان OOMKilled يساوي true.
• إذا أبلغ exporter عن نجاح العملية بينما بقي تطبيق الويب فارغاً، فهذا يعني عادةً أن البيانات أُرسلت مباشرةً إلى collector على المنفذ 4318، متجاوزةً إضافة اسم المشروع التي ينفذها الـproxy.
• يعني رفض الاتصال على المنفذ 4101 في تثبيت إنتاجي أن الـproxy عاد إلى PORT=4000. عيّن PORT صراحةً في ملف الوحدة.
• يعني ظهور docker compose ps مع 0.0.0.0:8123 أن عمليات الربط على loopback غير مفعّلة. شغّل docker compose config واقرأ المنافذ التي حُلّت.

Flawless وHyperProbe وموقع Superlog بينهما

هذه الفئة جديدة، وتختلف الأدوات في نطاق الموارد التي يُسمح للوكيل بالوصول إليها. Flawless أداة AI SRE مفتوحة المصدر، موجهة إلى Kubernetes، وتقرأ البيانات من حزمة Prometheus وLoki وGrafana موجودة مسبقاً بدلاً من إدارة مسار البيانات بنفسها. أما HyperProbe فتتبع النهج المعاكس. فهي منتج مستضاف ومغلق المصدر اعتباراً من August 2026، وتضع probes للقراءة فقط داخل عملية قيد التشغيل لالتقاط حالة المتغيرات، ثم تتيح هذه الحالة لمساعد عبر MCP (model context protocol).

يقع Superlog بين النهجين. فهو يدير مسار البيانات بالكامل، بدءاً من استقبال OTLP وصولاً إلى تخزين البيانات في ClickHouse، ويضع الوكيل في خطوة الفرز الأولي بدلاً من خطوة الإصلاح. ولهذا التصميم تحديداً، فإن استضافة Superlog ذاتياً قرار متعلق بالبنية التحتية، وليست مجرد حاوية يمكن تشغيلها ثم نسيانها. عند تشغيل Superlog، فإنك تشغّل column store، ويحتاج ذلك إلى العناية نفسها التي تحتاج إليها أي قاعدة بيانات تملكها.

FAQ

ما مقدار RAM الذي يحتاجه Superlog المستضاف ذاتياً؟

خطّط لتوفير 8 GB من RAM و4 vCPU و40 GB من مساحة القرص لعقدة واحدة عند انخفاض حجم الإدخال. تتكوّن الحزمة من Postgres وClickHouse ومجمّع OpenTelemetry وأربع عمليات Node، ويتطلب ClickHouse مساحة احتياطية. لا يكفي VPS بسعة 1 GB أو 2 GB: فـpnpm install وحده يستهلك موارد كثيرة، وقد ينهي kernel عملية ClickHouse بسبب نفاد الذاكرة تحت الحمل. قِس أرقامك الفعلية باستخدام docker stats --no-stream وfree -m بدلاً من الاعتماد على أي رقم منشور، بما في ذلك هذا الرقم.

إلى أي منفذ أوجّه مُصدّر OTLP؟

وجّهه إلى وكيل استقبال Superlog، الذي يحدّد README تشغيله على http://localhost:4101. يوفّر الوكيل /v1/traces و/v1/logs و/v1/metrics، ويصادق باستخدام مفتاح الإدخال الخاص بمشروعك، المأخوذ من ترويسة x-api-key أو من ترويسة authorization: bearer. المنفذ 4318 هو منفذ مجمّع OpenTelemetry الموجود في الخلفية. يؤدي التصدير إليه مباشرةً إلى تجاوز الوكيل، وهو المكوّن الذي يضيف معرّف مشروعك إلى البيانات. يستخدم الوكيل المنفذ 4000 تلقائياً عندما يكون PORT غير مضبوط، لذا شغّل ss -lntp وتحقق من المنفذ الذي استمع إليه قبل افتراض استخدام 4101.

هل يستبدل Superlog‏ Uptime Kuma أو Zabbix؟

لا. يجيب Uptime Kuma عمّا إذا كانت نقطة نهاية تستجيب من خارج شبكتك، ويراقب Zabbix مقاييس المضيف والخدمات مقابل الحدود التي تحددها. يستهلك Superlog آثار التتبّع والسجلات والمقاييس التي تصدرها تطبيقاتك، ويجمع حالات الفشل المتكررة في حوادث. أبقِ فحص توافر خارجي إلى جانبه، لأن الفحص الذي يعمل في مكان آخر سيستمر في الإبلاغ عندما يكون الخادم الذي يستضيف مسار بيانات المراقبة هو الذي تعطل.

هل يمكن لعامل Superlog تغيير أنظمة الإنتاج لديّ؟

فقط ضمن الصلاحيات التي تمنحها له. يقدّم العامل نتيجة التحقيق والتغيير المقترح، ثم يراجعهما شخص. أبقِ GitHub App في البداية ضمن نطاقات القراءة مع طلبات السحب، واجعل أي بيانات اعتماد يحتفظ بها العامل مقيّدة بالقراءة. تعامل مع منح صلاحية الكتابة إلى الإنتاج بوصفه قراراً منفصلاً ومدروساً، لأن العامل القادر على إعادة تشغيل الخدمات يمثل التزاماً أكبر بكثير من عامل يقرأ بيانات المراقبة ويكتب تصحيحاً لمراجعته.

هل ينبغي أن أثبّت commit محدداً أم أتابع main؟

ثبّت commit محدداً. لا توجد وسوم إصدارات في المستودع حتى August 2026، لذلك يمثل main الهدف المتغير الوحيد المتاح، وهو يتلقى عدة commits أسبوعياً. سجّل SHA الذي اختبرته، وانشر ذلك الإصدار، واقرأ الفرق قبل الانتقال إلى إصدار أحدث. تمثل git log --oneline <old-sha>..main المراجعة، وتُعد ملفات .env.example الخاصة بكل تطبيق أول مكان تبحث فيه عن المتغيرات المطلوبة حديثاً بعد أي تحديث.