لماذا تستبدل Datadog أو New Relic بـ SigNoz؟
SigNoz منصة مراقبة مفتوحة المصدر (رخصة Apache 2.0) تعتمد على ClickHouse للتخزين عالي الأداء، وبروتوكول OpenTelemetry لإضافة التتبع. بياناتك تبقى على بنيتك التحتية، وتتحكم في مدة الاحتفاظ، ولا تدفع سوى تكلفة VPS الذي يشغّل المنظومة.
أدوات SaaS للمراقبة تتبع نموذج تسعير متصاعداً : مجانية لعدد قليل من الخوادم، ثم الفاتورة ترتفع مع كل خدمة جديدة حتى تتجاوز 200 إلى 500 يورو شهرياً دون قيمة مضافة تناسبها.
ما الذي يمنحك إياه SigNoz
- Traces موزعة: تصوُّر كامل لمسار طلب HTTP عبر خدماتك المصغرة، مع spans ومدد وأخطاء في كل خطوة.
- مقاييس متوافقة مع Prometheus: استورد لوحات التحكم الموجودة أو أنشئ لوحات جديدة مباشرةً في واجهة SigNoz.
- سجلات مركزية: جمع سجلات منظّمة من جميع تطبيقاتك في واجهة موحدة.
- تنبيهات قابلة للضبط: حدد حدوداً لأي مقياس وتلقَّ إشعارات عبر Slack أو PagerDuty أو webhook.
- لوحات تحكم مخصصة: أنشئ عروضاً تقنية في بضع نقرات دون الحاجة لمعرفة LoQL أو PromQL.
- واجهة مستخدم حديثة: واجهة React سريعة الاستجابة بدون وكيل احتكاري من جانب العميل.
المتطلبات الأساسية
يعتمد SigNoz على ClickHouse، محرك قاعدة بيانات عمودية يستهلك ذاكرة كبيرة. الحد الأدنى الموصى به هو 4 جيجابايت ذاكرة عشوائية — أقل من ذلك يؤدي إلى قتل ClickHouse بواسطة OOM killer قبل أن تُحمَّل الواجهة. للاستخدام الإنتاجي مع عدة تطبيقات، استهدف 8 جيجابايت.
قائمة المتطلبات:
- خادم VPS يعمل بـUbuntu 22.04 أو Debian 12.
- Docker Engine ≥ 24 وDocker Compose V2.
- المنفذ 8080 مفتوح (واجهة SigNoz).
- المنافذ 4317 (OTLP/gRPC) و4318 (OTLP/HTTP) مفتوحة.
- 20 جيجابايت مساحة قرص كحد أدنى.
تثبيت SigNoz عبر Foundry CLI
الخطوة 1 — تثبيت Docker على VPS
curl -fsSL https://get.docker.com | sh systemctl enable --now docker docker compose versionالخطوة 2 — تثبيت Foundry CLI (foundryctl)
منذ الإصدار v0.112.0، يعتمد SigNoz على Foundry CLI كطريقة النشر الرسمية.
curl -L https://get.foundry.so/foundryctl/latest | bash export PATH="$HOME/.foundry/bin:$PATH" foundryctl --versionالخطوة 3 — إنشاء ملف casting.yaml
mkdir -p /opt/signoz && cd /opt/signoz cat > casting.yaml << 'EOF' apiVersion: foundry.so/v1 kind: Casting metadata: name: signoz spec: release: stable components: - name: signoz enabled: true - name: clickhouse enabled: true EOFالخطوة 4 — تشغيل النشر
cd /opt/signoz foundryctl cast -f casting.yamlيسحب Foundry CLI صور Docker ويشغّل الحاويات بالترتيب الصحيح. يستغرق التشغيل الكامل نحو 2-3 دقائق.
الخطوة 5 — التحقق من تشغيل SigNoz
docker compose -f /opt/signoz/docker-compose.yaml psافتح المتصفح على
http://<IP_VPS>:8080. ملاحظة: المنفذ القديم 3301 المذكور في دروس قديمة أصبح غير صالح — المنفذ الحالي هو 8080.الخطوة 6 — تأمين الوصول بـ Nginx
لا تُعرّض المنفذ 8080 مباشرةً. استخدم Nginx كـreverse proxy مع TLS:
ufw deny 8080server { listen 443 ssl; server_name signoz.yourdomain.com; location / { proxy_pass http://127.0.0.1:8080; } }
إضافة التتبع لـ Node.js وPython وGo
يستقبل SigNoz التتبعات عبر بروتوكول OTLP. إليك كيفية توصيل ثلاثة بيئات شائعة.
Node.js (Express/Fastify):
npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-nodeOTEL_EXPORTER_OTLP_ENDPOINT="http://<IP_VPS>:4318" \
OTEL_SERVICE_NAME="my-api" \
node -r ./tracing.js app.jsPython:
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
OTEL_EXPORTER_OTLP_ENDPOINT="http://<IP_VPS>:4318" \
OTEL_SERVICE_NAME="my-python-service" \
opentelemetry-instrument uvicorn main:appGo — spans يدوية:
go get go.opentelemetry.io/otel \
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp \
go.opentelemetry.io/otel/sdk/traceهيئ المتتبع في main.go ثم أنشئ spans حول العمليات الحرجة:
tracer := otel.Tracer("my-go-service")
ctx, span := tracer.Start(ctx, "fetch-user-details")
defer span.End()
span.SetAttributes(attribute.String("user.id", userID))في الحالات الثلاث، تظهر traces في واجهة SigNoz تحت الخدمات في ثوانٍ من أول طلب.
ضبط رتنشن ClickHouse والتخزين البارد
على VPS بمساحة قرص محدودة، قد تملأ البيانات القرص في غضون أسابيع بالإعدادات الافتراضية (3 أيام للـtraces، 30 يوماً للمقاييس).
ضبط الرتنشن من الواجهة: اذهب إلى الإعدادات ← فترة الاحتفاظ لضبط مدد مختلفة للـtraces والمقاييس والسجلات. لوكالة تدير مشاريع متعددة، 7 أيام للـtraces و90 يوماً للمقاييس توازن جيد.
ClickHouse TTL مع حجم تخزين بارد:
إذا كان لديك حجم ثانٍ منخفض التكلفة مُثبَّت على /mnt/cold، يمكنك إعداد ClickHouse لنقل البيانات القديمة تلقائياً:
<storage_configuration>
<disks>
<default/>
<cold_disk>
<type>local</type>
<path>/mnt/cold/clickhouse/</path>
</cold_disk>
</disks>
<policies>
<tiered>
<volumes>
<hot><disk>default</disk></hot>
<cold><disk>cold_disk</disk></cold>
</volumes>
</tiered>
</policies>
</storage_configuration>ثم طبّق سياسة TTL على جدول traces في SigNoz:
ALTER TABLE signoz_traces.distributed_signoz_index_v2
MODIFY TTL toDateTime(timestamp) + INTERVAL 7 DAY
TO VOLUME 'cold',
toDateTime(timestamp) + INTERVAL 30 DAY DELETE;التنبيهات المخصصة في SigNoz
بمجرد إضافة التتبع لتطبيقاتك، يملأ SigNoz تلقائياً عرض الخدمات بزمن الاستجابة P50/P99 ومعدل الأخطاء والإنتاجية لكل خدمة.
تنبيه على زمن الاستجابة P99: اذهب إلى التنبيهات ← قاعدة تنبيه جديدة، اختر تنبيه يستند إلى مقياس، وحدد الشرط : p99(signoz_latency_bucket{service_name="my-api"}) > 500.
تنبيه على معدل الأخطاء: استخدم الشرط rate(signoz_calls_total{service_name="my-api",status_code="STATUS_CODE_ERROR"}[5m]) > 0.05 للإطلاق عند تجاوز 5% من الاستدعاءات للفشل.
كشف الشذوذ: يدعم SigNoz قواعد تنبيه من نوع Anomaly — حدد نافذة مرجعية (مثلاً 7 أيام) وحداً مقبولاً للانحراف. أي تغيُّر غير معتاد في الإنتاجية أو زمن الاستجابة يُطلق التنبيه.
إنشاء لوحة تحكم مخصصة: اذهب إلى لوحات التحكم ← لوحة جديدة، أضف لوحة Time Series واختر مقياس Prometheus.
التوسع : standalone أو cluster
يتعامل SigNoz في وضع standalone مع نحو عشر خدمات مُضافة إليها تتبع تولّد بضعة آلاف من spans في الثانية. هذا هو حالة الاستخدام المستهدفة لـVPS المطور.
متى تفكر في الانتقال إلى cluster:
- يصل VPS بانتظام إلى 80% استخدام CPU على عملية ClickHouse.
- يتجاوز حجم traces 5000 span/ثانية في الذروة المستمرة.
- تحتاج إلى توافر عالٍ دون توقف عند التحديثات.
التوسع العمودي أولاً: قبل التوزيع، ضاعف ذاكرة VPS. ClickHouse مصمم للاستفادة من ذاكرة كبيرة؛ الانتقال من 8 إلى 16 جيجابايت غالباً ما ينقل عنق الزجاجة من CPU إلى الشبكة.
التوسع الأفقي: يوفر SigNoz مخططات Helm لنشر Kubernetes مع ClickHouse موزع. على VPS، أبسط نهج هو إضافة VPS ثانٍ مخصص لـClickHouse، متصل بالأول عبر شبكة خاصة.
احذر من قتل ClickHouse بسبب نقص الذاكرة
على VPS بأقل من 4 جيجابايت ذاكرة متاحة، قد يقتل kernel لينكس عملية ClickHouse بـ exit code 137.
التشخيص:
dmesg | grep -i oomستجد سطراً مثل Out of memory: Killed process XXXX (clickhouse-serv).
العلاج: أضف ذاكرة إلى VPS (موصى به)، أو حدّ استخدام ClickHouse للذاكرة بإضافة max_memory_usage=2000000000 إلى /etc/clickhouse-server/users.xml.
SigNoz مقابل Datadog وGrafana Cloud
مرّر الجدول أفقيًا
| المعيار | SigNoz (استضافة ذاتية) | Datadog | Grafana Cloud |
|---|---|---|---|
| التكلفة الشهرية (5 خدمات) | تكلفة VPS فقط (~10-20€) | ~75-150$ + مقاييس مخصصة | مجاني حتى 10k سلسلة، ثم ~8$/1k |
| Traces موزعة | نعم (OpenTelemetry أصيل) | نعم (عميل احتكاري) | نعم (Tempo، عبر OTLP) |
| المقاييس | نعم (متوافقة مع Prometheus) | نعم (احتكارية + Prometheus) | نعم (Mimir، متوافقة مع Prometheus) |
| السجلات | نعم (مدمجة) | نعم (تكلفة إضافية) | نعم (Loki، تكلفة إضافية) |
| سيادة البيانات | كاملة — بياناتك على VPS | بيانات عند Datadog (US/EU) | بيانات عند Grafana Labs |
| التعقيد التشغيلي | متوسط (Docker، خادم واحد) | لا شيء (SaaS) | منخفض (SaaS) |
| التحديثات | يدوية (foundryctl) | تلقائية | تلقائية |
| الدعم | مجتمع + خطة مدفوعة | مدفوع (مضمّن) | مجتمع + خطة مدفوعة |
استكشاف الأخطاء المتعمق
الواجهة لا تُحمَّل على المنفذ 8080: تحقق من أن حاوية signoz-frontend تعمل وأن جدار الحماية يسمح بالمنفذ.
التتبعات لا تظهر: أكثر الأسباب شيوعاً هو متغير OTEL_EXPORTER_OTLP_ENDPOINT غير صحيح. تأكد أن URL يشير إلى IP العام للـVPS (وليس localhost)، وأن المنفذ 4318 لـOTLP/HTTP مفتوح. اختبار سريع:
curl -v http://<IP_VPS>:4318ردّ 405 Method Not Allowed يؤكد أن الـcollector يستمع.
حاوية ClickHouse تعيد التشغيل: أكّد بـ dmesg | grep -i oom. لتحديد استهلاك الذاكرة:
echo '<max_memory_usage>2000000000</max_memory_usage>' \
>> /etc/clickhouse-server/users.xml
docker compose restart clickhouseتوقف بدء تشغيل SigNoz: إذا ظلت حاوية signoz في حالة starting لأكثر من 5 دقائق، فـClickHouse لم يصبح جاهزاً بعد. تحقق من سجلات ClickHouse:
docker compose logs clickhouse --tail=50امتلاء القرص أو صلاحيات غير كافية على حجم البيانات هي الأسباب الأكثر شيوعاً.
