التوثيق

تتبع الأخطاء

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

الإعداد

أنشئ مشروعًا في لوحة التحكم وانسخ DSN الخاص به، ثم وجّه حزمة SDK الموجودة لديك إليه:

Sentry.init({
  dsn: "https://<key>@vitrinaengine.com/ingest/<project>",
});

هذا هو التكامل كله. تعمل أي حزمة Sentry SDK — JavaScript، Python، Ruby، Go، PHP، .NET — لأن ما نستخدمه هو بروتوكولهم على الشبكة لا شيئًا يشبهه.

المفتاح الموجود في DSN ليس سرًا. تشحنه حزمة SDK للمتصفح ضمن حزمة الصفحة، فهو يحدد المشروع ولا يمنح أي صلاحية أخرى. لا تبنِ شيئًا يفترض أنه خاص.

كيف تتحول الأخطاء إلى مشكلات

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

والمشكلة التي حللتها ثم عادت فوقعت من جديد يُعاد فتحها بوصفها ارتدادًا وتُطلق لك تنبيهًا، بدلًا من أن تضيف بصمت تكرارًا آخر إلى مشكلة مغلقة.

ملفات source map

ارفع ملفات map الخاصة بإصدار ما فيصير مكدس المتصفح المصغّر قابلًا للقراءة. ارفعها من عملية البناء لديك عبر API — انظر مرجع API.

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

أخطاء مرفقة بحادث

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

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

وفي حساب وكالة يقتصر الملخص على مساحة العمل، حتى لا يحمل حادثُ عميلٍ تتبعاتِ مكدس عميل آخر داخل رسالة بريد.

سجلات خوادمك وشبكتك

اعتبارًا من خطة Business، يقبل المشروع أيضًا السجلات التي تكتبها أجهزتك أصلًا: syslog من Linux ومن معدات Cisco وJuniper، وسجل أحداث Windows، والسجل الموحَّد في macOS. وجِّه أي ناقل سجلات تستخدمه بالفعل إلى نقطة نهاية السجلات الخاصة بمشروعك، وهي مذكورة في صفحة المشروع بجوار الـ DSN. ولا شيء يحتاج إلى تثبيت على الأجهزة نفسها.

تُخزَّن الأخطاء فقط. فمستويات syslog الأدنى من err، ومستويات Windows الأدنى من Error، وكل ما يسميه سجل macOS Default أو أهدأ منه، تُهمل قبل احتسابها أو تحصيل رسوم عليها — فلا يكلفك المضيف السليم شيئًا، ولا تملأ التحذيرات التي لا تستدعي تنبيه أحد قائمة المشكلات لديك.

تُجمَّع سجلات الأحداث كما تُجمَّع الاستثناءات: حسب البرنامج الذي أصدرها وحسب الرسالة، لا حسب المضيف. فنشرٌ معطوب على عشرين خادم ويب هو مشكلة واحدة شوهدت عشرين مرة، لا عشرون مشكلة. وحيثما تسمِّي المعدات رسائلها بنفسها نجمع حسب ذلك الاسم، فتكون واجهة معطلة مشكلة واحدة أيًّا كان المنفذ.

ولأن سطر السجل يتكرر أكثر بكثير من الاستثناء، نحتفظ بمثال واحد لكل مشكلة في الساعة ونعدّ الباقي. عدد المرات والرسم البياني دقيقان؛ وما لا تحصل عليه هو نسخة منفصلة من السطر المئة المطابق.

الحصص

لكل خطة حصة شهرية من الأحداث — 5,000 على Free، و50,000 على Starter، و250,000 على Pro، و1,000,000 على Business. كما أن الاستقبال محدود المعدل لكل مشروع، وهي الحالة التي تقع فعلًا: فاستثناء داخل حلقة إعادة محاولة يستطيع لولا ذلك أن يحرق حصة شهر كامل في دقائق.

وتُحفظ الأحداث الفردية طوال مدة الاحتفاظ بالأخطاء في خطتك — سبعة أيام على Free، وثلاثون على Starter، وستون على Pro، وتسعون على Business. أما المشكلات المبنية منها فتبقى بعد زوال الأحداث: تظل أعدادها وأول وآخر ظهور لها ما بقيت مدة الاحتفاظ بالسجل في خطتك.

ما الذي لا نفعله

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