New Relic وتكلفة التنبيه الذي يستحق الاستيقاظ لأجله

الملخص

• تقدم New Relic مساراً متماسكاً من الوكلاء وبيانات OpenTelemetry عبر NRDB وشروط تنبيه NRQL ونماذج الكشف عن الشذوذ وعمليات الربط والتنبيه. يمكن لذلك أن يحل محل المراقبة اليدوية للوحات المعلومات ويقصر مدة التحقيق، ولكن لا يمكن اكتشاف سوى الإشارات التي تم جمعها وتسميتها والاحتفاظ بها والاستعلام عنها بشكل صحيح.
• تحدد وثائق المنصة ذاتها الظروف التي تعقد التشغيل العادي: قد تفشل طلبات بيانات القياس المقبولة لاحقاً في التحقق، وقد تحذف التتبعات المأخوذة بالعينات امتدادات، وقد يتم تقييم البيانات المتفرقة أو المتأخرة بشكل غير صحيح، وقد يؤدي تحرير شرط إلى إعادة تعيين تقييمه وسجل الشذوذ، وقد تؤدي خيارات الكتم أو التوجيه إلى كتم التنبيه الذي توقعه المشغل.
• تبلغ دراسات الحالة الخاصة بالبائع عن انخفاضات كبيرة في حجم التنبيهات ووقت الحل، بينما يربط تحليل New Relic لعام 2026 الحسابات الممكنة بالذكاء الاصطناعي بضوضاء أقل وإغلاق أسرع للمشكلات. هذه مؤشرات موثوقة على الاستخدام الإنتاجي، وليست تقديرات مضبوطة للتأثير الذي سيحصل عليه عميل جديد؛ إذ تظل جودة الأجهزة ونضج الفريق والاختيار في الميزات المتقدمة عوامل مربكة.
• تستخدم حالة شراء سليمة التكلفة لكل تنبيه قابل للتنفيذ: رسوم المنصة والبيانات والأجهزة وحوكمة الاستعلام والضبط والفرز ومراجعة الحوادث وتكلفة الترحيل مقسومة على التنبيهات التي تحدد حالة حقيقية وتصل إلى المالك المناسب في الوقت المناسب وتدعم إجراءً مفيداً. تبقى حالات الفشل المؤثرة على العملاء التي لم يتم اكتشافها في المقام على أنها فشل، حتى لو لم تولد أي تنبيه.

التنبيه هو نهاية سلسلة، وليس البداية

يبدأ أبسط عرض توضيحي لـ New Relic برسم بياني. يقوم وكيل تطبيق بالإبلاغ عن أوقات الاستجابة والأخطاء؛ يرتفع خط؛ يتجاوز شرط NRQL عتبة؛ يتلقى Slack أو PagerDuty رسالة. من السهل وصف هذا التسلسل على أنه اكتشاف آلي. ومن الأصعب وصف ما كان يجب أن يظل صحيحاً حتى تستحق الرسالة اتخاذ إجراء.

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

وأخيراً، احتاج المهندس إلى سياق وسلطة كافيين للتصرف.

توفر New Relic آليات مهمة في كل مرحلة تقريباً. لكنها لا تملك الحقيقة في كل مرحلة. يظل كود العميل وعمليات الدمج السحابية ومكونات OpenTelemetry ونقل الشبكة وأدوات الحوادث الخارجية ومعرفة الخدمة البشرية جزءاً من نظام الإنتاج. لا يمكن استرداد إشارة مفقودة في المنبع بواسطة نموذج تنبيه أفضل في المصب. ولا يمكن لعتبة مكتشفة بشكل صحيح إصلاح وسم توجيه قديم. ولا يمكن لملخص مشكلة مقنع أن يجعل خدمة غير مملوكة قابلة للتنفيذ.

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

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

تملك New Relic المنصة، وليس نموذج خدمة العميل

