Optimización de errores: Mejora tu rastreo de errores

Esta guía le muestra cómo optimizar sus errores para que pueda mejorar la tasa de errores, la detección de errores y la experiencia de los clientes. Es parte de nuestra serie sobre madurez de observabilidad.

Descripción general

Rastreo de errores es la práctica de capturar errores de aplicación y tasa de errores para que pueda abordar los problemas que afectan la experiencia de sus clientes con su software.

El monitoreo de IA de esta guía tiene como objetivo permitir a un cliente o equipo de New Relic:

• Calibre la forma en que New Relic entiende los errores, de modo que las métricas relacionadas con los errores reflejen solo los errores que sean significativos para usted.
• Reducir la incidencia de errores a lo largo del tiempo.

Resultado deseado

Mejore la experiencia y confiabilidad de los clientes al reducir la tasa de errores de la aplicación y el tiempo medio de resolución.

Indicadores de rendimiento clave

KPI comerciales

Reducir los errores que experimentan los clientes mejora la confiabilidad. Las organizaciones que mejoran la confiabilidad experimentan una mayor tasa de conversión (tasas de finalización del recorrido del usuario) y una mayor participación del usuario. Esto acerca a la organización al cumplimiento de su objetivo de ingresos (comercial) o de impacto social (sin fines de lucro).

FROM Transaction SELECT 
   (FROM Transaction select count(*) WHERE request.uri = '/api/v1/lastStep') /
   (FROM Transaction select count(*) WHERE request.uri = '/api/v1/firstStep') AS conversionRate

FROM PageView SELECT count(*) WHERE appName in ('CustomerApp1', 'CustomerApp2')

FROM Transaction count(*) WHERE appName = 'apiService'

FROM PageView SELECT uniqueCount(userId) WHERE appName in ('CustomerApp1', 'CustomerApp2')

FROM PageView SELECT uniqueCount(session) WHERE appName in ('CustomerApp1', 'CustomerApp2')

FROM Transaction uniqueCount(customerId) WHERE appName = 'apiService'

Los KPI empresariales anteriores funcionan bajo el supuesto de que usted apoya a su usuario proporcionándole una aplicación frontend. Si brinda soporte a sus clientes a través de API, es posible que los KPI anteriores se ajusten al tipo de entidad de transacción. Algunas organizaciones que brindan API como servicio utilizan KPI operativos como los que se muestran a continuación para promover la calidad de su oferta.

KPI operativos

Requisitos previos

Instalación y configuración requeridas

• Asegúrese de que nuestras soluciones

  APM

  ,

  monitoreo de browser

  , monitoreo de móviles, monitoreo sin servidor u OpenTelemetry estén recibiendo sus errores.

• Mapas fuente actualizados para la aplicación web

• Simbología actualizada para aplicaciones móviles.

Establecer el estado actual

• Crea una carga de trabajo para tu aplicación
• Cree un nivel de servicio para su carga de trabajo

Crea una carga de trabajo para tu aplicación

Defina la lista de aplicaciones y servicios para los que está intentando optimizar los errores. El equipo que lleva a cabo el proceso de optimización de errores debe tener total responsabilidad y control sobre estas aplicaciones y servicios. Una vez que lo hayas decidido, configura una carga de trabajo para estas entidades.

Carga de trabajo son un grupo de entidades (aplicación, instancia, etc.) de las que es responsable un equipo específico. Le permiten ver datos solo de la entidad sobre la que puede hacer algo. Basaremos la mayor parte de nuestro trabajo en el futuro en torno a la carga de trabajo que configure aquí.

Solo lleva unos minutos configurar una carga de trabajo. Consulte las instrucciones de carga de trabajo.

Si ya está familiarizado con la carga de trabajo y prefiere dividir su aplicación y servicios en múltiples cargas de trabajo, puede hacerlo. Simplemente siga los pasos a continuación para cada carga de trabajo.

Cree un nivel de servicio para su carga de trabajo

nivel de servicio le permite configurar y ver fácilmente los objetivos de nivel de servicio (SLO) para un grupo determinado de entidades. Usar nivel de servicio es una forma de monitor y comunicar el éxito de su proyecto de gestión de errores.

Desde su carga de trabajo, navegue hasta la pestaña Service levels . Cree un nivel de servicio que mida la tasa de errores para cada entidad en la carga de trabajo. Esto se configura en el Paso 2 en la UI del nivel de servicio. Para cada nivel de servicio, utilice las cláusulas WHERE para filtrar buenas solicitudes o errores que no deben tenerse en cuenta.

Crear un nivel de servicio de tasa de errores para cada servicio de aplicación

Para el paso 2 de la creación del servicio, elija Success SLI.

