Monitoreo de API, que deberías medir
Cuando se trata de monitoreo de APIs o servicios webs, que crees es lo más importante a considerar? En general el almacenamiento de métricas es siempre útil, pero no siempre todo lo que se almacena sirve y es información accionable. En este artículo intentare darte una idea sobre que información enfocarte y el porque creo que es importante. Mayormente las siguientes recomendaciones fueron tomadas en cuenta desde un punto de vista técnico y de negocio, el cual ayudarán a un equipo de analistas o a un grupo de desarrollo.
Métricas de Infraestructura
Disponibilidad (Uptime)
La disponiblidad puede ser describa como el tiempo que nuestro servicio en línea (uptime) y los tiempos en que el servicio esta muerto (downtimes), pero siendo honesto, nadie quiere tener downtimes y la disponibilidad de una API debe ser al menos del 99% todo el tiempo.
Si bien es una de las métricas más básicas, el tiempo de actividad o la disponibilidad es el estándar de oro para medir la disponibilidad de un servicio. Muchos acuerdos empresariales incluyen un SLA por sus siglas en inglés (Service Level Agreement), y el tiempo de actividad generalmente se suma a eso. Muchas veces, escucharás términos como triple 9 o cuatro 9, que es una medida de cuánto tiempo de actividad frente al tiempo de inactividad hay por año.
| Disponibilidad | Tiempos de inactividad al año |
| 99% | 3.65 días |
| 99.9% | 8.77 horas |
| 99.99% | 52.60 min |
| 99.999% | 5.26 min |
La disponibilidad parece una de las métricas más sencillas de registrar, sin embargo hasta las APIs más confiables experimentan tiempos de inactividad imprevistos mínimos, casi indetectables algunas veces y no siempre tienen que ver que el servicio este caído, sino con las cargas de trabajo que se estén procesando (esto es más probable que ocurra con APIs escritas con NodeJS donde solamente hay 1 servidor recibiendo y respondiendo peticiones).
La disponibilidad de un servicio se mide más comúnmente a través de un servicio de ping o pruebas sintéticas, como Pingdom o UptimeRobot. Puede configurar sondeos para que se ejecuten en un intervalo fijo, como cada minuto, para verificar endpoints específicos, como /health o /status. Este endpoint debe tener pruebas de conectividad básicas, como cualquier almacenamiento de datos de respaldo u otros servicios, no solamente una solicitud y respuesta inmediata.
Procesamiento (CPU Usage)
Esta es una de las mediciones más clásicas y determinan la cantidad de procesamiento que necesita un determinado endpoint, muy útil si deseas saber en que momento separar una función específica en muchas más pequeñas.
El uso elevado de la CPU puede significar que el servidor está sobrecargado, o que hay un error de rendimiento en la aplicación, como demasiados spinlocks. Muchos devops utilizan esta métrica (junto con su métrica hermana, el uso de memoria) para la planificación de recursos y la medición del estado general. Ciertos tipos de aplicaciones por su naturaleza tienen un mayor uso de la CPU que otras métricas, junto con cargas de trabajo que involucran matemáticas de punto flotante pesadas, como la codificación de video y las cargas de trabajo de aprendizaje automático.
Memoria (Memory Usage)
Al igual que el uso de la métrica de procesamiento, el uso de la memoria también es importante ya que se utiliza para medir la utilización de los recursos, ya que la CPU y la capacidad de la memoria son recursos físicos a diferencia de una métrica que puede depender más de la configuración.
El alto uso de memoria puede ser un indicador de servidores sobrecargados también. Tradicionalmente, las consultas de big data/streams y las bases de datos consumen mucha más memoria que CPU.
Métricas del servicio
Latencia
Es una de las métricas más importantes para rastrear la experiencia del cliente, si bien un aumento en las métricas de nivel de infraestructura, como el uso de la CPU, en realidad puede no corresponder a una caída en la capacidad de respuesta percibida por el usuario, la latencia de la API definitivamente lo hará.
Es el tiempo calculado entre que nuestro servidor recibe una petición y entrega una respuesta (milisegundos), en términos generales, mientras más corto sea este tiempo es mucho mejor y para tenerlo en cuenta, la latencia puede verse afectada por muchos factores externos como el tráfico de la red, la distancia geográfica entre el cliente y el servidor, o la sobrecarga de recursos en la máquina host.
Hay que tomar en cuenta que al iniciar un proyecto de API, la mayoría de los endpoints suelen responder con tiempos aceptables, pero conforme pasa el tiempo (años), algunos endpoints suelen volverse lentos ya que la información administrada por la BD suele impactar en los tiempos de búsqueda y respuesta, básicamente porque la BD crece y sin los modificadores correctos de optimización, las respuestas se veran afectadas.
Códigos de estado
El seguimiento de las respuestas HTTP puede brindarte detalles granulares sobre una API individual, pero el seguimiento de códigos de estado específicos pueden brindarte una mejor comprensión del tipo de problema. Por ejemplo, algunos proveedores de API responderán con un estado 200 OK, incluso cuando ocurrió un error. Esta métrica falsa puede llevarte a creer que todo está funcionando como se esperaba, pero los usuarios pueden experimentar problemas y su registro interno puede contar una historia diferente.
Métricas del negocio
Consumo
Puede ser fácil olvidar el uso o el consumo al monitorear las API. Es posible que las API internas no requieran una métrica de uso, pero la telemetría en el consumo de API de terceros puede ayudar a tomar decisiones comerciales. Calcular los costos al consumir un servicio web puede resultar difícil sin los datos adecuados. El consumo se puede evaluar en su conjunto o en ráfagas. Algunos proveedores de API facturan mensualmente, pero algunos pueden tener límites de tarifas en sus niveles de precios que también vigilan el uso durante un período de tiempo más pequeño.
Al realizar un seguimiento del consumo y configurar alertas para un uso elevado, puede evitar costos innecesarios. Además, reconocer cuándo no se utilizan las API también puede ser beneficioso. La falta de consumo es una señal de que una API sigue siendo parte de su base de código, pero puede que no sea vital para tu aplicación.
Crecimiento o uso
Una API no solo debe estar libre de errores, sino que debe crecer mes tras mes. Este métrica debe medirse en intervalos largos, como días o meses, para comprender las tendencias reales. Si mide el crecimiento de la API mes a mes, te recomiendo que elija 28 días en su lugar, ya que se elimina cualquier sesgo debido al uso de fines de semana frente a los días de la semana y también las diferencias en la cantidad de días por mes. Por ejemplo, febrero puede tener solo 28 días, mientras que el mes anterior tiene 31 días completos, lo que hace que febrero parezca tener un uso menor.
Recapitulando
Medir todas estas métricas puede parecer una tarea abrumadora. pero si tu servicio crees qe definitivamente crecerá conforme pasa el tiempo, estas recomendaciones son un "must" para que puedas ofrecer un mejor servicio.
Photo by Clint Adair on Unsplash