New Relic هي شركة مراقبة عريقة وليست مجرد غلاف تنبيهات جديد. وصفآخر تقرير سنوي لها كشركة عامةمنصة تجمع بين المقاييس والأحداث والسجلات والتتبعات مع أدوات تحليلية، وأعلن عن إيرادات للسنة المالية 2023 بلغت 925.6 مليون دولار، وقال إنها تخدم أكثر من 16000 عميل مدفوع. كما أشار الإيداع إلى Datadog وDynatrace كمنافسين مباشرين في مجال المراقبة الموحدة، وأقر بأن المؤسسات الكبيرة يمكنها بناء قدراتها الخاصة. في نوفمبر 2023،أكملت Francisco Partners وTPG استحواذاً بقيمة 6.5 مليار دولار، توقفت بعدها أسهم New Relic عن التداول العام.

حدود المنتج واسعة ولكن لا يزال من الممكن تحديدها. تشغل New Relic منصة البيانات والتحليلات المستضافة، NRDB، NRQL، وكلائها الخاصين، التنبيهات، لوحات المعلومات، ذكاء الحوادث، وتهيئة الإشعارات. وتستقبل بيانات القياس المنتجة عبر منظومة OpenTelemetry المحايدة للبائع بالإضافة إلى عمليات الدمج الأخرى. OpenTelemetry بحد ذاته مشروع CNCF به واجهات برمجة تطبيقات (APIs) ومكتبات تطوير (SDKs) واتفاقيات دلالية وبروتوكول OTLP وجامع؛ وهو ليس منتجاً لـ New Relic. وتظل PagerDuty وSlack وServiceNow وJira وخدمات السحابة وكتيبات تشغيل العملاء أنظمة منفصلة حتى عندما ترسل New Relic البيانات إليها.

هذا التمييز مهم عند إسناد كل من النجاح والفشل. إذا قام وكيل New Relic بتجهيز إطار عمل مدعوم تلقائياً وكشف عن خطأ لم يتمكن الفريق من رؤيته سابقاً، فإن الوكيل والمنصة يستحقان الفضل الحقيقي. إذا أسقط جامع OpenTelemetry البيانات لأن طابوره صغير جداً، فلا يمكن أن يُعزى فشل الاكتشاف إلى NRDB فقط. إذا أنشأت New Relic مشكلة ولكن سر webhook منتهي الصلاحية يمنع التسليم، فإن حساب التنبيه المستضاف عمل بينما فشلت النتيجة التشغيلية. يجب على المشتريات أن تحصي النتيجة، لأن العميل اشترى قدرة شاملة، ولكن يجب على الهندسة تحديد الطبقة الفاشلة بدقة.

الحدود القانونية والتجارية مهمة أيضاً.التزام مستوى الخدمةمن New Relic لطلبات Pro وEnterprise المؤهلة يعرف التوفر حول القدرة على تسجيل الدخول وعرض بيانات العميل، ويستهدف توفراً شهرياً بنسبة 99.8% على أساس جهود معقولة تجارياً، ويستثني أسباباً مثل تكنولوجيا العميل وخدمات الطرف الثالث ونقل الإنترنت العام. لا تتلقى الترتيبات القياسية وبعض الترتيبات القائمة على الاستخدام نفس الالتزام. وهذا وعد أضيق من "سيصل كل تنبيه مهم بشكل صحيح وفي الوقت المحدد". يحتاج المشترون إلى قراءة طلبهم الفعلي وخطة الدعم واتفاقيات الإشعارات الخارجية بدلاً من استنتاج ضمان نتائج التنبيه من توفر المنصة.

تحدد الأجهزة ما يمكن معرفته

يمكن لـ New Relic استيعاب بيانات القياس من وكلاء اللغات والبنية التحتية، ومكونات المتصفح والجوال، وعمليات الدمج السحابية، وواجهات برمجة التطبيقات، وPrometheus، وOpenTelemetry. هذا الاتساع قيم لأن العديد من الحوادث تعبر الطبقات. معدل خطأ HTTP المتزايد يكون أكثر فائدة عندما يمكن ربطه بنشر، أو انتظار قاعدة بيانات، أو مضيف مشبع، أو تبعية فاشلة. يخلق الاتساع نفسه أعمال حوكمة: المزيد من المصادر تنتج المزيد من السمات، والمزيد من اتفاقيات التسمية، والمزيد من التكلفة، والمزيد من الطرق لتعني إشارتان تبدوان متشابهتين أشياء مختلفة.

