Header Ads Widget

Ticker

6/recent/ticker-posts

13 métricas importantes para las empresas de API


Las métricas son cruciales para cualquier producto. Entonces, ¿cuáles son algunos KPI que las empresas de API deben monitorear? Aquí hay 13 métricas útiles de infraestructura y productos.

El triángulo de la observación y el análisis de API

Cuando se trata de analítica y observabilidad de API, sus métricas pueden considerarse como un triángulo: métricas de infraestructura para la estabilidad, métricas de aplicaciones para resolver problemas operativos comerciales y métricas de productos  para gestionar problemas comerciales clásicos.

Las métricas también dependen de dónde se encuentre en el ciclo de vida del producto. Una API lanzada recientemente se centrará más en mejorar el diseño y el uso al tiempo que sacrifica la confiabilidad y la compatibilidad con versiones anteriores. Mientras que un equipo que respalda una API empresarial bien adoptada puede concentrarse más en impulsar la adopción de funciones adicionales por cuenta y dar prioridad a la confiabilidad y la compatibilidad con versiones anteriores sobre el diseño.

¿A quién le importan las métricas de API?

Por lo general, hay algunos equipos que se preocupan por las métricas de API:

  • Gestión de productos : los gerentes de productos de API están a cargo de las funciones de la API de mapas de ruta , lo que garantiza que se creen los puntos finales de API correctos. También deben equilibrar las necesidades de los clientes (ya sean internos o externos) con el tiempo de ingeniería y las limitaciones personales.
  • Negocio / Crecimiento : los equipos orientados a los negocios, como marketing y ventas, no piensan en términos de puntos finales de API. En cambio, están interesados ​​principalmente en la adopción por parte de los clientes y en asegurarse de que los clientes estén utilizando con éxito las API. También aprecian saber de dónde vienen los usuarios y cuáles podrían ser nuevas oportunidades de venta.
  • Ingeniería de aplicaciones / plataforma : los desarrolladores de API son responsables de agregar nuevas funciones a las API mientras depuran problemas específicos de la aplicación en la lógica empresarial de la API. Estos productos pueden ser API como servicio, complementos, integraciones para socios, API incorporadas en un producto más grande u otros tipos.
  • Infraestructura / DevOps : los equipos de infraestructura y DevOps utilizan métricas para garantizar que los servidores estén funcionando y que los recursos limitados se asignen correctamente. Estos datos podrían resultar útiles para varios equipos de ingeniería.

Métricas de API de infraestructura

A continuación, se incluyen algunas métricas de API de infraestructura útiles para considerar el seguimiento. Muchas de estas métricas son el foco de las herramientas de supervisión del rendimiento de aplicaciones (APM) y las empresas de supervisión de la infraestructura como Datadog.

1: tiempo de actividad

Si bien es una de las métricas más fundamentales, el tiempo de actividad es el estándar de oro para medir la disponibilidad de un servicio. Muchos acuerdos empresariales incluyen un SLA (Acuerdo de nivel de servicio), y el tiempo de actividad generalmente se suma a eso. Muchas veces, escucharás frases como triples nueves o cuatro nueves. Se refieren a cifras porcentuales que miden cuánto tiempo de actividad hay por año.

DISPONIBILIDAD %TIEMPO DE INACTIVIDAD POR AÑO
99% ("dos nueves")3,65 días
99,9% ("tres nueves")8,77 horas
99,99% ("cuatro nueves")52.60 minutos
99,999% ("cinco nueves")5.26 minutos

Por supuesto, pasar de cuatro a cinco nueves es mucho más difícil que pasar de dos a tres nueves, por lo que no verá cinco nueves excepto con los servicios más críticos (y costosos) para la misión.

Dicho esto, ciertos servicios en realidad pueden tener un menor tiempo de actividad al tiempo que garantizan un manejo elegante de las interrupciones sin afectar su servicio. El tiempo de actividad se mide más comúnmente a través de un servicio de ping o pruebas sintéticas, como a través de Pingdom o UptimeRobot . Puede configurar sondeos para que se ejecuten en un intervalo fijo, como cada minuto, para sondear un punto final específico como /health/statusEste punto final debe tener pruebas de conectividad básicas, como cualquier almacenamiento de datos de respaldo u otros servicios. Puede publicar fácilmente estas métricas en su sitio web utilizando herramientas como Statuspage.io .

Los servicios de ping más sofisticados llamados pruebas sintéticas pueden realizar configuraciones de prueba más elaboradas, como ejecutar una secuencia específica y afirmar que la carga útil de respuesta tiene un valor particular. Sin embargo, tenga en cuenta que las pruebas sintéticas pueden no ser representativas del tráfico real de sus clientes. Puede tener una API con errores mientras mantiene un alto tiempo de actividad.

