• /
  • EnglishEspañol日本語한국어Português
  • Inicia sesiónComenzar ahora

Te ofrecemos esta traducción automática para facilitar la lectura.

En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.

Crea una propuesta

Parte de implementación 4: Alertas y otras soluciones proactivas

Esta es la cuarta y última parte de nuestra guía de implementación.

En etapas de implementación anteriores, instrumentó su stack y se familiarizó con la plataforma New Relic. Ahora es un buen momento para pensar en soluciones proactivas que le notificarán los problemas con antelación y le ayudarán a evitar los peores escenarios. En esta etapa, aprenderá sobre algunas soluciones importantes en esta área, que incluyen:

  • Alertando
  • Monitor sintético
  • Errors Inbox

Piense en su estrategia de alerta

Alerts UI

LaUI de New Relic le brinda una vista del estado de condición de alerta en una cuenta.

Antes de configurar alertas, recomendamos dedicar algo de tiempo a pensar en sus objetivos y estrategia de alerta. Cuanto más grande sea su organización, más importante será.

Cuando no se tiene una estrategia de alertas y, en cambio, se configuran alertas de forma rápida y desordenada para resolver problemas puntuales, se pueden generar demasiadas alertas. Cuando eso suceda, su equipo sufrirá un exceso de alertas y comenzará a ignorarlas. Dedicar algún tiempo a pensar en su estrategia de alerta le asegurará configurar alerta de una manera inteligente que pueda escalar a medida que su organización crece o a medida que agrega más datos a New Relic.

Para enviarle mensajes de notificación de alerta, utilizamos workflows (las reglas de cómo el incidente crea la notificación y qué datos se envían) y notification destinations (dónde se envía la notificación). Le recomendamos que planifique cómo se configurarán para que sean coherentes y mantenibles en toda su organización. Si se está integrando con otro servicio, como Slack o PagerDuty, considere cómo controlará y mantendrá esta integración a largo plazo.

Evitar el exceso de alertas debe ser un objetivo central de su estrategia de alerta. Una estrategia que podría aplicar es categorizar su alerta según la gravedad del impacto empresarial. Aquellos que son más severos o críticos deberían hacer el ruido más fuerte y entregarse a las partes interesadas que están en condiciones de responder, mientras que aquellos que tienen un menor impacto en el negocio deberían entregarse más silenciosamente, con un "radio de explosión" más pequeño.

Por ejemplo, podría considerar definir algunos protocolos de gravedad de alertas que pueda aplicar en toda la organización y utilizar el flujo de trabajo para garantizar que las alertas se enruten correctamente. Los equipos pueden aplicar rutas ligeramente diferentes para cada gravedad, pero introducir un lenguaje común y una comprensión del impacto en toda la organización puede generar dividendos a medida que se amplían los esfuerzos de alerta.

Gravedad

Impacto

Audiencia

Integracion

Nivel 1 / P1

Crítico

On call ingeniería de confiabilidad del sitio (SRE), C-Level Manager / incidente Commander /, Relevant Product Owner y equipos DevOps

PagerDuty, Slack, Correo electrónico

División 2 / P2

Alto

Equipos relevantes de Product Owner y DevOps

PagerDuty, flojo

Sección 3 / P3

Medio

Equipos DevOps

Slack

Caja de arena/Sev 4/P4

Bajo/Ninguno

Equipos DevOps

Holgura de la caja de arena

Un ejemplo de cómo una organización podría definir algunos protocolos de seguridad de alerta.

Para garantizar la calidad de las alertas a largo plazo, es posible que desee considerar la planificación de revisiones periódicas de su condición de alerta para garantizar que se aborde cualquier exceso de alertas y que las alertas se clasifiquen correctamente. Para ello será necesario analizar con qué frecuencia alertan los disparos y cuáles son los tiempos de respuesta y resolución.

Para conocer formas de comenzar con las alertas:

Aquí hay algunos documentos sobre cómo automatizar su alerta:

Monitoreo sintetico

Nuestro monitoreo sintético le brinda un conjunto de herramientas automatizadas y programables para monitor sus sitios web, transacciones comerciales críticas y extremos de API. Estas herramientas le permiten ejecutar un monitor simple para verificar el tiempo de actividad y la funcionalidad básica, o crear scripts complejos que imiten las acciones y el flujo de trabajo de un usuario real.

Para utilizar bien Sintético, su equipo debe identificar los recorridos de los clientes críticos para el negocio y las API dependientes, y configurar el monitor Sintético para realizar un seguimiento de ellos. Sus informes de seguimiento de Sintético pueden ser parte de su carga de trabajo u otro panel de control.

Synthetic monitoring - Monitors index

Puedes comprobar el estado y métrica de tu monitor con el índice de monitores.

Para comenzar con Sintético, consulte Introducción a Sintético y Crear un monitor.

Errors Inbox

Nuestra característica Errors Inbox le ayuda a detectar, priorizar y tomar medidas proactivas ante los errores antes de que afecten a su usuario final. Recibirás una alerta cada vez que surja un error crítico que afecte a los clientes a través de tu canal de comunicación preferido, como Slack.

This is an image of the main errors inbox UI

La le Errors Inbox UI permite revisar fácilmente los errores de su carga de trabajo.

Para utilizar Errors Inbox, deberás haber configurado alguna carga de trabajo. Recursos para comenzar:

¿Que sigue?

Esta guía le ha ayudado a establecer una base sólida de observabilidad, pero ese es sólo el primer paso para avanzar hacia la excelencia en observabilidad. A continuación, es posible que desees concentrarte en aprender los puntos más finos de New Relic y optimizar tu configuración. Algunas ideas para los próximos pasos:

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.