يقلل OpenTelemetry من الاحتكار في الأجهزة الملكية، لكنه لا يلغي تصميم الأجهزة. يوضحدليل موارد OpenTelemetryمن New Relic أن سمات الموارد تستخدم لتوليف الكيانات، مع كونservice.nameمطلوباً للخدمة وحقول مثلservice.instance.idموصى بها لتمييز النسخ. يغير اسم خدمة مفقود أو غير مستقر ما يظهر في الواجهة وما ينقسم التنبيه بناءً عليه. وسم البيئة الغائب من أحد عمليات النشر يمكن أن يوجه بيانات الإنتاج إلى استعلام مخصص للتجهيز، أو يتركها خارج كليهما.

حتى استجابة النقل الناجحة لا تثبت وصول بيانات قابلة للاستخدام. تقولوثائق نقطة نهاية OTLPمن New Relic إن الحمولات يجب أن تبقى أقل من واحد ميغابايت، ويجب على المصدرين التجميع بشكل مناسب وتمكين الضغط وإعادة محاولة حالات الفشل العابرة ومراعاة حدود المعدل. بشكل أكثر دقة، تستجيب نقطة النهاية بعد التحقق من المصادقة وحجم الحمولة وتحديد المعدل، بينما يحدث التحقق من المحتوى بشكل غير متزامن. لذلك يمكن أن تسبق حالة النجاح فشل استيعاب يسجل لاحقاً كـNrIntegrationError. المشغل الذي يتحقق فقط من نجاح HTTP قد تحقق من التسليم إلى الباب الأمامي، وليس من بيانات قياس قابلة للاستعلام.

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

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

الأجهزة هي أيضاً برامج تتغير. تضيف إصدارات الوكلاء دعماً للأطر، وتغير الإعدادات الافتراضية، وتصلح العيوب. تتطور اتفاقيات OpenTelemetry الدلالية. تشير New Relic إلى أن التحول من الأجهزة الأصلية إلى واجهات برمجة تطبيقات OpenTelemetry يمكن أن ينتج أسماء امتدادات أو مقاييس مختلفة لأنظمة مثل Elasticsearch وRabbitMQ، مما قد يكسر لوحات المعلومات والتنبيهات التي تعتمد على أسماء دقيقة. لذلك يحتاج برنامج الترقية إلى اختبارات عقد بيانات القياس: انشر معاملة معروفة وخطأ واستدعاء تبعية؛ تحقق من السمات المتوقعة وارتباط الكيان؛ وقارن استعلام التنبيه قبل ترقية تهيئة الوكيل أو الجامع الجديدة.

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

تحول NRQL الحكم التشغيلي إلى شروط قابلة للتنفيذ

NRQL هي واحدة من أقوى ميزات New Relic لأنها تتيح للفرق التعبير عن منطق الكشف عبر مخزن بيانات مشترك. يمكن للشرط مراقبة نسبة خطأ، أو نسبة مئوية لزمن الاستجابة، أو عمق طابور، أو عدد حدث عمل، أو أي نتيجة رقمية مشتقة من بيانات القياس تقريباً. يمكن للتقسيم تطبيق شرط واحد عبر العديد من الخدمات أو المضيفين أو المستأجرين. هذا أكثر مرونة من كتالوج إنذارات البنية التحتية الثابتة ويمكنه ربط السلوك التقني بمعاملة تجارية.

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

تنبيه NRQL ليس أيضاً مجرد رسم بياني يعمل كل دقيقة. تصفوثائق التنبيه المتدفقمن New Relic ثلاث طرق تجميع. تدفق الأحداث، الافتراضي، يناسب البيانات المتكررة والمرتبة غالباً. مؤقت الأحداث يناسب البيانات التي تصل بشكل غير منتظم أو على دفعات. الإيقاع يستخدم ساعة حائط New Relic وتصفه الشركة بأنه الخيار الأقدم والأقل جودة. يتم تصفية البيانات، وجمعها في نافذة تجميع، ويسمح لها بتأخير إضافي أو مؤقت، وضغطها في قيمة، ثم اختبارها لمدة عتبة.

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

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