¿Qué es la monitorización sintética ?
Como su nombre lo indica, el monitoreo sintético es un conjunto predefinido de llamadas API que un servidor (generalmente un servicio de Monitoreo) activa para llamar a su servicio. Si bien no refleja las experiencias de los usuarios del mundo real, es útil ver que la secuencia de estas API funciona como se esperaba.

2: uso de la CPU

El uso de la CPU es una de las métricas de rendimiento más clásicas que puede ser un proxy de la capacidad de respuesta de la aplicación. El uso elevado de la CPU del servidor puede significar que el servidor o la máquina virtual están suscritos y sobrecargados, o puede significar un error de rendimiento en su aplicación, como demasiados spinlocks. Los ingenieros de infraestructura utilizan el uso de la CPU (junto con su métrica hermana, el porcentaje de memoria) para la planificación de recursos y la medición del estado general. Ciertos tipos de aplicaciones, como los servicios de proxy de gran ancho de banda y las puertas de enlace API, naturalmente tienen un mayor uso de la CPU, junto con cargas de trabajo que involucran matemáticas de punto flotante pesadas, como la codificación de video y el aprendizaje automático.

Al depurar API localmente, puede ver fácilmente el sistema y procesar el uso de la CPU a través del Administrador de tareas en Windows (o el Monitor de actividad en Mac ). Sin embargo, probablemente no desee utilizar SSH y ejecutar el topcomando en un servidor. Aquí es donde varios proveedores de APM pueden resultar útiles. Los APM generalmente incluyen un agente que puede integrar en su aplicación o en el servidor que captura las métricas de uso de la CPU y la memoria. También puede realizar otra supervisión específica de la aplicación, como la creación de perfiles de subprocesos.

Al observar el uso de la CPU, es esencial observar el uso por CPU virtual (es decir, subproceso físico). El uso desequilibrado puede implicar que las aplicaciones no estén correctamente subprocesadas o un grupo de subprocesos de tamaño incorrecto.

Muchos proveedores de APM le permiten etiquetar una aplicación con varios nombres para que pueda realizar resúmenes. Por ejemplo, es posible que desee tener un desglose de cada uno de métricas VM, como _my-api-westus-vm0__my-api-westus-vm1__my-api-eastus-vm0_, etc, mientras que tienen estas enrolladas en una sola aplicación llamada _my-api_.

3: uso de memoria

Al igual que el uso de la CPU, el uso de la memoria también es un buen proxy para medir la utilización de recursos. La capacidad de la CPU y la memoria son recursos físicos, a diferencia de otras métricas, que pueden depender más de la configuración. Una máquina virtual con un uso de memoria extremadamente bajo puede reducirse o tener servicios adicionales asignados a esa máquina virtual para consumir memoria adicional. Por otro lado, el alto uso de memoria puede ser un indicador de servidores sobrecargados.

Tradicionalmente, las consultas de big data, el procesamiento de flujos y las bases de datos de producción consumen mucha más memoria que la CPU. De hecho, el tamaño de la memoria por máquina virtual es un buen indicador de cuánto tiempo puede tardar su consulta por lotes, ya que más memoria disponible puede reducir los puntos de control, la sincronización de red y la paginación en el disco. Al observar el uso de la memoria, también debe mirar el número de fallas de página y operaciones de E / S. Un error común es configurar una aplicación para asignar solo una pequeña fracción de la memoria física disponible. Esto puede provocar una alteración de la memoria virtual de página artificialmente alta.

Métricas de la API de la aplicación

4: Solicitud por minuto (RPM)

RPM (Solicitudes por minuto) es una métrica de rendimiento que se utiliza a menudo al comparar HTTP o servidores de bases de datos. Por lo general, su RPM de un extremo a otro será mucho más bajo que un RPM anunciado, que sirve más como un límite superior para una API simple de "Hola mundo". Esto se debe a que un servidor no considerará la latencia incurrida por operaciones de E / S en bases de datos, servicios de terceros, etc.

Si bien a algunos les gusta presumir de sus altas RPM, el objetivo de un equipo de ingeniería debe ser la eficiencia e intentar reducir esto. Ciertas funciones comerciales que requieren muchas llamadas a la API se pueden combinar en menos llamadas a la API para reducir este número. Los patrones comunes como agrupar múltiples solicitudes en una sola solicitud pueden ser muy útiles, además de garantizar que tenga un esquema de paginación flexible .

Su RPM también podría variar según el día de la semana o incluso la hora del día, especialmente si sus consumidores presentan un menor uso durante las noches y los fines de semana. Algunas situaciones justifican el seguimiento de métricas de aplicaciones más detalladas, como RPS (solicitudes por segundo) o QPS (consultas por segundo).

5: Latencia media y máxima

