Alerta mejores practicas

Con alerta, puedes empezar a detectar problemas antes de que se vuelvan críticos. Usando NRQL, nuestro lenguaje de consulta New Relic, puede crear y personalizar su condición de alerta que se centre en lo que más le preocupa. Utilice para recibir actualizaciones sobre comportamientos inusuales en sus datos, enviar notificaciones a las personas que necesitan verlas y tomar decisiones efectivas sabiendo la causa raíz de su problema.

Mejore su cobertura de alerta utilizando nuestras recomendaciones sobre cómo utilizar mejor la respuesta de alerta, el mantenimiento, la calidad y la configuración avanzada. Consulte nuestra guía de gestión de calidad de alertas para saber cómo medir y mejorar la calidad de sus alertas.

Puede seguir estas acciones recomendadas para mejorar y aprovechar al máximo su configuración de alerta.

Sugerencia

¿Ya creaste tu primera alerta? De lo contrario, consulte nuestra serie de tutoriales para conocer todos los pasos que necesita para comenzar.

Mejorar la respuesta de alerta

Qué tengo que hacer	Beneficio
Tener un nombre explicativo para la alerta.	La descripción y la etiqueta deben darte una alerta autodescriptiva para saber qué servicio está mal, qué entorno está involucrado, qué equipo es el propietario y si está impactando al usuario final. Le ayuda a responder más rápido y decidir qué hacer.
Añade etiqueta a tu condición de alerta	Sus problemas e incidentes tienen estas etiquetas en sus metadatos. Úselos para crear filtros flexibles en el flujo de trabajo o agréguelos a la carga útil de su notificación. Los problemas tienen 3 fuentes de etiqueta: La etiqueta definida en la condición de alerta. Los valores actuales de la cláusula`facet/where` de la condición de alerta. La etiqueta de la entidad infractora si los resultados de la alerta tienen como ámbito una entidad única. Si el incidente no tiene como ámbito la entidad, no se traerá la etiqueta de entidad. Estos eventos se almacenan en NRDB. No se preocupe por el consumo de tablas nr* porque no se cuentan como ingesta.
Categorizar la condición de alerta	En toda su organización, defina categorías de alerta, expectativas para manejar su notificación y un destino único. Por ejemplo, ser proactivo con Slack para notificar antes de que ocurra el incidente; reactivo a PagerDuty para detectar y notificar un incidente en curso; o informativo para Jira.
Definir el método de comunicación y escalamiento.	Decidir el medio de notificación. Algunos métodos de notificación son: correo electrónico, Slack, PagerDuty o Jira.
Añade un equipo responsable	Este equipo es el encargado de gestionar la primera notificación.
Agregue una URL de runbook a cada condición de alerta	El runbook debe describir los pasos de remediación a seguir y a quién involucrar o escalar.
Usar enriquecimientos	Priorice y clasifique su notificación de alerta más rápido proporcionando métricas adicionales específicas para el problema.

Mejorar alerta de mantenimiento

Qué tengo que hacer	Beneficio
Organiza tus pólizas	Recomendamos crear una política para cada destino o audiencia por separado que necesite recibir una notificación. Considere agrupar por entidad, servicio o tecnología para que coincida con el enfoque de sus respectivos equipos.
Agregue un equipo propietario a cada condición de alerta	El equipo propietario garantiza que la alerta sigue siendo relevante. Aprueban cualquier cambio en la condición.
Programe una revisión periódica de condición de alerta	Utilice la página de resumen de alertas para consultar el incidente creado y decidir la acción a realizar. Te recomendamos etiquetar la condición con la fecha de la última revisión, lo que te permitirá identificar alertas obsoletas.
Automatiza la creación de alertas usando Terraform	Evitarás cambios no documentados y una trazabilidad clara.

Mejorar la calidad de las alertas

Qué tengo que hacer	Beneficios
Tener SLI y SLO en un informe	Las infracciones de SLI y SLO no siempre son incidentes y no requieren una alerta a menos que haya documentado los pasos para evitarlas. SLI/SLO puede resaltar el área en la que el equipo debe centrarse para realizar mejoras en lugar de responder a un evento.
Silenciar alerta durante el mantenimiento	Suprimirá las notificaciones ruidosas.
Tener un enfoque sistémico al definir alerta para un servicio	Le ayuda a asegurarse de cubrir toda su stack de manera consistente. Puedes organizar tu alerta por tecnología, equipos involucrados, etc.
Revisar las decisiones sugeridas	Todos los días analizamos sus datos de alerta y proporcionamos decisiones sugeridas, así como comentarios sobre las decisiones existentes. Esto mejorará la reducción de ruido.
Identificar y sintonizar oscilaciones alerta	Estas alertas indican una configuración de condición de alerta deficiente que genera ruido. Es posible que aún indiquen un problema de larga data en su sistema, pero esto no es un incidente.
Aumente el umbral o la duración de la ventana y utilice la agregación de ventanas deslizantes	Tenga en cuenta que la resolución automática antes de que su equipo pueda tomar alguna medida puede saturar su bandeja de entrada y generar ruido. Utilice un panel si desea ver picos de corta duración y suavizar los picos temporales. Comprenderá el impacto que esto tendrá en el cierre de su incidente.
Usar decisiones	Aproveche su etiqueta personalizada y metadatos en las decisiones. Los incidentes relacionados se correlacionarán en un tema único y completo. Mantenga habilitadas las decisiones predeterminadas cuando comience. En un par de semanas, podrá evaluar la eficacia de estas decisiones.
Si utiliza decisiones, aumente el período de gracia de notificación	Obtendrá más incidentes relacionados con sus problemas. Obtendrá un contexto más rico y útil desde la primera notificación. Cuanto más largo sea el período de gracia, más tardía será la notificación.
Revisar periódicamente el feed de problemas	Desplácese por la columna Notified para asegurarse de que todos los problemas se dirijan a al menos un destino. Si no es necesario enrutar, considere eliminar la condición, ya que puede ser ruido.

Condición de creación de alerta y configuración avanzada

Si eres nuevo en alerta o quieres sugerencias que optimicen tu cobertura de alerta, presta atención a estas recomendaciones:

Entender la señal

Cada condición de alerta genera una señal o múltiples señales si la condición contiene una cláusula facetaria. Cada valor de faceta posible creará una señal distinta.

Puedes consultar todas las señales en NrAiSignal. Esto le permite obtener detalles sobre el valor observado, cuántos puntos de datos se consideraron y, en el caso de condiciones de anomalía, el valor esperado y la desviación estándar. También brinda información sobre el delta de tiempo entre la hora de New Relic y la hora de sus datos sin procesar (si sus datos son una marca de tiempo), lo que puede ayudarlo a encontrar la configuración de demora más precisa al crear sus condiciones.

Mantener la salud de la entidad

Usamos señales para inferir la salud y la cobertura de alerta de una entidad. Si los resultados de una condición de alerta contienen datos de una sola entidad, New Relic los vinculará al estado de esa entidad y estos eventos se mostrarán en contexto en la UI de New Relic.

Se recomienda, para la mayoría de las condiciones, mantener la existencia de una señal. Ninguna señal puede provocar que New Relic muestre un estado de salud gris (desconocido) para algunas entidades, además de agregar estas entidades a la lista de entidades no cubiertas.

Si la cláusula where de tu condición excluye todos los datos, no quedarán datos. Esta es una pérdida de señal para New Relic y la condición de alerta NO PUEDE evaluarse según NINGÚN umbral. Significa que el resultado de la consulta NRQL no tiene datos, pero no significa que New Relic no esté recibiendo datos. Si desea recibir una notificación, debe agregar un umbral de pérdida de señal.

Utilice los filtros más genéricos en su sección where y los más específicos en su sección select . Utilice la función de filtro para medir con precisión lo que le interesa. Por ejemplo:

Select filter(count(*), where ErrorCode=123) from Transaction where AppName='Application1' and Environment='Production'

Retraso de alerta o duración del temporizador

Intente ajustar el retraso/tiempo con el comportamiento de sus datos. Una demora breve puede desencadenar una alerta falsa debido a datos incompletos y una demora grande puede aumentar el tiempo para recibir notificaciones. New Relic no sabe cuántos datos esperar ni qué tan tarde podrían llegar a un extremo de New Relic. Dependiendo del transportista log y de la configuración, los datos log se pueden agrupar y experimentar retrasos significativos para registros de volúmenes bajos.

Establece tu umbral de condición

Establezca niveles de umbral significativos para optimizar la alerta para su negocio. Aquí hay algunas pautas sugeridas:

Acción	Recomendaciones
Establecer niveles de umbral	Avoid setting thresholds too low. Por ejemplo, si establece un umbral de condición de CPU del 75% durante 5 minutos en sus servidores de producción y rutinariamente supera ese nivel, esto aumentará la probabilidad de alerta no procesable o falso positivo.
Experimentando con la configuración	You don't need to edit files or restart the software, así que siéntete libre de realizar cambios rápidos en tus niveles de umbral y ajustarlos según sea necesario.
Ajustar la configuración	Adjust your conditions over time. Ajusta tu umbral siempre que uses New Relic para mantener el ritmo de tu rendimiento mejorado. Si está implementando algo que sabe que afectará negativamente su desempeño durante un período de tiempo, afloje su umbral para permitirlo.
Desactivar configuración	Puede disable any condition en una política, si es necesario. Esto es útil, por ejemplo, si deseas seguir usando otras condiciones en la póliza mientras experimentas con otras métricas o umbrales.

El indicador de estado de salud codificado por colores en la UI de New Relic cambia a medida que el umbral de alerta aumenta o vuelve a la normalidad. Esto le permite monitor una situación a través de la interfaz de usuario antes de alcanzar un umbral crítico, sin necesidad de recibir una notificación específica al respecto. Hay dos umbrales de incidente: crítico (rojo) y advertencia (amarillo). Defina estos umbrales con diferentes criterios, teniendo en cuenta las sugerencias anteriores.

Asegúrese de que se ejecuten sus trabajos por lotes diarios

Puede configurar una condición de alerta para recibir una notificación si sus trabajos por lotes no se ejecutan.

Suponiendo que está enviando un evento a New Relic como parte de su trabajo por lotes, puede configurar una condición de alerta para que le notifique si sus trabajos por lotes no se ejecutan.

Configure una consulta de recuento simple sobre el evento.
```
SELECT count(*) FROM MyBatchEvent
```
Configure Pérdida de señal para abrir un nuevo incidente después de 24 horas y 30 minutos. Puede ajustar esto, pero es una buena idea permitir un trabajo por lotes de ejecución tardía.
Asegúrese de utilizar el método de agregación de transmisión de evento Timer . Como solo obtendrás 1 punto de datos cada 24 horas, puedes configurar el temporizador en su configuración más baja, 5 segundos.

Utilice valores no nulos cuando no haya señal

De forma predeterminada, los espacios en las señales de datos se rellenan con valores nulos. En los casos en los que necesite poder crear condiciones basadas en esas lagunas de datos, puede llenar las lagunas con un valor personalizado o el último valor conocido. Puede configurar esta configuración por condición en la UI o configurar valores de llenado de espacios a través de NerdGraph.

Importante

Configurar el llenado de espacios no evita que se active la "pérdida de señal".

Defina sus preferencias de creación de problemas

Decida cuándo recibirá la notificación de problemas para poder responder a los problemas cuando ocurran.

Si es nuevo en Alerta, obtenga más información sobre las opciones de preferencias de problemas.

La configuración de preferencia de emisión predeterminada combina todas las condiciones dentro de una política en una sola emisión. Cambie su configuración de preferencia de problemas predeterminada para aumentar o disminuir la cantidad de problemas y notificaciones de problemas que recibe.

Cada equipo dentro de su organización puede tener diferentes necesidades. Haga a su equipo 2 preguntas importantes al decidir sus preferencias de temas:

¿Queremos que nos avisen cada vez que algo salga mal?
¿Queremos agrupar todas las notificaciones similares y recibir una notificación una vez?

Cuando una póliza y sus condiciones tienen un alcance más amplio, como gestionar el rendimiento de varias entidades, aumenta el número de emisiones que recibe. Es posible que necesite más notificaciones porque dos problemas no necesariamente pueden estar relacionados entre sí.

Cuando una política y sus condiciones tienen un alcance enfocado, como administrar el rendimiento de una entidad, opte por la preferencia de emisión predeterminada. Necesita menos notificaciones cuando dos problemas están relacionados entre sí o cuando el equipo ya ha sido notificado y está solucionando un problema existente.

¿Que sigue?

Para obtener más información sobre el uso de alerta:

Obtenga más información sobre los conceptos y términos de alertas.
Obtenga más información sobre la API.
Lea los detalles técnicos sobre los límites y reglas mínimos y máximos.
Lea más sobre cuándo es posible que desee utilizar configuraciones de pérdida de señal y llenado de espacios.

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