لغة الاستعلام لها حدود صريحة.LIMITغير متوافقة مع تنبيهات NRQL لأنه يتم تقييم مجموعة النتائج الكاملة. الاستعلامات الفرعية وصلات الاستعلامات الفرعية غير متوافقة مع التنبيهات المتدفقة لأنها تحتاج إلى تمريرات بيانات متعددة. حدود الحساب والشرط مهمة أيضاً: تدرج الوثائق الحالية 4000 شرط تنبيه لكل حساب، و20000 قسم لكل شرط NRQL، و300 مليون نقطة بيانات مطابقة في الدقيقة، و2.5 مليار عملية مسح استعلام في الدقيقة. يمكن أن تزيد النوافذ المنزلقة النقاط المطابقة بشكل كبير، وفي بعض خطط الحوسبة، تضيف رسوماً استهلاكية.

هذه سقوف سخية للعديد من المؤسسات، لكن التداعيات التصميمية تصل قبل الحد الأقصى الصعب. إدارة واختبار وتوجيه شرط مقسم عبر آلاف الأبعاد المتقلبة أصعب من تنبيه على مستوى الخدمة محدد النطاق عن عمد. لذلك يجب أن تسأل حوكمة الاستعلام ليس فقط عما إذا كانت NRQL تقبل التعبير، ولكن أي مجموعة يمثلها، وكيف يتصرف مقامه، وماذا يحدث عند انعدام الحركة، وكم عدد الإشارات المميزة التي يخلقها، وأي فريق يملك كل واحدة.

يتعلم كشف الشذوذ التاريخ ويرث غموضه

العتبات الثابتة سهلة الشرح وصعبة التعميم. قد تكون عتبة زمن استجابة بخمس ثوان غير مقبولة للدفع وطبيعية لتقرير ليلي. تختلف الحركة عند الظهر عنها عند منتصف الليل. تعالج شروط الشذوذ في New Relic هذا بالتنبؤ بالقيمة التالية من السلوك السابق وفتح تنبيه عندما تبقى الملاحظات بعيدة بما يكفي عن التنبؤ. يتم التعبير عن الحساسية من خلال المسافة من القيمة المتوقعة، بينما يتحكم الاتجاه والمدة في أي الانحرافات تحتسب.

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

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

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

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

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

يمكن أن تبدو بيانات القياس المفقودة سليمة أو مكسورة أو مجرد متأخرة

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

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

تعقد الكثافة الأساسية المشكلة. تعرف سلسلة زمنية مترية باسمها ومجموعة السمات الفريدة. يمكن لإضافة قيم عميل أو طلب أو حاوية أو معرف غير محدود أن تضاعف عدد السلاسل بشكل كبير. تصف New Relic حالياً ميزانية كثافة أساسية يومية تبلغ 15 مليون لكل حساب وميزانية افتراضية تبلغ 100000 لكل مقياس، مع توسيع مدفوع وعناصر تحكم في التقليم. عند الوصول إلى الحدود، يختلف السلوك حسب الحد؛ تقول وثائق حدود البيانات إن بعض تجاوزات معدل الطلبات تتلقى استجابات 429، بينما يمكن لبلوغ حد الكثافة الأساسية المترية أن يوقف البيانات المجمعة لبقية اليوم بالتوقيت العالمي المنسق على الرغم من أنه قد تظل البيانات الخام مخزنة.

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