Agrega una etiqueta al nivel de servicio para que puedas ver todas las tasas de errores en una sola vista. Puedes usar la etiqueta predeterminada. category:success

Crear un nivel de servicio de tasa de errores para cada aplicación browser

• Para el paso 2 de la creación del servicio, elija

  Success

  SLI.

  

• Para el paso 4, agregue una etiqueta al nivel de servicio. Puedes usar la etiqueta predeterminada. category:success

  

Crear un nivel de servicio de tasa de errores para cada aplicación móvil

Crear un nivel de servicio para fallas móviles

• Para el paso 2, elija MobileSession como fuente del evento válido. Elija MobileCrash como fuente de malas respuestas.

  

• Para el paso 4, agregue una etiqueta al nivel de servicio. Puede utilizar la etiqueta predeterminada category:success.

  Crear un nivel de servicio para errores de solicitud móvil

• Para el paso 2, elija MobileRequest como fuente del evento válido. Elija MobileRequestError como fuente de malas respuestas.

  

• Para el paso 4, agregue una etiqueta al nivel de servicio. Puede utilizar la etiqueta predeterminada category:success.

Cree un nivel de servicio de tasa de errores para cada aplicación sin servidor

Cree un nivel de servicio de tasa de errores para la función Lambda de AWS integrada con nuestro monitoreo sin servidor:

• Para el Paso 1, seleccione Lambda function como tipo de entidad

• Para el paso 2, seleccione AWSLambdaInvocation para eventos válidos y AwsLambdaInvocationError para respuestas incorrectas

  

• Para el paso 4, agregue una etiqueta al nivel de servicio. Puedes usar la etiqueta predeterminada. category:success

  

  Actualmente, el nivel de servicio solo admite tasa de errores para la función Lambda AWS utilizando el monitoreo New Relic sin servidor para AWS Lambda. Puede capturar la tasa de errores fuera del nivel de servicio utilizando la siguiente consulta:

  SELECT sum(provider.errors.Sum)/sum(provider.invocations.Sum)*100 FROM ServerlessSample

  Copia

Crear un nivel de servicio de tasa de errores para cada aplicación de telemetría abierta

• Para el paso 1, seleccione Service - OpenTelemetry.
• Para el evento válido del Paso 2, utilice el tipo de entidad Span para buenos tipos de eventos. Agregue lo siguiente a la cláusula WHERE: (span.kind LIKE 'server' OR span.kind LIKE 'consumer' OR kind LIKE 'server' OR kind LIKE 'consumer')
• Para el evento no válido del paso 2, utilice el tipo de entidad Span y la opción Repeat WHERE clause . Agregue lo siguiente a la cláusula WHERE para detectar malas respuestas: otel.status_code = 'ERROR'
• Para el paso 4, agregue una etiqueta al nivel de servicio. Puede utilizar la etiqueta predeterminada category:success.

Utilice el nivel de servicio para realizar un seguimiento de su progreso frente a la tasa de errores actual

Utilizando el proceso documentado anteriormente, ha creado un nivel de servicio basado en su tasa de errores actual.

• La columna SLO le muestra la tasa de errores objetivo que seleccionó utilizando una línea de base.
• El modo de vista operativa le muestra el rendimiento reciente en comparación con su objetivo.
• El modo de vista Período tras período le muestra el rendimiento frente a su objetivo durante un período de tiempo más largo.
• Puede actualizar la tasa de errores objetivo a medida que se realicen mejoras.

Proceso de mejora

• Identificar errores intrascendentes
• Elimina errores intrascendentes de tu tasa de errores
• Configurar alerta de tasa de errores
• Establecer una lista de héroes de error
• Clasificación de errores mediante Errors Inbox
• Errores de enlace a JIRA
• Errores de enlace a Slack
• Utilice CodeStream

Identificar errores intrascendentes

Explora tus errores como te resulte más cómodo. Puedes hacer esto usando:

• Vistas listas para usar para APM, monitoreo de móviles, errores de JavaScript, monitoreo sin servidor y OpenTelemetry
• Errors Inbox filtrada según su carga de trabajo
• Tipos de datos NRQL como TransactionError, JavaScriptError, MobileRequestError, AwsLambdaInvocationError, Span

Elimina errores intrascendentes de tu tasa de errores

Puede eliminar errores que no importan de dos maneras:

• Evite que se ingieran mediante la configuración (solo APM) o mediante reglas de eliminación. Este enfoque solo funciona para errores que usted está seguro de que no es necesario capturar. La ventaja adicional de este enfoque es la reducción de la ingesta de errores ruidosos.
• Utilice NRQL para filtrar los errores de los cálculos del nivel de servicio. Haga esto agregando a la cláusula WHERE un filtro de malas respuestas. Asegúrese de volver a basar el nivel de servicio si esto mejora significativamente la tasa de errores. Hacerlo mejorará la precisión de las alertas de errores.

Configurar alerta de tasa de errores

Revise cada uno de los niveles de servicio configurados en Crear nivel de servicio para su carga de trabajo y cree una alerta para notificar al equipo cuando la tasa de errores aumente más allá de lo aceptable.

Establecer una lista de héroes de error

Las alertas le permitirán saber si está cumpliendo con los niveles actuales de rendimiento de errores, pero no le ayudarán a mejorarlos. Para mejorar el sentimiento de los clientes, cree un proceso en el que un miembro de su equipo revise los errores diariamente. El héroe del error debería:

• Inicialmente, céntrese en los errores que ocurren en la mitad superior de la página. Para un proceso de revisión diario, esto significa centrarse en los errores que ocurrieron sólo en las últimas 24 horas.
• Clasificación de errores mediante Errors Inbox

Clasificación de errores mediante Errors Inbox

Errors Inbox es un lugar único para detectar, clasificar y tomar medidas proactivas sobre todos los errores antes de que afecten a los clientes. Los errores similares se agruparán para evitar la duplicación del trabajo y permitirle priorizar los errores por número de ocurrencias.

Al acceder Errors Inbox, asegúrese de seleccionar su carga de trabajo para que solo vea errores relevantes para su equipo.

Reserve un tiempo regular para revisar Errors Inbox como equipo. Para empezar, tiene sentido hacerlo diariamente o algunas veces a la semana, ya que tendrá que revisar muchos grupos de errores. Posteriormente, puede ser más apropiado semanal o quincenal.

Revise los errores uno por uno haciendo clic en la pantalla de detalles del error cuando sea necesario para obtener más información como traza, registro, etc. Esto señalará la causa del error o proporcionará un punto de partida para una investigación adicional.

Después de una breve discusión, es posible que pueda marcar el grupo de errores como uno de los siguientes:

• Ignorar: para usar cuando el error no es problemático. Esto ocultará el grupo de errores de la vista de la bandeja de entrada a partir de ese momento.
• Resuelto: para usar cuando el error fue el resultado de un problema conocido que ya se ha solucionado. Esto eliminará el grupo de errores de la lista a menos que se repita. Si vuelve a ocurrir, se debe repensar la solución implementada anteriormente.

Nota: Ignorar y/o resolver errores a través de Errors Inbox no impedirá que cuenten para la tasa de error métrica.

Si ninguno de los estados anteriores es adecuado, asigne el error al miembro correspondiente del equipo para que lo investigue y lo resuelva en mayor profundidad. Ese miembro del equipo puede realizar más investigaciones a su propio ritmo, actualizando las notas del grupo de errores con su progreso y/o pidiendo ayuda a otros miembros del equipo a través de la sección de notas.

En la próxima reunión de clasificación, puede volver a visitar estos grupos de errores para ver si ahora se pueden marcar como resueltos. A medida que pasa el tiempo, debería comenzar a ver que aparecen menos grupos de errores nuevos y un movimiento positivo en sus KPI.

Errores de enlace a JIRA

A medida que se adentre en casos más extremos o en errores complejos, es posible que necesite pedir ayuda a otros equipos. Vincular Errors Inbox a Jira puede ayudar con esto. Conecte su Errors Inbox a Jira para poder crear fácilmente tickets conectados a grupos de errores. Puedes controlar la información enviada a Jira a través de las plantillas de Jira.

Errores de enlace a Slack

A medida que disminuye la velocidad de los errores que llegan a Errors Inbox , es posible que una sesión regular del equipo ya no sea un buen uso del tiempo. Una alternativa es vincular Errors Inbox a Slack y a) designar una persona rotativa para monitor el canal y resolver/ignorar/asignar grupos de errores a medida que ingresan o b) permitir que el equipo responda proactivamente a los grupos de errores.

Utilice CodeStream

Muchos de sus grupos de errores requerirán cambios de código para resolverse. Conecte CodeStream a su cuenta de New Relic para abrir el código infractor directamente en su IDE para investigar el código directamente. También puede dejar notas y comentarios sobre líneas de código específicas para que los desarrolladores las revisen y viceversa.

New Relic con CodeStream le brinda más contexto sobre sus grupos de errores, como poder ver números de versión o confirmar SHA. Además, utilizar Errors Inbox como un lugar centralizado para identificar, discutir y rectificar problemas de código le permite responder a los problemas de código de manera eficiente y evitar la duplicación del trabajo.

Realización de valor

Revise la tasa de errores semanalmente a medida que avanza en la práctica. A medida que disminuye la tasa de errores, debería ver un tiempo medio de resolución más rápido y una mayor satisfacción de los clientes.