Una de las métricas más importantes que se utilizan para medir la experiencia del cliente es la latencia. Si bien es posible que un aumento en las métricas a nivel de infraestructura, como el uso de la CPU, no corresponda en realidad a una caída en la capacidad de respuesta percibida por el usuario, la latencia de la API definitivamente lo hará.

Sin embargo, el seguimiento de la latencia por sí solo puede no proporcionar una comprensión completa de por qué se produjo un aumento. Por lo tanto, es importante seguir cómo la latencia se ve afectada por los cambios de la API, como el lanzamiento de nuevas versiones, la adición de puntos finales o el cambio del esquema de la API. Esto puede ayudar a revelar la causa raíz de los aumentos de latencia.

Dado que los puntos finales problemáticos pueden estar ocultos cuando se mira solo la latencia agregada, es fundamental observar los desgloses de latencia por ruta, geografía y otros campos. Por ejemplo, es posible que tenga un POST /checkoutpunto final que haya aumentado lentamente en latencia con el tiempo, lo que podría deberse a un tamaño de tabla SQL en constante aumento que no está indexado correctamente. Sin embargo, debido al bajo volumen de llamadas a POST /checkout, este problema está enmascarado por su GET /itemspunto final, que se llama mucho más que el punto final de pago. De manera similar, si tiene una API GraphQL, querrá ver la latencia promedio por operación GraphQL.

Ponemos la latencia en aplicación / ingeniería a pesar de que muchos equipos de DevOps / Infraestructura también analizarán la latencia. Por lo general, una persona de infraestructura observa la latencia agregada en un conjunto de VM para asegurarse de que las VM no estén sobrecargadas, pero no profundizan en las métricas específicas de la aplicación, como por ruta.

6: errores por minuto

Al igual que las RPM, los errores por minuto (o tasa de error) es la cantidad de llamadas a la API con una familia de códigos de estado que no son 200 por minuto. El seguimiento de su tasa de error es fundamental para medir qué tan defectuoso y propenso a errores es su API.

Es esencial comprender qué tipo de errores se están produciendo. Los errores 500 podrían implicar errores de código de su parte, mientras que muchos errores 400 podrían implicar errores de usuario de una API mal diseñada o documentada . Esto significa que al diseñar su API, es vital utilizar el código de estado HTTP apropiado .

Puede profundizar más para ver de dónde provienen estos errores. Muchos 401 Unauthorizederrores de una región geográfica específica podrían implicar que los bots están intentando piratear su API.

Métricas de productos API

Las API ya no son solo un término de ingeniería asociado con microservicios y SOA. La API como producto se está volviendo mucho más común, especialmente entre las empresas B2B que desean superar a la competencia con nuevos socios y canales de ingresos. Las empresas impulsadas por API deben observar más que solo métricas de ingeniería, como errores y latencia, para comprender cómo se utilizan sus API (o por qué no se están adoptando tan rápido como se planeó). La función de garantizar que se creen las funciones correctas recae en el administrador de productos API , una nueva función que muchas empresas B2B se apresuran a cumplir.

7: Crecimiento del uso de API

Para muchos gerentes de producto, el uso de API (junto con consumidores únicos) es el estándar de oro para medir la adopción de API. Una API no solo debe estar libre de errores, sino que debe demostrar un crecimiento a lo largo del tiempo. A diferencia de las solicitudes por minuto, el uso de la API debe medirse en intervalos más largos, como días o meses, para comprender las tendencias reales. Si mide el crecimiento de la API mes a mes, le recomendamos que elija 28 días, ya que elimina cualquier sesgo debido al uso de fines de semana frente a los días de la semana y 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.

8: Consumidores únicos de API

Dado que el aumento de un mes en el uso de API podría atribuirse a una sola cuenta de cliente, es importante medir la cantidad de clientes únicos mensuales. Monitorear sus Usuarios Activos Mensuales (MAU) puede proporcionar la salud general de la adquisición y el crecimiento de nuevos clientes. Muchos equipos de plataformas correlacionan API MAU con su MAU web para obtener el estado completo del producto. Si la MAU web está creciendo mucho más rápido que la API MAU, esto podría implicar un embudo con fugas durante la integración o implementación de una nueva solución. Esto es especialmente cierto cuando el producto principal de la empresa es una API; tal es el caso de muchas empresas B2B y SaaS . Por otro lado, API MAU se puede correlacionar con el uso de API para comprender de dónde provino el aumento del uso de API (clientes nuevos frente a clientes existentes).

9: Principales clientes por uso de API

Para cualquier empresa que se centre en B2B, el seguimiento de los principales consumidores de API puede revelar cómo se utiliza su API y dónde existen oportunidades de ventas adicionales. Muchos líderes de productos experimentados saben que muchos productos exhiben dinámicas de ley de potencia, con un puñado de usuarios avanzados que tienen una cantidad de uso desproporcionada que todos los demás. No es sorprendente que estos sean los mismos usuarios avanzados que, en general, aportan a su empresa la mayor cantidad de ingresos y referencias orgánicas.