يوضح تاريخ حالة المنصة في 2026 لماذا يجب قياس هذه الطبقة بدلاً من افتراضها. يسجلموجز الحوادث العامةلـ New Relic حلقات تتضمن إشعارات تنبيه متأخرة أو مفقودة، وتنبيهات كاذبة، وإشعارات فقدان إشارة كاذبة، وتشوهات في بيانات القياس. في20 مارس 2026، على سبيل المثال، قالت الشركة إن بعض عملاء منطقة الولايات المتحدة المستخدمين لعمليات دمج Azure قد تلقوا أخطاء وإشعارات متأخرة أو مفقودة وبيانات متأثرة محتملة غير قابلة للاسترداد. في18 مايوأبلغت أن انقطاعاً من مزود سحابي خارجي تسبب في تأخر البيانات وتأخر أو فقدان أو خطأ في الإشعارات لبعض عملاء الولايات المتحدة والاتحاد الأوروبي. في21 ينايرسجلت أكثر من أربع ساعات حيث يمكن أن تشهد مجموعة فرعية من عملاء الولايات المتحدة إشعارات فورية متأخرة أو مفقودة.

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

يمكن أن يكون هذا الفحص الخارجي شاشة اصطناعية خفيفة موجهة بشكل مستقل، أو إنذاراً سحابياً أصلياً للمورد الأكثر أهمية، أو نبض قلب استيعابي مراقب خارج New Relic، أو إشارة رحلة مستخدم من مزود آخر. تكرار كل تنبيه سيعيد خلق الضوضاء والتكلفة. حماية مجموعة صغيرة من المسارات الوجودية تخلق تحكماً مفيداً دون إعادة بناء المنصة بأكملها.

الربط يقلل من التفرع لكنه لا يستطيع إثبات السبب المشترك

يمكن لحادث كبير أن يخلق تنبيهاً واحداً لكل مضيف وخدمة ومنطقة وعرض. تحويل التنبيه لكل حدث بشكل منفصل يحول الفشل التقني إلى فشل انتباه. تقوم معلومات الحوادث من New Relic بتجميع أحداث التنبيه في مشكلات ويمكنها تطبيق قرارات ربط مبنية أو مقترحة أو معرفة من قبل العميل بناءً على الوقت والسمات وتشابه النص وعلاقات الكيانات. يمكنها محاكاة قرار مقترح مقابل البيانات الحديثة قبل التفعيل.

هذا يعالج حاجة حقيقية. توصيإرشادات SRE من Googleبأن تقترب التنبيهات المزعجة من علاقة واحد لواحد مع الحوادث وتحذر من أن التنبيهات المتكررة منخفضة الأولوية يمكن أن تجعل التنبيهات الخطيرة تتلقى اهتماماً أقل. وجدتدراسة صناعية لمدة عامين لأكثر من أربعة ملايين تنبيه من Huawei Cloudبالمثل أوصافاً غير واضحة وخطورة مضللة واستراتيجيات قديمة وتأرجحاً وعواصف جماعية؛ ولا يزال يتعين على مهندسيها إعادة تهيئة الحظر والتجميع والربط بعد تغير الخدمات أو استراتيجيات التنبيه.

يمكن لآلية الربط من New Relic إجراء ذلك التجميع على نطاق المنصة. تشمل قراراتها الموثقة تجميع الأحداث من نفس نشر Kubernetes أو التطبيق أو الشاشة الاصطناعية، بالإضافة إلى قواعد قائمة على التشابه وعلاقات الطبولوجيا. تمنح فترة سماح تصل إلى 20 دقيقة النظام وقتاً لجمع وربط النشاط قبل الإشعار. الفائدة هي عناصر عمل مجزأة أقل وسياق أكثر على صفحة مشكلة واحدة.

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

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

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

التوجيه هو جزء من موثوقية الكشف

بمجرد أن يفتح شرط حدث تنبيه ويشكل الربط مشكلة، تقوم سير عمل New Relic بتصفية أحداث المشكلة وإرسال محفزات مختارة إلى الوجهات. يمكنها إثراء إشعار بنتائج NRQL واستهداف البريد الإلكتروني، Slack، PagerDuty، ServiceNow، Jira، webhooks أو عمليات دمج أخرى. يمكن للوسوم توجيه خدمة إلى فريقها. يمكن أن تختلف محفزات الإشعار للتفعيل، الإقرار، التحقيق، الإغلاق، تغيير الأولوية والتحديثات اللاحقة.

