Esta guía es una introducción para mejorar su habilidad para diagnosticar problemas que afectan a los clientes. Podrá recuperarse de los problemas de rendimiento de la aplicación más rápidamente siguiendo los procedimientos de esta guía.
Esta guía es parte de nuestra serie sobre madurez de observabilidad.
Requisitos previos
A continuación se detallan algunos requisitos y algunas recomendaciones para utilizar esta guía:
Cobertura de observabilidad de New Relic:
- Required : APM con rastreo distribuido, logs en el contexto de APM y agente de infraestructura
- Recomendado: log y Monitoreo de red (NPM)
Required: administración a nivel de servicio
Recomendado: algo de experiencia en el uso de New Relic APM, rastreo distribuido, consultas NRQL y UI
Recomendado: leíste estas guías:
Descripción general
Antes de comenzar a utilizar esta guía, le ayudará a comprender lo que aprenderá. Esta guía le ayudará a comprender:
Cómo se ve impactado su negocio al mejorar sus habilidades de diagnóstico.
La clave operativa de indicadores de rendimiento utilizada para medir el éxito.
Cómo percibe finalmente su usuario los diferentes tipos de problemas de confiabilidad.
La diferencia entre la causa directa y la causa raíz subyacente de un problema.
Los pasos básicos de diagnóstico para encontrar y resolver problemas, que incluyen:
- Definir el problema: crear un planteamiento del problema
- Encontrar la fuente del problema
- Encontrar la causa directa de ese problema.
Algunas categorías de problemas de desempeño (rendimiento de salida, desempeño de entrada y desempeño de cliente) y la característica New Relic utilizada para diagnosticar esos problemas (APM, Sintético, y monitoreo de móviles).
Cómo utilizar una matriz de problemas, que es una hoja de referencia para comprender los problemas comunes y sus posibles fuentes.
Hacia el final, revisaremos algunos problemas de rendimiento de ejemplo, que deberían ayudarle a comprender mejor estos conceptos.
Resultados deseados
Resumen
El valor para el negocio es:
- Reducir el número de incidentes que perturban el negocio
- Reducir el tiempo necesario para resolver problemas (MTTR)
- Reducir el coste operativo del incidente
El valor para operaciones de TI e ingeniería de confiabilidad del sitio (SRE) es:
- Mejorar el tiempo para comprender y resolver.
Resultado comercial
En 2014, Gartner estimó que el coste medio del tiempo de inactividad de TI era de 5.600 dólares por minuto. El costo acumulativo de un incidente que afecta el negocio está determinado por factores como el tiempo de conocimiento, la frecuencia, el tiempo de reparación, el impacto en los ingresos y la cantidad de ingenieros que clasifican y resuelven el incidente. En pocas palabras, desea menos incidentes que afecten al negocio, una duración más corta de los incidentes y diagnósticos más rápidos, con menos personas necesarias para resolver los impactos en el rendimiento.
En última instancia, el objetivo empresarial es maximizar el tiempo de actividad y minimizar el tiempo de inactividad, donde el costo del tiempo de inactividad es:
Downtime minutes x Cost per minute = Downtime cost
El tiempo de inactividad está determinado por la cantidad de incidentes que interrumpen el negocio y su duración. El costo del tiempo de inactividad incluye muchos factores, pero los que se pueden medir más directamente son el costo operativo y la pérdida de ingresos.
La empresa debe impulsar una reducción en lo siguiente:
- número de incidentes que perturban el negocio
- costo operativo del incidente
Resultado operativo
El resultado operativo requerido es mantener el cumplimiento de los objetivos de nivel de servicio a nivel de producto. Para ello, diagnostique el nivel de servicio degradado, comunique su diagnóstico y realice una resolución rápida. Pero siempre ocurren degradaciones e incidentes inesperados y es necesario responder con rapidez y eficacia.
En otras guías de esta serie, nos centramos en mejorar time to know. En nuestra guía de gestión de calidad alerta, nos centramos en reactive formas de mejorar el tiempo para saber, y en nuestra guía de administración a nivel de servicio nos centramos en proactive métodos.
En la guía que estás leyendo ahora, nos centramos en mejorar time to understand y time to resolve.
Indicadores de rendimiento clave - operacional
Hay muchas métricas discutidas y debatidas en el mundo de la “gestión de incidentes” y la teoría de la ingeniería de confiabilidad del sitio (SRE); sin embargo, la mayoría está de acuerdo en que es importante centrarse en un pequeño conjunto de indicadores de rendimiento clave.
Los KPI a continuación son los indicadores más comunes utilizados por las prácticas exitosas de ingeniería de confiabilidad del sitio (SRE) y gestión de incidentes.
Percepción de confiabilidad del usuario final
La forma en que los clientes perciben el rendimiento de su producto es fundamental para comprender cómo medir la urgencia y la prioridad. Además, comprender la perspectiva de los clientes ayuda a comprender cómo la empresa ve el problema, así como a comprender el flujo de trabajo requerido para respaldar las capacidades impactadas. Una vez que comprenda la percepción de los clientes y del negocio, podrá comprender mejor qué podría estar afectando la confiabilidad de dichas capacidades.
En última instancia, la observabilidad desde la perspectiva de los clientes es el primer paso para volverse proactivo y competente en ingeniería de confiabilidad.
Hay dos experiencias principales que impactan la percepción del usuario final sobre el rendimiento de su producto digital y sus capacidades. Los términos a continuación son desde la perspectiva de los clientes utilizando el lenguaje común de los clientes.
Causa raíz versus causa directa
La causa raíz de un problema no es lo mismo que la causa directa de ese problema. Del mismo modo, solucionar la causa directa (a corto plazo) no suele significar que se haya solucionado la causa raíz (a largo plazo) del problema. It's very important to make this distinction.
Cuando busque un problema de rendimiento, primero debe intentar encontrar la causa directa del problema haciendo la pregunta "¿Qué cambió?". El componente o comportamiento que cambió no suele ser la causa raíz, pero de hecho es la causa directa que debe resolverse primero. Resolver la causa raíz es importante, pero generalmente requiere una discusión retroactiva posterior al incidente y una gestión del problema a largo plazo.
Por ejemplo: el nivel de servicio para su capacidad de inicio de sesión cae repentinamente. Inmediatamente se descubre que los patrones de tráfico son mucho más altos de lo habitual. Usted traza el problema de rendimiento a una configuración de límite de conexión TCP abierta que está provocando una cola de conexión TCP mucho más grande. Inmediatamente resuelve el problema implementando un aumento del límite de TCP y alguna instancia de servidor adicional. Resolvió la causa directa del problema a corto plazo, pero la causa raíz podría ser cualquier cosa, desde una planificación de capacidad inadecuada, una comunicación perdida por parte de marketing o un despliegue relacionado con consecuencias no deseadas en las cargas ascendentes.
Esta distinción también se hace en ITIL/ITSM Incident management frente a Problem management. Las causas fundamentales se discuten en conversaciones posteriores al incidente y luego se resuelven en procesos de gestión de problemas a más largo plazo.
Pasos de diagnóstico (descripción general)
Paso 1: definir el problema
La primera regla es establecer rápidamente el planteamiento del problema. Hay muchas guías sobre cómo crear planteamientos de problemas, pero lo mejor es lo simple y efectivo. Un planteamiento del problema bien formado hará lo siguiente:
- Describa lo que está experimentando el usuario final. ¿Cuál es el problema que está experimentando el usuario final?
- Describa el comportamiento esperado de la capacidad del producto. ¿Qué es lo que debería experimentar el usuario final?
- Describa el comportamiento actual de la capacidad del producto. ¿Cuál es la valoración técnica de lo que está experimentando el usuario?
Evite cualquier suposición en el planteamiento de su problema. Cíñete a los hechos.
Paso 2: Encuentra la fuente
La "fuente" es el componente o código más cercano a la causa directa del problema.
Piense en muchas tuberías de agua conectadas a través de muchas uniones, divisores y válvulas. Se le alerta de que su nivel de servicio de salida de agua está degradado. Trazas el problema desde la salida del agua por las tuberías hasta determinar qué unión, split, válvula o tubería está causando el problema. Descubres que una de las válvulas eléctricas está en cortocircuito. Esa válvula es la fuente de tu problema. El corto es la causa directa de su problema. Resuelve fácilmente la causa directa reemplazando el valor. Tenga en cuenta que la causa raíz puede ser algo más complejo, como las condiciones climáticas, los productos químicos en el agua o la fabricación.
Este es el mismo concepto para diagnosticar una pila de tecnología compleja. Si su capacidad de inicio de sesión es limitada (salida), debe rastrear el problema hasta el componente (fuente) que está causando ese límite y solucionarlo. Podría ser el software API (límite de servicio), los servicios de middleware, la base de datos, las limitaciones de recursos, un servicio de terceros o cualquier otra cosa.
En TI existen tres categorías principales de puntos de interrupción para mejorar su tiempo de respuesta:
Output
Input
Client
Definir su desempeño métrico dentro de estas categorías, también conocido como nivel de servicio, mejorará significativamente su tiempo de respuesta para determinar dónde está la fuente del problema. La medición de estas categorías está cubierta en nuestra guía de administración a nivel de servicio. Para comprender cómo utilizarlos en el diagnóstico, siga leyendo.
Paso 3: encuentre la causa directa
Una vez que esté cerca de la fuente del problema, determine qué cambió. Esto le ayudará a determinar rápidamente cómo resolver el problema de forma inmediata y a corto plazo. En el ejemplo del Paso 2, el cambio fue que la válvula ya no funcionaba debido a un hardware degradado que provocaba un cortocircuito.
Ejemplos de cambios comunes en TI son:
- Rendimiento (tráfico)
- Código (despliegue)
- Recursos (asignación de hardware)
- Cambios de dependencia ascendentes o descendentes
- Volumen de datos
Para ver otros ejemplos comunes de problemas que afectan el rendimiento, consulte la matriz de problemas a continuación.
Utilice puntos de datos de salud
Como se mencionó anteriormente, existen tres categorías de rendimiento principales que impulsan su viaje de diagnóstico. Comprender estos puntos de datos de salud reducirá significativamente el tiempo necesario para comprender dónde está el origen del problema.
Matriz de problemas
La matriz de problemas es una hoja de referencia de problemas comunes categorizados según los tres puntos de datos de salud.
Las fuentes de los problemas están ordenadas según su frecuencia, siendo las más comunes en la fila superior y a la izquierda. A continuación se enumera un desglose más detallado. Una administración a nivel de servicio bien hecha le ayudará a descartar dos de cada tres de estos puntos de datos rápidamente.
Esta tabla es una matriz de problemas ordenada por puntos de datos de salud:
| Punto de datos | Capacidad de New Relic | Fuentes de problemas comunes | | ---------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Salida | APM, infraestructura, logs, NPM | aplicación, fuentes de datos, cambio de configuración de hardware, infraestructura, red interna, proveedor externo (AWS, GCP) | | Entrada | Sintético, logs | Enrutamiento externo (CDN, puertas de enlace, etc.), enrutamiento interno, cosas en el Internet (ISP, etc.) | | Cliente | navegador, móvil | código de navegador o móvil |
Los problemas tienden a agravarse, pero el objetivo es "encontrar la fuente" y luego determinar "qué cambió" para restaurar rápidamente el nivel de servicio.
Problemas de ejemplo
Veamos un problema de ejemplo. Digamos que su empresa lanza un nuevo producto y el aumento significativo de solicitudes provoca un tiempo de respuesta inaceptable. La fuente se descubre en el servicio de middleware de inicio de sesión. El problema es un salto en los tiempos de cola TCP.
Aquí hay un desglose de esta situación:
- Category: rendimiento de salida
- Source: iniciar sesión en el middleware
- Direct cause: Tiempos de cola TCP debido a la carga de solicitudes adicionales
- Solution: mayor límite de conexión TCP y recursos escalados
- Root-cause: planificación de capacidad insuficiente y pruebas de control de calidad en el servicio descendente que afectan el middleware de inicio de sesión
Otro problema de ejemplo
Aquí hay otro problema de ejemplo:
- Hubo un aumento repentino en 500 errores de puerta de enlace al iniciar sesión...
- El tiempo de respuesta de la API de inicio de sesión aumentó hasta el punto en que comenzaron los tiempos de espera...
- Los tiempos de espera se trazaron a las conexiones de la base de datos en la capa de middleware...
- La traza de la transacción reveló un aumento significativo en el número de consultas de la base de datos por solicitud de inicio de sesión...
- Se encontró un marcador de despliegue para un despliegue que ocurrió justo antes del problema.
Aquí hay un desglose de esta situación:
- Category: degradación del rendimiento de salida que conduce a una falla en el rendimiento de entrada
- Source: base de datos de llamada de servicio de middleware
- Direct cause: 10 veces mayor consulta de la base de datos después de la implementación del código
- Solution: despliegue de retroceso
- Root-cause: pruebas de garantía de calidad insuficientes
Matriz de problemas por fuente
A continuación se muestra una tabla con la matriz de problemas ordenada por fuentes.
Source | Common direct causes |
|---|---|
Aplicación |
|
Fuente de datos |
|
Redes internas y enrutamiento |
|
Identificación de anomalías en el patrón de rendimiento
Sugerencia
Tener un nivel de servicio bien formado en los límites de su servicio relacionados con la clave de transacción (capacidades) le ayudará a identificar más rápidamente en qué flujo de trabajo de extremo a extremo reside el problema.
Identificar un patrón de anomalía mejorará su capacidad para identificar cuál y dónde puede estar la causa directa de los problemas.
Hay mucha información excelente y clases gratuitas en línea sobre cómo identificar patrones, pero el concepto general es bastante simple y puede desbloquear poderosas capacidades de diagnóstico.
La clave para identificar patrones y anomalías en los datos de rendimiento es que no necesita saber cómo debería funcionar el servicio: solo necesita determinar si el comportamiento reciente cambió.
Los ejemplos proporcionados en esta sección utilizan el tiempo de respuesta o la latencia como métrica, pero puede aplicar el mismo análisis a casi cualquier conjunto de datos, como errores, rendimiento, métricas de recursos de hardware, profundidad de cola, etc.
Normal
A continuación se muestra un ejemplo de un gráfico de tiempo de respuesta aparentemente volátil (7 días) en APM. Mirando más de cerca, puedes ver que el comportamiento del tiempo de respuesta es repetitivo. En otras palabras, no hay ningún cambio radical en el comportamiento durante un período de 7 días. Los picos son repetitivos y no inusuales en comparación con el resto de la línea de tiempo.
De hecho, si cambia la vista de los datos de average over time a percentiles over time, queda aún más claro cuán "regulares" son los cambios en el tiempo de respuesta.
Anormal
Este gráfico muestra un tiempo de respuesta de la aplicación que parece haber aumentado de manera inusual en comparación con el comportamiento reciente.
Esto se puede confirmar utilizando la comparación semana tras semana.
Vemos que el patrón ha cambiado y que parece estar empeorando con respecto a la comparación de la semana pasada.
Encontrar la fuente
A continuación, veremos cómo encontrar la fuente en New Relic. Tenga en cuenta que este flujo de trabajo se basa en rastreo distribuido.
Primero, encontrarás una aplicación relacionada con la latencia o errores que experimenta el usuario final. Esto no significa que la aplicación o el código sean el problema, pero encontrar cualquier aplicación dentro del flujo (primero) lo acercará más rápidamente a la fuente. Una vez encontrada esta aplicación, puede descartar rápidamente componentes como código, host, base de datos, configuración y red.
Una vez identificada la aplicación, la pregunta es qué transacciones dentro de esa aplicación son parte del problema. Utilice la aplicación que identificó como que experimenta un problema de rendimiento e identifique qué transacción o transacciones se ven afectadas. Aquí puede repetir la habilidad de anomalía del patrón de desempeño descrita anteriormente en Identificar anomalías del patrón de desempeño, pero esta vez en la transacción misma.
Los siguientes documentos le ayudarán a utilizar New Relic para identificar transacciones problemáticas:
- Página de transacciones: Encuentre problemas de rendimiento específicos
- Transacción lenta en la página de resumen del servicio.
Una vez que se identifican las transacciones problemáticas, puede utilizar rastreo distribuido para revisar los componentes de extremo a extremo que respaldan esa transacción. rastreo distribuido lo ayuda a identificar rápidamente dónde está la latencia y/o dónde ocurren los errores en toda su stack, todo desde una sola vista.
Los siguientes recursos le ayudarán a aprender cómo utilizar rastreo distribuido para identificar el componente fuente del problema:
- Introducción al rastreo distribuido
- Cómo utilizar la UI de rastreo distribuido
- Seminarios web gratuitos en línea sobre rastreo distribuido
- Un vídeo sobre el uso del rastreo distribuido para el análisis de causas directas
Aquí hay un breve resumen de los pasos para encontrar la fuente:
- Examinar una aplicación relacionada con el rendimiento afectado.
- Identifique qué transacciones están contribuyendo al problema.
- Utilice rastreo distribuido para identificar el componente problemático dentro del flujo de un extremo a otro.
Ahora podemos pasar al paso final, identificar la causa directa.
Encontrar la causa directa
Una vez que se encuentra el componente fuente, puede comenzar a determinar la causa directa.
Utilizando el conocimiento de los pasos anteriores, sabrá si el problema es la latencia, el éxito o ambos.
Los problemas de latencia se pueden encontrar usando la traza de la transacción y/o "span en proceso" dentro de rastreo distribuido.
El mensaje de error de problemas de éxito también se puede ver en la traza, pero los mejores detalles para los problemas de éxito generalmente se encuentran en el log de aplicación.
De cualquier manera, si usted es el respondedor de incidentes de primer nivel o una ingeniería de confiabilidad del sitio (SRE), encontrar la causa directa recaería en los expertos en la materia (PYME), que generalmente son los desarrolladores y el ingeniero responsable del componente fuente. encontró.
El siguiente paso más eficaz después de descubrir el componente fuente es ponerse en contacto con los expertos en la materia de dicho componente. Muéstreles los datos descubiertos en la clasificación y los diagnósticos que haya completado para tener ventaja en la resolución de problemas.
Sugerencia
Tenga en cuenta que tanto el contexto de inicio de sesión como el rastreo distribuido están habilitados de forma predeterminada con nuestro agente más nuevo. (Si no ha actualizado su agente por un tiempo, le recomendamos actualizarlo periódicamente).
Log-in-context y rastreo distribuido son capacidades críticas necesarias para reducir el tiempo de clasificación, diagnóstico y resolución de problemas a largo plazo.
¡Ahora, adelante y conviértete en un excelente ingeniero de confiabilidad del sitio con New Relic!
Próximos pasos
Si aún no lo ha hecho, es posible que desee leer algunas de nuestras guías de madurez de observabilidad relacionadas, que incluyen: