Selección de indicadores importantes (fuera de la CPU/disco/red)

título

Imagínese por un segundo que de repente lo ascendieron de un antiguo desarrollador normal a un arquitecto senior, y se le asignó la tarea de supervisar el trabajo de telemetría para todos los equipos de ingeniería de su organización. Hace poco tuve una conversación en DevOps Days Toronto con alguien que tuvo esta experiencia en particular. Se le acaba de encargar que descubra cómo estabilizar los esfuerzos de 68 equipos de desarrollo diferentes (!). Por "estabilización" se refería a corregir el comportamiento inestable de su producto, que comenzaba a tener grandes bloqueos.

Todos sus equipos trabajaron en diferentes partes de una única gran arquitectura de microservicios que se volvió lo suficientemente grande como para que los esfuerzos individuales para desarrollar cada servicio crecieran y se detuvieran. Debido a que era conocido como un ingeniero amigable y talentoso que contribuía a muchos servicios de forma individual, la compañía decidió "DevOps", es decir, lo destacó del equipo actual para enfocarse en hacer que todo el sistema funcione mejor en conjunto. Estaba feliz de poder ayudar, pero le resultaba difícil saber cómo empezar. Sabía que quería algunos datos que le dieran una buena idea de los problemas, pero su pregunta era qué necesitaba medir exactamente.

Índice

    Las métricas de CPU, memoria, red y disco no son buenas maestras

    Mucho se ha escrito sobre la teoría de elegir buenos indicadores. Escribí antes, por ejemplo, que Hipótesis de buenos sistemas de prueba de desempeño. Con esto quiero decir que cuando pensamos en los sistemas que construimos y cómo deberían funcionar (por ejemplo, esta cola debería manejar 50 000 registros por segundo, o que el balanceador siempre debería elegir al trabajador menos ocupado), el buen desempeño confirma nuestras verdaderas suposiciones, desacreditar nuestros errores de opinión y mostrarnos casos extremos. Nos enseñan cómo funcionan realmente las cosas que construimos.

    Según esta figura, el clásico triunvirato CPU/memoria/red es mediocre en el mejor de los casos. Puede tener una hipótesis importante sobre la cantidad de RAM o CPU que debe usar el procesador, y puede aprender algo sobre su creación (o muy probablemente el intérprete principal, el sistema operativo o el recolector de basura) si su suposición no se confirma con la práctica. Sin embargo, las métricas que miden cosas como cuánto tiempo lleva una llamada de base de datos en particular, o cuentan la cantidad total de flujos de trabajo o elementos en cola, reflejan suposiciones que contribuyen a una mejor comprensión de lo que le preocupa.

    Dejame darte un ejemplo. Supongamos que ha creado un proceso que se espera que consuma un 4 % de CPU y 400 000 RAM por grupo de 1000 conexiones de base de datos, pero el sistema de producción que ejecuta su proceso utiliza un orden de magnitud más de RAM y CPU de lo que suponía. ¿Aprendió algo sobre su proceso o aprendió algo sobre el host que inicia su proceso? El problema con métricas como el uso de CPU y memoria es que miden el sistema, no el proceso. Estas métricas le enseñan más sobre el sistema operativo y la sobrecarga del tiempo de ejecución de lo que realmente le interesa.

    Como elijo cifras significativas desde cero

    Crear un sistema distribuido no es lo mismo que comprenderlo, y los ingenieros experimentados a menudo pueden adivinar qué tan bien el equipo que lo administra comprende la arquitectura. La evidencia está en todas partes: en la profundidad con la que probamos nuestro código, en la forma específica en que rastreamos los servicios, en la precisión con la que podemos obtener nuestros planes de energía e incluso en la forma en que podemos implementar nuestros cambios.

    Un arquitecto recién nombrado que preguntó "¿por dónde empiezo?" la pregunta era un ingeniero experimentado. Sabía que se estaba desempeñando bien y sabía que los equipos que tenía la tarea de sincronizar no entendían lo que estaban creando. No necesitaba conferencias sobre teoría y no iba a perder el tiempo pidiendo a los equipos que determinaran su rendimiento. Necesitaba enganchar los ganchos; la pregunta era ¿dónde?

    Bueno, déjame decirte lo que funcionó para mí en el pasado. Cada vez que me piden que maneje un paquete de software grande y tumultuoso que no escribí, lo dibujo, y esta imagen inevitablemente resulta ser similar a la Figura 1. De hecho, es una de las imágenes reales que dibujé cuando era fotografiado por primera vez y tratando de averiguar cómo funciona en la práctica la arquitectura de microservicios de Librato.

    libreto-arquitectura

    Paso 1: Medir el espacio entre servicios

    Por lo general, nos enfocamos en las cajas y, al final, queremos saber cómo funciona cada uno de estos servicios para obtener algunas métricas que son indicadores clave de qué tan bien están haciendo lo que deberían estar haciendo. Sin embargo, en este caso ignoraremos por completo las casillas. De hecho, voy a eliminar todas esas etiquetas de cuadro y etiquetaré las filas en su lugar. Sobre cada línea voy a colocar una etiqueta que define el protocolo que representa cada una de estas líneas.

    librato-microservicios-arquitectura

    Compruébelo: nuestra arquitectura de microservicio anteriormente oscura se ha convertido en un puñado de protocolos de red comerciales. Cada aplicación que creamos es una ecuación balanceada; funcionará bien siempre que esté en equilibrio y eventualmente erradicaremos cualquier cosa que pueda ponerlo fuera de servicio. Pero por el momento, la mejor manera de detectar si no está equilibrado es medir el tiempo de interacción entre sus componentes, medir el espacio entre los servicios. Nuestra estrategia será encontrar una manera de calcular el tiempo de las interacciones representadas por cada una de estas líneas.

    Si hice que eso pareciera fácil, no lo es. Obtener estas cifras, que en conjunto llamo datos de demora entre servicios, requerirá muchos conocimientos técnicos. En casi todos los casos, tendrá que ir a la fuente y agregar algunas herramientas que envuelvan las llamadas a la API o la base de datos. A veces necesitará reconfigurar un conjunto de servidores web o proxies, y de vez en cuando tendrá que escribir su propio código de conexión o API contenedora.

    Debería obtener un conjunto de números del orden de decenas o cientos de milisegundos. Si algo sale mal con la aplicación, estos números le indicarán dónde está el problema (en qué servicio y en qué nodos). Tenga en cuenta que esto no es lo mismo que decirle cuál es realmente el problema, pero llegaremos a eso en un minuto.

    Por supuesto, tendrá que poner todos estos datos en alguna parte. Aquí están las cosas que yo (y muchas otras) Escribí sobre eso durante mucho tiempo, pero debe tenerse en cuenta aquí que necesitará un sistema de telemetría escalable para ayudar a almacenar y analizar todo.

    Paso 2: extraiga conocimiento de sus datos de retraso

    Juega con estos números cuando ejecutes cada uno. Presta atención a los valores básicos y busca patrones de comportamiento y cosas que te parezcan extrañas. ¿Están aumentando y disminuyendo algunos retrasos en el servicio? ¿Algunos parecen dependientes de otros? ¿Cambian según la hora del día o el día de la semana? Si encuentra estas plantillas, hable con los ingenieros que ejecutan los servicios y vea si estas plantillas confirman su comprensión de cómo debería funcionar el servicio. No debería pasar mucho tiempo antes de que tú u otra persona noten algo en los datos que te haga decir algo como "ja". Este es el sonido del descubrimiento científico. Sumérjase en estos comportamientos de servicio con la ayuda de un ingeniero que los gestione y es probable que encuentre cifras significativas o dos.

    Si algo sale mal, mire los retrasos de datos entre los servicios y vea qué tan pronto puede determinar qué está pasando de lado. Los números tienden a crecer frente a los servicios que realmente tienen problemas. Comparta sus datos con los ingenieros que ejecutan estos servicios, profundice en los números juntos para descubrir qué salió mal y probablemente obtendrá buenos resultados.

    Paso 3: Repita

    Si esto suena más lento y consume más tiempo que instalar un APM completamente automatizado, es cierto, pero el jugo, en forma de información que obtiene sobre sus servicios y las métricas que incorporan ese conocimiento, bien vale la pena. Los indicadores efectivos requieren atención y paciencia. Requieren un poco de esfuerzo para identificarlos, pero cada uno es una manifestación de perspicacia; todos te enseñan algo que no sabías sobre los servicios que atiendes; cada uno es algo para ser valorado, compartido y hablado.

    En la vida de cada ingeniero que se ocupa de los datos de telemetría, llega un momento en el que desea dejar de jugar con las herramientas de monitoreo y comenzar a jugar con los datos de monitoreo. Si está dispuesto a traducir su tiempo de las métricas de gestión de la infraestructura al uso de la infraestructura de la infraestructura, Regístrese para una prueba gratuita hoy, y permítanos ayudarlo a identificar y rastrear sus indicadores clave de rendimiento.

    Artículos de interés

    Subir