هذا قوي لأن الكشف بدون ملكية هو مجرد سجل. وهو أيضاً سطح تهيئة آخر. قد لا يعود مرشح سير العمل مطابقاً بعد تغيير سياسة أو وسم. يمكن أن تنتهي صلاحية بيانات اعتماد الوجهة. قد لا يتحقق مستلم بريد إلكتروني من عنوان. قد تتغير حمولة webhook. قد يعيد استعلام إثراء بيانات فارغة. يستخدم اختبار سير عمل New Relic مشكلة مطابقة موجودة، لذا يمكن لتهيئة بدون تاريخ ذي صلة أن تعرض أنها لم تجد تطابقاً دون إثبات ما إذا كان المسار المستقبلي سيعمل.

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

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

نتائج العملاء مشجعة ومختارة

تنشر New Relic أمثلة مسماة مفصلة لفرق تقلل من عبء التنبيه. يقولحساب عميل PicPayإنه قلص حجم الحوادث بنسبة 65%، ووقت الحل الوسطي بنسبة 30%، ووقت التعطل السنوي بنسبة 51% بعد وضع معايير التنبيه ومركزة السجلات. تقولViewpointإنها قللت ضوضاء التنبيه الأسبوعية من أكثر من 3500 إلى أقل من 600 ووفرت 57% مقارنة بحل المراقبة السابق. يبلغThe Access Groupعن انخفاض بنسبة 99% في ضوضاء التنبيه إلى حوالي تسعة تنبيهات يومياً ويصف تحقيقات تستغرق حوالي عشر دقائق بعد الضبط والدمج.

هذه الحسابات مهمة. إنها تحدد العملاء وأحمال العمل والأرقام قبل وبعد والممارسين. إنها تظهر أن New Relic يمكن تضمينها في عمليات إنتاج كبيرة وأن ترشيد التنبيه يمكن أن يحقق مكاسب كبيرة. كما تظهر أن النتيجة لم تكن مفتاحاً قلبته نموذج شذوذ. وضعت PicPay معايير تنبيه المنصة ومركزت السجلات. قامت Viewpoint بتجهيز تطبيقات Kubernetes ووسعت الوصول عبر الوظائف. قام The Access Group بضبط التنبيهات بدقة واستخدم الكتم وأضاف أجهزة عمل. العمل التنظيمي هو جزء من النتيجة.

الدليل مختار من قبل البائع ويفتقر إلى مقامات مهمة. لا تقدم الصفحات أسعار العقود أو ساعات التنفيذ الهندسي أو مجموعة تحكم مطابقة أو فترات ثقة أو حوادث هاربة أو تعدادات سلبية كاذبة أو الجزء من التحسن الذي تسببت فيه New Relic بدلاً من الدمج وإعادة تصميم العمليات. قد يتم تعريف "ضوضاء التنبيه" أيضاً بشكل مختلف من قبل كل عميل. يمكن أن يكون الانخفاض من 3500 إلى 600 إشعار ممتازاً، لكنه غير مكتمل دون معرفة ما إذا كانت حالات الفشل التي اكتشفها العميل قد انخفضت أيضاً.

يقدمتقرير تأثير الذكاء الاصطناعي لعام 2026من New Relic رؤية رصدية أوسع بكثير. يقول إن التحليل يغطي استخداماً مجمعاً ومجرد الهوية لحوالي 6.6 مليون مستخدم نشط خلال عام 2025. كان لدى الحسابات الممكنة بالذكاء الاصطناعي ما يقرب من 46% تنبيهات مزعجة مقابل 63% للحسابات غير الممكنة، وحوالي ضعف معدل ربط المشكلات، ووقت أقل بنسبة 25% تقريباً للإغلاق الوسطي. في مايو، كان المتوسطان المبلغان 26.75 دقيقة و50.23 دقيقة على التوالي.

المقياس يجعل الارتباط مثيراً للاهتمام، وليس سببياً. يجمع التقرير الميزات التوليدية وتعلم الآلة والحتمية تحت "New Relic AI". لا ينشر توزيعاً عشوائياً أو أعداد حسابات في كل مجموعة أو طرق مطابقة أو تعقيد خدمة أو نضج فريق أو مزيج خطورة أو اتفاقيات إغلاق أو نتائج سلبية كاذبة. الفرق التي تمكن الميزات المتقدمة قد تستثمر أيضاً أكثر في الأجهزة وممارسة الحوادث. وقت الإغلاق الوسطي ليس بالضرورة وقت الاسترداد؛ يمكن إغلاق مشكلة تلقائياً أو يدوياً أو بالسياسة دون إثبات أن المستخدمين تعافوا.

التفسير الصحيح هو أن الربط والمساعدة المتكاملين مساهمان محتملان في جهد تشغيلي أقل، وترى New Relic ارتباطاً ثابتاً في ممتلكاتها الخاصة. لا ينبغي للمشتري أن يضع 25% في نموذج عائد استثمار كتوفير مضمون. يجب أن يقيس المراحل نفسها محلياً: بدء الإشارة، فتح الحدث، تسليم الإشعار، الإقرار، بدء التحقيق، التخفيف، استرداد الخدمة وإغلاق المشكلة. عندها فقط يمكنه تحديد الدقائق التي أزالتها New Relic.

تكشف تكلفة التنبيه القابل للتنفيذ أين انتقل العمل

يجعل نموذج New Relic التجاري حجم بيانات القياس ووصول المستخدم مرئياً.شروط القائمة العامة الحاليةتتضمن 100 جيجابايت من الاستيعاب الشهري بدون رسوم، ثم تدرج البيانات الأصلية بسعر 0.40 دولار لكل جيجابايت وData Plus بسعر 0.60 دولار لكل جيجابايت، إلى جانب رسوم المستخدم والحوسبة المتقدمة. يمكن أن تتغير الأسعار العامة وتختلف التزامات المؤسسات، لذا هذه الأرقام هي نقاط مرجعية وليست عروض أسعار. تغير Data Plus أيضاً الاحتفاظ وحدود الاستعلام، مما يعني أن التكلفة مرتبطة بكمية التاريخ التي يمكن للتحقيق فحصها.

الفاتورة المباشرة هي جزء واحد فقط من اقتصاديات التنبيه. معادلة شهرية مفيدة هي:

تكلفة التنبيه القابل للتنفيذ = (المنصة + الاستيعاب + الاحتفاظ + الحوسبة + الأجهزة + عمليات التجميع + حوكمة الاستعلام + ضبط التنبيه + صيانة التوجيه + الفرز + مراجعة الحوادث + التدريب + استهلاك الترحيل) / التنبيهات القابلة للتنفيذ

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

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

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

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

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

تنتمي تكلفة الترحيل إلى الحساب حتى عندما يحسن OpenTelemetry القابلية للنقل. الأجهزة المكتوبة مقابل واجهات برمجة تطبيقات مفتوحة يمكنها إرسال البيانات إلى خلفية أخرى، لكن شروط NRQL ولوحات المعلومات وقرارات المشكلات وقواعد الكتم ومرشحات سير العمل وخطوط الأساس التاريخية وعادات التحقيق هي أصول خاصة بـ New Relic. بيانات القياس المصدرة لا تترجم تلقائياً المعنى التشغيلي المضمن فيها. يتطلب الخروج المستقبلي تشغيلاً متوازياً وترجمة قواعد وإعادة تدريب وإثباتاً بأن البديل يكتشف نفس حالات الفشل.

يستخدم التقييم الجاد حالات الفشل العادية ويحتفظ بكل محاولة

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

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

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

شغل تكرارات كافية لعبور التغيير الروتيني: ترقية وكيل، نشر، حدود دورة حركة، نهاية أسبوع، إعادة تشغيل جامع، وتحرير شرط. تحتاج شروط الشذوذ وقتاً للتعلم، لذا يجب أن يقارن الاختبار الفترات الباردة والناضجة. كرر مع تأخر بيانات القياس وغيابها جزئياً. بالنسبة للربط، اخلق فشلاً واحداً بعدة أعراض وفشلين متزامنين غير مرتبطين؛ قس كلاً من التجميع والدمج الضار. بالنسبة للتوجيه، اختبر تحديثات الإقرار والإغلاق بالإضافة إلى التفعيل الأولي.

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

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

