ملخص
- توفر New Relic مسارًا مترابطًا من الوكلاء وبيانات OpenTelemetry عبر NRDB وشروط تنبيه NRQL ونماذج الشذوذ والربط وسير عمل الإشعارات. يمكن أن يحل ذلك محل مراقبة لوحات التحكم اليدوية ويختصر التحقيق، ولكن فقط الإشارات التي تم جمعها وتسميتها والاحتفاظ بها والاستعلام عنها بشكل صحيح يمكن اكتشافها.
- تحدد وثائق المنصة نفسها الظروف التي تعقد التشغيل العادي: طلبات القياس المقبولة يمكن أن تفشل لاحقًا في التحقق من الصحة، والتتبع المأخوذ منه عينات يمكن أن يحذف الامتدادات، والبيانات المتناثرة أو المتأخرة يمكن تقييمها بشكل غير صحيح، وتحرير شرط يمكن أن يعيد تعيين تقييمه وتاريخ الشذوذ، وخيارات الكتم أو التوجيه يمكن أن تمنع التنبيه الذي توقعه المشغل.
- تشير دراسات الحالة من البائعين إلى تخفيضات كبيرة في حجم التنبيهات ووقت الحل، بينما يربط تحليل New Relic لعام 2026 الحسابات الممكّنة بالذكاء الاصطناعي بانخفاض الضوضاء وإغلاق أسرع للمشكلات. هذه علامات موثوقة على الاستخدام الإنتاجي، وليست تقديرات مضبوطة للتأثير الذي سيحصل عليه عميل جديد؛ تظل جودة القياس ونضج الفريق والاختيار للميزات المتقدمة عوامل مربكة.
- قضية شراء سليمة تستخدم التكلفة لكل تنبيه قابل للتنفيذ: رسوم المنصة والقياس، والأدوات، وحوكمة الاستعلام، والضبط، والفرز، ومراجعة الحوادث، وتكلفة الترحيل مقسومة على التنبيهات التي تحدد حالة حقيقية، وتصل إلى المالك المناسب في الوقت المناسب، وتدعم إجراءً مفيدًا. تظل حالات الفشل المؤثرة على العميل والتي لم يتم التقاطها في المقام كحالات فشل، على الرغم من أنها لم تولد أي تنبيه.
التنبيه هو نهاية السلسلة، وليس البداية
أبسط عرض لـ New Relic يبدأ برسم بياني. يُبلغ وكيل التطبيق عن أوقات الاستجابة والأخطاء؛ يرتفع خط؛ يعبر شرط NRQL حدًا؛ يتلقى Slack أو PagerDuty رسالة. من السهل وصف هذا التسلسل على أنه كشف آلي. لكن من الأصعب وصف ما يجب أن يظل صحيحًا لكي تستحق الرسالة إجراءً.
كان على التطبيق إصدار دليل على الفشل. كان على الوكيل أو المجمع الحفاظ على الحقول المفيدة وتسليمها. كان على أسماء الخدمات والسمات الأخرى تحديد المكون الإنتاجي الصحيح. كان على NRDB الاحتفاظ بالسجلات التي يتوقعها الاستعلام وكشفها. كان على الاستعلام تمثيل الضرر الذي يلحق بالمستخدم وليس مجرد حالة داخلية غير عادية. كان على نافذة التجميع ومعالجة البيانات المتأخرة أو الغائبة أن تناسب المصدر. كان على حد ثابت أو خط أساس متعلم التمييز بين التباين العادي والمشكلة. كان على الربط تجميع الأعراض دون دمج حالات الفشل غير ذات الصلة. كان على سير العمل مطابقة المشكلة الناتجة، وكانت بيانات اعتماد الوجهة وملكية الاستدعاء بحاجة إلى أن تكون حديثة.
أخيرًا، كان المهندس بحاجة إلى سياق وسلطة كافيين للتصرف.
توفر New Relic آليات مهمة في كل مرحلة تقريبًا. لكنها لا تملك الحقيقة في كل مرحلة. تظل شيفرة العميل، وتكاملات السحابة، ومكونات OpenTelemetry، وتسليم الشبكة، وأدوات الحوادث من طرف ثالث، ومعرفة الخدمة البشرية جزءًا من نظام الإنتاج. الإشارة المفقودة في المنبع لا يمكن تعويضها بنموذج تنبيه أفضل في المصب. الحد المكتشف بشكل صحيح لا يمكنه إصلاح علامة توجيه قديمة. ملخص مقنع للمشكلة لا يمكنه جعل خدمة غير مملوكة قابلة للتنفيذ.
لهذا السبب، المقام المفيد ليس أحداث التنبيهات التي تم إنشاؤها. إنه التنبيهات القابلة للتنفيذ: الإشعارات التي تتوافق مع حالة حقيقية تتطلب الانتباه، وتصل مبكرًا بما يكفي لتحسين النتيجة، وتصل إلى مالك مناسب، وتحتوي على أدلة كافية لبدء التشخيص وتؤدي إلى إجراء مبرر. هذا التعريف متطلب عمدًا. إنه يمنح الائتمان للأتمتة فقط عندما تغير الأتمتة العمل.
كما يكشف عن خطأين مختلفين. التنبيه الخاطئ أو منخفض القيمة يستهلك الانتباه دون تحسين الخدمة. التنبيه المفقود يسمح للضرر بالاستمرار حتى يلاحظه مستخدم أو جهاز مراقبة آخر أو مهندس. ضبط الحساسية عادة ما يوازن بين الاثنين. زيادة المدة أو التأخير يمكن أن تقمع الضوضاء العابرة مع تمديد وقت الكشف. تضييق نطاق الشذوذ يمكن أن يكشف عن انحرافات أصغر مع زيادة التنبيهات. لا يوجد إعداد عالمي يمكنه حسم هذه المقايضة لأن تكلفة فشل دفعة مفقودة تختلف عن تكلفة تباطؤ مهمة خلفية قصير.
New Relic تمتلك المنصة، وليس نموذج خدمة العميل
New Relic هي شركة مراقبة راسخة منذ فترة طويلة وليست غلاف تنبيه جديد.تقريرها السنوي الأخير كشركة عامةوصف منصة جمعت بين المقاييس والأحداث والسجلات والتتبعات مع أدوات تحليلية، وأبلغ عن إيرادات السنة المالية 2023 بقيمة 925.6 مليون دولار وقال إنها تخدم أكثر من 16,000 عميل مدفوع. كما ذكر الإيداع Datadog و Dynatrace كمنافسين مباشرين في المراقبة الموحدة، وأقر بأن المؤسسات الكبيرة يمكنها بناء قدراتها الخاصة. في نوفمبر 2023،أكملت Francisco Partners و TPG استحواذًا بقيمة 6.5 مليار دولار، وبعد ذلك توقفت أسهم New Relic عن التداول العام.
حدود المنتج واسعة ولكنها لا تزال قابلة للتحديد. تدير New Relic منصة البيانات والتحليل المستضافة، NRDB، NRQL، وكلائها الخاصين، والتنبيه، ولوحات التحكم، وذكاء الحوادث، وتكوين الإشعارات. تقبل القياسات المنتجة من خلال نظام OpenTelemetry المحايد للبائعين بالإضافة إلى تكاملات أخرى. OpenTelemetry نفسه هو مشروع CNCF مع واجهات برمجة تطبيقات، ومجموعات تطوير برمجيات، واتفاقيات دلالية، وبروتوكول 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 لأنها تسمح للفرق بالتعبير عن منطق الكشف عبر مخزن بيانات مشترك. يمكن لشرط مراقبة نسبة خطأ، أو نسبة مئوية من زمن الاستجابة، أو عمق قائمة انتظار، أو عدد حدث تجاري، أو أي نتيجة رقمية مشتقة من القياسات. التصنيف يمكنه تطبيق شرط واحد عبر العديد من الخدمات أو المضيفين أو المستأجرين. هذا أكثر مرونة من كتالوج منبهات البنية التحتية الثابتة ويمكنه ربط السلوك التقني بمعاملة تجارية.
المرونة تنقل المسؤولية إلى تصميم الاستعلام. المتوسط يمكن أن يخفي مجموعة صغيرة من المستخدمين المتضررين بشدة. النسبة المئوية يمكن أن تصبح غير مستقرة عند حركة المرور المنخفضة. العدد يمكن أن ينخفض لأن الطلب اختفى وليس لأن الخدمة تحسنت. قسمة الأخطاء على جميع المعاملات يمكن أن تقلل من الفشل إذا كان المقام يشمل فحوصات الصحة. التصنيف بواسطة معرف جراب ephemeral يمكن أن يخلق تيارًا من الإشارات قصيرة العمر بينما وحدة التشغيل الحقيقية هي النشر. مرشح منسوخ من لوحة التحكم قد يحذف بيئة أعيدت تسميتها حديثًا.
تنبيه NRQL ليس مجرد رسم بياني يعمل كل دقيقة.توثيق التنبيهات المتدفقة من New Relicيصف ثلاث طرق تجميع. تدفق الأحداث، الافتراضي، يناسب البيانات المتكررة والمرتبة في الغالب. مؤقت الأحداث يناسب البيانات التي تصل بشكل غير منتظم أو في دفعات. الإيقاع يستخدم ساعة حائط New Relic وتصفه الشركة بأنه الخيار الأقدم والأدنى. يتم تصفية البيانات، وتجميعها في نافذة تجميع، والسماح بتأخير إضافي أو مؤقت، وضغطها إلى قيمة، ثم اختبارها لمدة عتبة.
كل إعداد يغير المكتشف. نافذة أطول تنعم الذروة لكنها يمكن أن تخفي فشلًا قصيرًا وشديدًا. تأخير أطول يعطي وقتًا للقياس المتأخر للوصول لكنه يمد الفاصل الزمني قبل التنبيه. مؤقت الأحداث يمكن أن ينتظر فترة هادئة في دفعة، بينما تدفق الأحداث يحتاج إلى طوابع زمنية لاحقة لإغلاق نافذة سابقة. إذا كان المؤقت قصيرًا جدًا للبيانات غير المتسقة، تحذر New Relic من أنه يمكن تقييم النافذة قبل وصول جميع النقاط وإنتاج إشعار غير صحيح.
النوافذ الفارغة تتطلب قرارًا آخر. ترك فجوة فارغة يمكن أن يعيد تعيين مؤقت مدة العتبة. ملؤها بصفر يمكن أن يحول البيانات المفقودة إلى صحة واضحة لاستعلام واحد وكارثة واضحة لآخر. ترحيل القيمة الأخيرة يمكن أن يحافظ على فشل قديم أو نجاح قديم. كشف فقدان الإشارة يساعد، لكنه ينشط فقط بعد وجود الإشارة؛ شرط مفعل بينما المصدر غائب بالفعل لا يمكنه اكتشاف ذلك الغياب بأثر رجعي. في شرط مصنف، كل وجه هو إشارة خاصة به، وهو قوي حتى تنتهي الكيانات العابرة كجزء من التحجيم الطبيعي.
لغة الاستعلام لها حدود صريحة.LIMITغير متوافق مع تنبيه NRQL لأنه يتم تقييم مجموعة النتائج الكاملة. الاستعلامات الفرعية وضم الاستعلامات الفرعية غير متوافقة مع التنبيهات المتدفقة لأنها تحتاج إلى تمريرات بيانات متعددة. حدود الحساب والشرط مهمة أيضًا: التوثيق الحالي يسرد 4,000 شرط تنبيه لكل حساب، و20,000 وجه لكل شرط NRQL، و300 مليون نقطة بيانات متطابقة في الدقيقة، و2.5 مليار عملية فحص استعلام في الدقيقة. النوافذ المنزلقة يمكن أن تزيد النقاط المتطابقة بشكل كبير، وفي بعض خطط الحوسبة، تضيف رسوم استهلاك.
هذه سقوف سخية للعديد من المؤسسات، لكن تأثير التصميم يصل قبل الحد الصلب. شرط مصنف عبر آلاف الأبعاد المتقلبة أصعب في الملكية والاختبار والتوجيه من تنبيه مستوى خدمة محدد النطاق بعناية. لذلك يجب على حوكمة الاستعلام أن تسأل ليس فقط ما إذا كان NRQL يقبل التعبير، ولكن أي مجموعة سكانية يمثلها، وكيف يتصرف مقامه، وماذا يحدث عند عدم وجود حركة مرور، وكم عدد الإشارات المميزة التي يخلقها، وأي فريق يملك كل واحدة.
كشف الشذوذ يتعلم التاريخ ويرث غموضه
الحدود الثابتة سهلة الشرح وصعبة التعميم. حد زمن استجابة خمس ثوان قد يكون غير محتمل للخروج من المتجر وعادي لتقرير ليلي. حركة المرور عند الظهيرة تختلف عن حركة المرور عند منتصف الليل. شروط الشذوذ في New Relic تعالج هذا من خلال التنبؤ بالقيمة التالية من السلوك السابق وفتح تنبيه عندما تبقى الملاحظات بعيدة بما يكفي عن التنبؤ. يتم التعبير عن الحساسية من خلال المسافة من القيمة المتوقعة، بينما يتحكم الاتجاه والمدة في أي انحرافات تحتسب.
توثيق الشذوذمؤهل بشكل مناسب. الإشارات الجديدة لها تاريخ قليل وتوقعات غير مستقرة. الإشارات المتسقة تنتج نطاقات أضيق؛ الإشارات غير المنتظمة تنتج نطاقات أوسع. يمكن للنظام استنتاج الموسمية تلقائيًا أو استخدام الموسمية بالساعة أو اليومية أو الأسبوعية أو بدون موسمية. الأنماط الشهرية والسنوية غير مدعومة. لذلك يمكن نمذجة دورة مبيعات أسبوعية، بينما تحتاج ذروة التجديد السنوية أو دفعة نهاية الشهر إلى تصميم آخر.
الشذوذ ليس نفس الفشل الضار. الترويج الناجح يمكن أن ينتج زيادة غير عادية في حركة المرور. النشر الذي يجعل نقطة نهاية غير فعالة بطيئة بشكل موحد قد يصبح المعيار الجديد إذا استمر. خطأ أمني أو دفعي منخفض الحجم يمكن أن يبقى داخل نطاق واسع على الرغم من أن كل occurrence مهم. على العكس، دفعة متوقعة يمكن أن تنبه إذا كانت الموسمية خاطئة. النموذج يكتشف الانحراف عن السلوك المكتسب؛ العميل يقرر ما إذا كان السلوك المكتسب مقبولًا وما إذا كان الانحراف يتطلب مقاطعة.
صيانة الشرط تخلق حد موثوقية مهم بشكل خاص. تنص New Relic على أن تغيير استعلام أو طريقة تجميع أو نافذة أو تأخير أو ملء فجوة أو اتجاه شذوذ أو عتبة أو فاصل زمني منزلق يعيد تعيين تقييم شرط NRQL. للحدود المستندة إلى المدة، يخلق ذلك على الأقل فترة الانتظار المكونة قبل أن يتم فتح حدث جديد. لشروط الشذوذ، يتم فقدان كل تعلم الشذوذ ويبدأ من جديد. التعديل حسن النية الذي يتم قبل إصدار محفوف بالمخاطر يمكن أن يخلق فترة عمياء أو غير مستقرة بالضبط عندما تكون الثقة مطلوبة.
هذا يجعل تكوين التنبيه أصلًا مُدارًا بالتغيير. يجب أن تسجل التعديلات السبب والقيم السابقة والتأثير المتوقع والمالك. يجب على الفريق معاينة الإشارة التاريخية، وتطبيق التغييرات خارج الفترات الحرجة عندما يكون ذلك ممكنًا، وتشغيل تمرين فشل معروف بعد أن يصبح الشرط نشطًا. للتنبيهات الشاذة، يجب على المالك التعامل مع فترة إعادة التعلم على أنها ثقة منخفضة، وإقرانها بحارس ثابت أو اصطناعي حيث يبرر الخطر ذلك، وتجنب التعديلات التجميلية المتكررة التي تعيد تعيين النموذج.
أضافت New Relic كشف الشذوذ الخارجي، الذي يقارن الكيانات بالأقران بدلاً من مقارنة إشارة واحدة بماضيها. يمكن أن يجد ذلك خادمًا محملاً بدرجة زائدة في مجموعة صحية بخلاف ذلك.إرشاد الشذوذ الخارجييقدم أيضًا تحذيرًا قيمًا: كيان يُبلغ عن طوابع زمنية قديمة يمكن استبعاده من المقارنة تمامًا. العلاجات الموصى بها، تقسيم الشروط حسب سلوك الإبلاغ أو إطالة النافذة، تقايض التغطية ضد التأخير والصيانة مرة أخرى. الكشف الأكثر تطورًا لا يلغي الحاجة إلى فهم الوقت.
القياس المفقود يمكن أن يبدو صحيًا أو مكسورًا أو متأخرًا فقط
فقدان القياس هو أحد أكثر الغموض خطورة في المراقبة. عدم وجود أحداث خطأ قد يعني عدم وجود فشل، أو عدم وصول طلبات، أو أن العملية توقفت عن الإبلاغ، أو أن مرشحًا استبعد السجلات، أو فشل النقل. الاستجابة الصحيحة تعتمد على أي غياب حدث.
تكشف New Relic عدة أدوات لهذا. شروط فقدان الإشارة يمكن أن تفتح أو تغلق حدث تنبيه بعد مؤقت. ملء الفجوة يمكن أن يدخل قيمة ثابتة أو قيمة آخر معروفة. سجلاتNrIntegrationErrorيمكن أن تكشف عن البيانات المشوهة والحدود وإخفاقات التكوين. واجهة حدود الحساب تبلغ عن بعض حوادث الابتلاع والاستعلام. تسمح هذه الضوابط للفريق بمراقبة المراقبة نفسها، لكنها تحتاج إلى شروط منفصلة ومسار مستقل. تنبيه حول التنبيهات المفقودة الذي يستخدم نفس مسار القياس الفاشل ليس ضمانًا كاملاً.
الأصلية تعقد المشكلة. سلسلة زمنية للمقياس يتم تعريفها باسمها وتركيبة السمة الفريدة. إضافة قيم معرف العميل أو الطلب أو الحاوية أو المعرف غير المحدود يمكن أن تضاعف عدد السلاسل بشكل كبير. تصف New Relic حاليًا ميزانية أصلية يومية تبلغ 15 مليون لكل حساب وميزانية افتراضية تبلغ 100,000 لكل مقياس، مع توسعة مدفوعة وضوابط تقليم. عندما يتم الوصول إلى الحدود، يختلف السلوك حسب الحد؛ يقول توثيق حدود البيانات أن بعض تجاوزات معدل الطلب تتلقى استجابات 429، بينما الوصول إلى حد أصلي للمقياس يمكن أن يوقف تشغيل البيانات المجمعة لبقية يوم UTC على الرغم من أن البيانات الأولية قد تظل مخزنة.
الأصلية ليست مجرد موضوع تكلفة. إنها تغير مجموعات التنبيه وأداء الاستعلام. تنبيه مصنف على حقل عالي التغير يمكن أن يخلق آلاف الإشارات قصيرة العمر، ويزيد عمل تقييم التنبيه، ويجعل التوجيه غير منطقي. تقليم الحقل يمكن أن يتحكم في الإنفاق لكنه يزيل البعد اللازم لعزل مستأجر واحد. الوحدة الصحيحة عادة ما تكون خدمة مملوكة تشغيليًا أو منطقة أو عبء عمل أو طبقة عميل، وليس أي معرف يسهل إرفاقه.
تاريخ حالة المنصة لعام 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يقول إنه خفض ضوضاء التنبيه الأسبوعية من أكثر من 3,500 إلى أقل من 600 ووفر 57% مقارنة بحل المراقبة السابق.The Access Groupيبلغ عن تخفيض بنسبة 99% في ضوضاء التنبيه إلى حوالي تسعة تنبيهات يوميًا ويصف التحقيقات التي تستغرق حوالي عشر دقائق بعد الضبط والتوحيد.
هذه الحسابات مهمة. إنها تحدد العملاء وأعباء العمل والأرقام قبل وبعد والممارسين. تظهر أنه يمكن دمج New Relic في عمليات إنتاج كبيرة وأن ترشيد التنبيه يمكن أن يحقق مكاسب كبيرة. كما تظهر أن النتيجة لم تكن مفتاحًا قلبه نموذج الشذوذ. وضع PicPay معايير تنبيه المنصة ومركزية السجلات. Viewpoint قامت بقياس تطبيقات Kubernetes ووسعت الوصول عبر الوظائف. The Access Group ضبطت التنبيهات واستخدمت الكتم وأضافت قياس الأعمال. العمل التنظيمي جزء من النتيجة.
الأدلة مختارة من قبل البائع وتفتقر إلى القواسم الهامة. الصفحات لا توفر أسعار العقود، أو ساعات تنفيذ الهندسة، أو مجموعة تحكم متطابقة، أو فترات ثقة، أو حوادث هاربة، أو عدد النتائج السلبية الكاذبة، أو جزء التحسن الناجم عن New Relic وليس عن التوحيد وإعادة تصميم العمليات. "ضوضاء التنبيه" قد تعرف أيضًا بشكل مختلف من قبل كل عميل. الانخفاض من 3,500 إلى 600 إشعار يمكن أن يكون ممتازًا، لكنه غير مكتمل دون معرفة ما إذا كانت حالات الفشل التي اكتشفها العميل قد انخفضت أيضًا.
تقرير تأثير الذكاء الاصطناعي لعام 2026 من New Relicيقدم نظرة رصدية أكبر بكثير. يقول إن التحليل يغطي استخدامًا مجمعًا وغير محدد الهوية لحوالي 6.6 مليون مستخدم نشط خلال عام 2025. الحسابات الممكّنة بالذكاء الاصطناعي كان لديها حوالي 46% تنبيهات مزعجة مقابل 63% للحسابات غير الممكّنة، وحوالي ضعف معدل ربط المشكلات، ومتوسط وقت إغلاق أقل بنحو 25%. في مايو، كان المتوسط المبلغ عنه 26.75 دقيقة و50.23 دقيقة على التوالي.
النطاق يجعل الارتباط مثيرًا للاهتمام، وليس سببيًا. التقرير يجمع الميزات التوليدية والتعلم الآلي والحتمية تحت "ذكاء New Relic الاصطناعي". لا ينشر تعيينًا عشوائيًا، أو أعداد حسابات في كل مجموعة، أو طرق مطابقة، أو تعقيد الخدمة، أو نضج الفريق، أو مزيج الشدة، أو اتفاقيات الإغلاق، أو نتائج سلبية كاذبة. الفرق التي تمكّن الميزات المتقدمة قد تستثمر أيضًا في القياس وممارسة الحوادث. متوسط وقت الإغلاق ليس بالضرورة وقت الاسترداد؛ يمكن إغلاق المشكلة تلقائيًا أو يدويًا أو بموجب سياسة دون إثبات أن المستخدمين تعافوا.
التفسير الصحيح هو أن الربط المتكامل والمساعدة هما مساهمان محتملان في تقليل الجهد التشغيلي، وترى 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 الاصطناعي، العمل الجماعي الخاضع للتحكم أو المطابق بعناية سيساعد في فصل تأثير المنتج عن نضج العميل. نشر أعداد الحسابات، ومعايير التبني، وضوابط الشدة والبنية، وآليات الإغلاق، وفترات الثقة. ربط متوسط وقت الإغلاق بطوابع استرداد الخدمة المستقلة. الكشف عن عدد مرات قبول الأسباب الجذرية أو الاستعلامات المقترحة أو تصحيحها أو تجاهلها. هذه المقاييس ستحول الارتباط الواسع إلى دليل يمكن للفريق استخدامه في تخطيط السعة.
سيصبح الحكم أكثر إيجابية إذا أظهرت هذه الأدلة تغطية عالية قابلة للتنفيذ، ومعدلات ربط ضارة منخفضة، وتخفيضات مستدامة في دقائق المهندس بعد تضمين عمل القياس والضبط. سيصبح أقل إيجابية إذا كانت المكاسب تعتمد على فرق متخصصة كبيرة، أو إذا أنتج إعادة تعلم الشذوذ فترات عمياء ذات مغزى، أو إذا كانت إخفاقات التوجيه شائعة، أو إذا أدى التحكم في التكلفة بشكل متكرر إلى إزالة الأدلة اللازمة للتشخيص.
الحكم: اشتر نظام الكشف، خصص ميزانية للقائمين عليه
تقدم New Relic منصة مراقبة ذات قيمة تقنية كبيرة. طبقة البيانات المشتركة، و NRQL التعبيرية، والقياس الواسع، والتقييم المتدفق، وكشف الشذوذ، وربط الحوادث، وسير العمل يمكن أن تحل محل مراقبة لوحات التحكم اليدوية والبحث المجزأ عن الأدوات. يبلغ العملاء المسموون عن تخفيضات كبيرة في الضوضاء ووقت الحل. دعم OpenTelemetry يقلل من مصدر مهم للتقييد، والتوثيق صريح بشكل غير معتاد بشأن البيانات المتأخرة وإعادة التعيين والحدود والإشارات المفقودة.
لا يمكن للمنصة أن تقرر ما يعتبره العمل ضارًا، أو تضمن أن قياس العميل يعبر عنه، أو تبقي كل استعلام ومسار صحيحين مع تغير الخدمات. النماذج الأكثر تقدمًا تحسن الآليات بين القياس والانتباه؛ إنها لا تزيل الحاجة إلى الإشراف على الآليات. ينتقل العمل البشري المتكرر من التحديق في لوحات التحكم إلى تصميم الإشارات، وحوكمة الاستعلامات، ومراجعة الاستثناءات، واختبار المسارات، وإصلاح الشروط بعد الحوادث.
يمكن أن تكون مقايضة ممتازة. بضع ساعات من هندسة التنبيه المنضبطة يمكن أن توفر ساعات أكثر بكثير من الفرز المكرر وتقلل الضرر على العميل. يمكن أن تكون أيضًا مقايضة سيئة عندما تقيس الفرق فقط البيانات المبتلعة وأعداد الإشعارات، وتسمح بتراكم الشروط بدون مالكين، أو تعامل حجم التنبيه المنخفض دليلاً على موثوقية أعلى.
لذلك يجب شراء New Relic وتشغيلها كنظام كشف، وليس كأوراكل. قياس المسار الكامل من الأدلة المنبعثة إلى الإجراء المبرر. حافظ على رؤية حالات الفشل المفقودة. قم بتحميل تكلفة القياس والضبط على التنبيه الذي يعتمد عليهما. احمِ المسارات الأكثر أهمية بفحص مستقل. الرقم الحاسم ليس عدد الإشارات التي يمكن لـ NRDB تخزينها أو عدد الأحداث التي يمكن لخوارزمية تجميعها. إنه كم مرة يخبر النظام الشخص المناسب بشيء حقيقي، مبكرًا بما يكفي ليكون مهمًا، بتكلفة إجمالية أقل من الفشل والعمل الذي يمنعه.