Esto significa que es fundamental realizar un seguimiento de lo que sus diez clientes principales están haciendo realmente con su API. Puede desglosar aún más esto por los puntos finales que están llamando y cómo los están llamando. ¿Usan un punto final específico mucho más que sus usuarios no avanzados? Tal vez hayan encontrado un momento de "ah-ha" con su API, mientras que otros consumidores no lo han hecho.

10: Retención de API

¿Debería gastar más dinero en su producto e ingeniería o invertir más dinero en el crecimiento? La retención y la rotación (lo opuesto a la retención) pueden indicarle qué camino tomar. Un producto con una alta retención de producto está más cerca de ajustarse al mercado de productos que un producto con un problema de abandono.

A diferencia de la retención de suscripción, la retención de producto rastrea el uso real de un producto. Si bien los dos están correlacionados, no son lo mismo. En general, el abandono de productos es un indicador principal de abandono de suscripciones, ya que los clientes que no encuentran valor en una API pueden quedarse atascados con un contrato anual mientras no utilizan activamente la API. La retención de API debe ser mayor que la retención web. Mientras que la retención de API se centra en los clientes postintegrados, la retención web incluirá a los clientes que iniciaron sesión pero que aún no se integraron necesariamente con la plataforma.

11: Hora del primer Hola mundo (TTFHW)

TTFHW es un KPI importante no solo para realizar un seguimiento del estado de su producto API, sino también para su Experiencia de desarrollador (DX) en general. Especialmente si su API es una plataforma abierta que atrae a desarrolladores y socios externos, desea asegurarse de que puedan comenzar a funcionar lo antes posible. TTFHW mide cuánto tiempo pasa desde la primera visita a su página de destino hasta una primera transacción a través de su plataforma API. Se trata de un marketing de seguimiento de métricas multifuncionales, documentación y tutoriales para la propia API.

12: Llamadas a API por transacción comercial

Si bien más es mejor para muchos productos y métricas comerciales, es importante mantener el número de llamadas por transacción comercial lo más bajo posible para reducir los gastos generales. Esta métrica refleja directamente el diseño de la API. Si un nuevo cliente tiene que realizar tres llamadas diferentes y unir los datos, la API no tiene los puntos finales correctos. Al diseñar una API, es esencial pensar en términos de una transacción comercial y lo que el cliente está tratando de lograr, en lugar de solo características y puntos finales. Una gran cantidad de llamadas por transacción comercial también puede significar que su API no sea lo suficientemente flexible cuando se trata de filtrado y paginación .

13: SDK y adopción de versiones

Muchos equipos de plataformas de API también pueden mantener varios SDK e integraciones. A diferencia de los dispositivos móviles, donde solo tiene iOS y Android como sistemas operativos móviles principales, es posible que tenga decenas o incluso cientos de SDK. Esto puede convertirse en una pesadilla de mantenimiento al implementar nuevas funciones. Puede implementar de forma selectiva funciones críticas en sus SDK más populares, mientras que las funciones menos críticas pueden implementarse en SDK menos populares. Medir la versión de API o SDK también es importante cuando se trata de desaprobar ciertos puntos finales y características. No querrá desaprobar el punto final que usa su cliente que más paga sin consultar por qué lo está usando.

Negocio y Crecimiento

Las métricas de negocio y crecimiento son similares a las métricas de productos, pero se centran en los ingresos, la adopción y el éxito del cliente. Por ejemplo, en lugar de mirar a los diez clientes principales por uso de API, es posible que desee ver los diez clientes principales por ingresos y luego por el uso de sus terminales. Para realizar un seguimiento del crecimiento empresarial, sería beneficioso utilizar herramientas de análisis que ayuden a enriquecer los perfiles de usuario con datos de clientes de su CRM u otros servicios de análisis para comprender mejor quiénes son sus usuarios de API.

Conclusión: realice un seguimiento de las métricas de API adecuadas

Para cualquiera que cree y trabaje con API, es fundamental realizar un seguimiento de las métricas de API correctas. La mayoría de las empresas no lanzarían un nuevo producto web o móvil sin la ingeniería y la instrumentación del producto adecuadas. Del mismo modo, no querrá lanzar una nueva API sin una forma de realizar un seguimiento de las métricas de API correctas.

A veces, los KPI de un equipo pueden combinarse con otro equipo, como vimos con las métricas de uso de API. Además, puede haber diferentes formas de ver la misma métrica subyacente. Sin embargo, los equipos deben concentrarse en buscar las métricas adecuadas para su equipo. Por ejemplo, los gerentes de producto no deberían preocuparse tanto por el uso de la CPU, al igual que los equipos de infraestructura no deberían preocuparse por la retención de API.

 

Publicar un comentario

0 Comentarios