توضح البدائل ما الذي تدفع له New Relic لتفعله

تنافس New Relic منصات تجارية متكاملة تشمل Datadog وDynatrace وSplunk Observability وElastic، بالإضافة إلى خدمات سحابية أصلية ومكونات مفتوحة المصدر. المقارنة ذات الصلة ليست جرداً للميزات. إنها من يشغل مخزن البيانات، وعمليات الدمج، والترقيات، والتوسع، ونظام الاستعلام، وتقييم التنبيهات، والربط، والدعم، وكم يصل من السياق إلى مهندس.

يفصل Prometheus تقييم التنبيه عنAlertmanager، الذي يجمع ويوجه ويكبت ويسكت التنبيهات. يمكن لـ Grafana توفير لوحات معلومات وتنبيهات عبر مصادر البيانات؛ يغطي Loki وTempo السجلات والتتبعات؛ يمكن لـ OpenTelemetry توحيد التجميع. يمكن أن تكون هذه المجموعة فعالة وشفافة ومحمولة. كما تترك العميل مسؤولاً عن السعة والتوفر العالي والاحتفاظ والترقيات والربط بين الإشارات والواجهات بين المكونات ما لم يتولها مزود مدار.

يمكن أن تكون الإنذارات السحابية الأصلية أبسط لحمل عمل مركز في AWS أو Azure أو Google Cloud. قد ترى مقاييس المنصة بدون وكيل آخر وتوفر رجوعاً مستقلاً. تصبح أقل تماسكاً عبر سحابات وتطبيقات وأحداث أعمال متعددة. يمكن لمتتبع أخطاء متخصص أن يتفوق على منصة واسعة لسير عمل استثناءات المطورين مع ترك أدلة البنية التحتية ومستوى الخدمة في مكان آخر.

يمكن أن تكون المعمارية العقلانية هجينة. استخدم New Relic لتحليل التطبيقات الواسع وعبر المكدس، وOpenTelemetry حيث تكون القابلية للنقل والتحكم مهمين، وإنذاراً مستقلاً لبعض المسارات الحرجة. أبق الفحوصات الاصطناعية على مستوى العمل منفصلة عن تنبيهات الأعراض الداخلية. استخدم مقاييس محلية أو سحابية أصلية عندما يكون لتصدير كل التفاصيل عالية الحجم قيمة إضافية قليلة. الهدف ليس نقاء الأداة؛ بل هو كشف موثوق بملكية وتكلفة مفهومة.

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

ما الدليل الذي سيغير الحكم

أقوى دليل مفقود هو موثوقية على مستوى الشروط عبر مهام متكررة ومفصح عنها. يمكن لـ New Relic تقوية الحجة مادياً بنشر توزيعات الدقة والاستدعاء ووقت الكشف للشروط الثابتة والشذوذ والقيم الشاذة عبر مجموعات بيانات معنونة، مع فترات بدء بارد وبيانات متأخرة وبيانات مفقودة وتغييرات موسمية وتحريرات مدرجة. يجب أن تبلغ نتائج الربط عن عمليات الدمج الضارة والمجموعات المفقودة، وليس فقط نسبة الأحداث المربوطة.

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

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

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

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

الحكم: اشتر نظام الكشف، وخصص ميزانية لحراسه

تقدم New Relic منصة مراقبة كبيرة تقنياً. طبقة البيانات المشتركة، وNRQL التعبيرية، والأجهزة الواسعة، والتقييم المتدفق، وكشف الشذوذ، وربط الحوادث، وسير العمل يمكنها أن تحل محل المشاهدة اليدوية والبحث المجزأ في الأدوات. يبلغ العملاء المسمون عن انخفاضات كبيرة في الضوضاء ووقت الحل. يقلل دعم OpenTelemetry من مصدر مهم للاحتكار، والوثائق صريحة بشكل غير عادي حول البيانات المتأخرة وإعادة التعيين والحدود والإشارات المفقودة.

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

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

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