Header Ads Widget

Ticker

6/recent/ticker-posts

Uso de API Analytics para potenciar la plataforma


 Las métricas de API son quizás el factor más importante para mejorar cualquier sistema de API. Las métricas son inherentemente valiosas: el seguimiento de los datos sobre el uso de API, la disponibilidad, el tiempo de actividad y otros conocimientos es fundamental para mantener una plataforma en buen estado constante. Dicho esto, es una verdad desafortunada que muchos desarrolladores no aprovechan al máximo el análisis de API , simplemente prefieren considerar las métricas como una herramienta comercial y poco más.

Es una lástima. Si bien las métricas de API sin duda cumplen una función comercial muy importante en el panorama de las API modernas, se pueden aprovechar a mayores alturas, sirviendo para ampliar las opciones comerciales y las soluciones técnicas en un verdadero enfoque hacia el empoderamiento de la plataforma.

En este artículo, analizaremos las métricas de API en general, citando su importancia y valor específico para los proveedores de API. Con esto en mente, abordaremos algunas métricas que son de vital importancia para rastrear e identificaremos metodologías sólidas para derivar estos datos.

Definición de KPI

Los datos son extremadamente valiosos ya que pueden usarse para hacer que un sistema complejo sea más transparente. Si bien esto es obviamente un beneficio para los hosts de API web, puede ser difícil determinar qué indicadores específicos deben monitorearse. Por esta razón, aquí hay algunos KPI , o indicadores clave de rendimiento , para considerar al generar y revisar métricas de API.

Disponibilidad y tiempo de actividad

Seguimiento del tiempo de actividad y la disponibilidad de la API

Las métricas más importantes cuando se trata de algo tan vivo y de alta demanda como una API son la disponibilidad y el tiempo de actividad . Mientras que el tiempo de actividad describe si el servicio está "encendido" o "apagado", la disponibilidad es un poco más matizada, ya que rastrea la frecuencia con la que el servicio ha fallado, por cuánto tiempo y con qué propósito.

Imaginemos un servidor que proporciona datos multimedia a través de una transmisión codificada . Al hablar del tiempo de actividad, nos gustaría saber un porcentaje del tiempo en el que el servicio estuvo activo. Esta métrica podría ser del 99,999% , que es una métrica absolutamente monstruosa; esto significaría que en un año, el sistema solo estuvo inactivo durante un total de 5 minutos y 15,6 segundos.

Sin embargo, esa no es realmente una métrica útil; solo nos dice la cantidad total de tiempo en el que el recurso estuvo técnicamente inalcanzable. La disponibilidad se preocupa más no solo por si el recurso estaba disponible o no, sino por si el acceso fue completo, sin restricciones y sin obstáculos. Si bien una API podría tener una disponibilidad del 99,999% simplemente al poder llamar al punto final de la API, si el servidor de autenticación está abrumado por conexiones y rechaza 1 de cada 5 conexiones, en teoría, el tiempo de actividad se mantiene mientras la disponibilidad es terrible.

En consecuencia, cuando trabajamos con estas métricas, debemos contextualizarlas absolutamente y extraer significado de ellas. El tiempo de actividad no lo es todo, y sin tiempo de actividad, no se puede determinar la disponibilidad; deben trabajar en conjunto entre sí .

Relacionado: 6 técnicas para 99,999% de tiempo de actividad

Capacidad de respuesta y latencia

Descubra problemas de latencia para optimizar el rendimiento de la API

De manera similar, el seguimiento de la capacidad de respuesta y la latencia agrega una capa secundaria completa al concepto de disponibilidad, al considerar estrictamente si los datos eran fáciles de interactuar y, de hecho, respondían a las solicitudes dentro de un tiempo normal definido específicamente.

En nuestro ejemplo, podríamos tener un tiempo de actividad del 99,999%, e incluso podríamos tener un servicio de llamadas efectivo del 99,999%, pero si cada llamada tardaba 5 horas en responder, entonces nuestra experiencia de usuario no es lo que podría extrapolarse de las métricas de disponibilidad y tiempo de actividad por sí mismos. Si la latencia entre la llamada realizada, la llamada respondida y los datos enviados es demasiado alta, y la capacidad de respuesta en sí es tan astronómicamente baja, la usabilidad real de una API es cuestionable.

Por el contrario, podríamos tener una gran capacidad de respuesta, digamos en milisegundos, y aún así tener una mala disponibilidad o una latencia increíblemente alta . Esto puede ocurrir cuando el servidor que procesa los datos de la API en sí se separa del punto final en el que se realiza la llamada, lo que da como resultado que muchas llamadas fallen, pero aquellas llamadas que tuvieron éxito se atienden inmediatamente a una línea externa lenta. Esto sería básicamente una interacción de baja disponibilidad, respuesta rápida, alta latencia, que es una trifecta de malas situaciones.

Si bien la disponibilidad y el tiempo de actividad describen los valores de un servicio de datos, no necesariamente contextualizan los datos como tales. Sin embargo, la capacidad de respuesta sí, especialmente cuando estos datos se desglosan geográficamente . Ser capaz de identificar fallas en el procesamiento de datos por ubicación geográfica y luego contextualizar esto dentro de los valores de respuesta bajos y altos puede ayudar a contextualizar los valores absolutos creados al analizar la disponibilidad y el tiempo de actividad.

En otras palabras, la disponibilidad y el tiempo de actividad le indican si hay un problema; la capacidad de respuesta y la latencia son claves para identificar por qué existen los problemas.

Lea también: Cómo optimizar el paquete de respuesta API

Valoraciones de punto final

Una métrica muy poderosa es el KPI de la valoración del punto final . Cuando nos involucramos en el descubrimiento de este KPI, lo que realmente estamos haciendo es esta simple pregunta: ¿qué está pasando con los puntos finales? Esta es una pregunta general e implica una gran cantidad de datos que son enormemente valiosos. Para el análisis de endpoints, considere buscar respuestas a preguntas como:

  • Frecuencia : ¿Tenemos puntos finales que se utilizan con más frecuencia que otros? ¿A qué ritmo se utilizan?
  • Comparación de utilización : ¿Cuáles son nuestros puntos finales menos utilizados? ¿Tenemos datos sobre por qué podrían estar tan infrautilizados?
  • Tráfico : ¿Qué endpoints son los más afectados por tráfico malicioso?
  • Vulnerabilidades : cuando ocurre una violación de datos, o cuando las pruebas de penetración han mostrado vulnerabilidad, ¿qué endpoints son responsables?

Las respuestas pueden informar a los proveedores sobre el estado de una API en general, incluida información de la plataforma como:

  • Hinchazón : si tenemos una gran cantidad de puntos finales sin usar, sugiere que estamos admitiendo grandes porciones de base de código que ya no se necesitan; esto es una hinchazón innecesaria .
  • Eficiencia del servicio : si tenemos uno o dos puntos finales que son atacados constantemente, debemos analizarlos. Si cubren varios servicios, esos servicios deben dividirse en sus propios puntos finales para lograr un verdadero enfoque de microservicio.
  • Seguridad : si tenemos puntos finales vulnerables, tenemos un problema en nuestra base de código que permite que las vulnerabilidades se detecten y exploten fácilmente.

La lista sigue y sigue, pero simplemente mirar los puntos finales en lugar de la base de código en sí puede informar gran parte de nuestra comprensión sobre el sistema en general. Piense en estas métricas como síntomas para un médico, mientras que los problemas pueden estar en cualquier paso del sistema API, la identificación de los síntomas en el nivel del punto final informa cómo podemos resolver el problema.

Obtenga información de la supervisión de puntos finales de API específicos

Más sobre métricas de API: éxito frente a fracaso: la importancia de las métricas de API

Conversiones

La conversión de usuarios también es una métrica importante, aunque relacionada con el negocio

Hasta ahora hemos hablado de preocupaciones técnicas, pero también hay KPI comerciales que nos informan sobre la experiencia del desarrollador de API Una de esas métricas de datos es la idea de conversiones o la velocidad a la que un consumidor realiza una acción deseada. Esta suele ser una acción como hacer clic en un anuncio en un sitio web, pero en el espacio de la API, puede ser de todo, desde registrarse para una cuenta premium hasta enviar información social.

El concepto clave en la conversión es que si el usuario ve valor en un producto, es más probable que continúe. Volvamos a nuestro ejemplo de codificación de medios para ver cómo funciona.

Digamos que tenemos una API que transmite contenido de video a un usuario. La API se llama a través de un subprograma incrustado en un espacio de JavaScript en una página web y sirve datos de un servidor aleatorio según la disponibilidad. El usuario tiene la capacidad de seleccionar el servidor de su elección si se registra para una cuenta premium, o puede optar temporalmente por registrar una cuenta con credenciales compartiendo información de la cuenta social para elevar los límites de tasas y permitir la elección del servidor localizado.

En nuestro caso, los abrumadores datos de conversión sugieren que los usuarios están dispuestos a registrarse en la cuenta gratuita, pero no están dispuestos a convertirse en una cuenta premium. Esto nos dice algunas cosas sobre nuestra API, cuando se combina con datos adicionales:

  • Nuestros datos de disponibilidad sugieren que las cuentas premium no tienen alta disponibilidad debido a una cantidad relativamente menor de energía del servidor dedicada a la autenticación de cuentas premium;
  • Nuestros datos de tiempo de actividad sugieren que todas las cuentas están satisfechas con sus tasas de tiempo de actividad, ya que la tasa supera el 99,99%;
  • Nuestra latencia muestra que, si bien algunos datos se ralentizan debido a métodos de entrega no premium, en general nuestra latencia es aceptable.

Al observar estos datos, podemos extrapolar lo que sugieren nuestros datos de conversión. Si bien nuestra latencia es aceptable independientemente del tipo de cuenta, parece que no hemos asignado suficiente espacio para la autenticación de la cuenta premium, lo que hace que muchos usuarios no vean el valor real del sistema premium.

Esto se puede corregir fácilmente separando el servidor de autenticación para cuentas premium de la pila de servidores típica. Este aumento en la experiencia del usuario podría resultar no solo en una mayor adopción de cuentas premium (y por lo tanto un aumento en los ingresos), sino, en teoría, una mejor experiencia del usuario en general.

Generación de métricas de KPI

Ahora que hemos identificado algunos KPI que los proveedores deberían comenzar a buscar, ¿cómo se obtienen exactamente estos datos ? Si bien, en teoría, parte de ella podría generarse mediante soluciones internas, hay una gran cantidad de soluciones de terceros que pueden incorporarse fácilmente en API ya existentes con un esfuerzo mínimo.

Si bien no todas las soluciones serán apropiadas para su caso de uso dado, al menos una de estas debería, en teoría, ser aplicable con el lenguaje o la arquitectura actualmente empleados.

Galileo

Galileo alcanza todos nuestros principales KPI . Si bien la solución definitivamente está dirigida a la empresa , cada uno de los KPI que utiliza el servicio también es de gran valor para las API más pequeñas.

Una de las grandes ofertas de Galileo es el hecho de que ofrece registro en tiempo real de solicitudes y respuestas, y tiene un sistema que permite la reproducción de dichas solicitudes. Si bien esto es obviamente valioso en una situación de depuración , también arroja luz sobre la experiencia del usuario.

Como parte de estos conjuntos de datos, el uso de los consumidores es una métrica clave que Galileo también rastrea. La capacidad de rastrear la popularidad de los servicios y los puntos finales más utilizados es valiosa y puede desempeñar un papel importante en la identificación de problemas en la arquitectura general mucho antes de que se conviertan en un problema.

Cabe señalar que Galileo ofrece una solución empresarial en forma de Mashape Enterprise , un servicio que utiliza las mismas estructuras fundamentales que Galileo, pero está diseñado desde cero para trabajar con arquitecturas más grandes y complejas con opciones de integración asequibles. Dicho esto, Galileo todavía se puede utilizar con pequeñas API, y sus aplicaciones en tiempo real lo hacen bastante atractivo.

Análisis de API de Mashery

Mashery es otra implementación común y poderosa. Como servicio, cubre muchos de los mismos KPI que hacen otras soluciones con la adición de un conjunto de visualización de métricas conocido como TIBCO Spotfire .

La inclusión de Spotfire es una buena idea para la visualización y se relaciona con el enfoque general que Mashery parece adoptar con la inclusión del conjunto de características de "Resumen ejecutivo", una solución de métricas diseñada específicamente para fines comerciales, para presentar métricas a los accionistas , empleados y otros empleados de nivel ejecutivo.

Esto no significa necesariamente que Mashery esté restringido solo a espacios empresariales; como con cualquier opción en esta lista, la adaptación de Mashery a su entorno se hace fácilmente con la amplia gama de documentación y apoyo de la comunidad que disfrutan los adoptantes de la solución. Dicho esto, Mashery está diseñado expresamente para uso empresarial y centrado en el negocio.

3escala

Yendo en una dirección ligeramente diferente, 3scale ofrece métricas como una herramienta integrada en una infraestructura más grande. Como tal, 3scale ofrece sus métricas para API que se basan en la propia infraestructura. Dicho esto, las ofertas de 3scale hacen que las consideraciones sean atractivas. 3scale está diseñado para ser altamente escalable , y su integración de soluciones API como la limitación de tarifas y la facturación en el propio sistema hace que la propuesta sea valiosa.

La única advertencia con 3scale es que continúa con la tendencia a que los proveedores de métricas de API se centren en la empresa. Existe una barrera de precios que podría ser difícil de alcanzar para los equipos más pequeños, y la idea de integrar una API en una infraestructura más grande podría no ser factible para algunas API, especialmente aquellas que, por contrato (generalmente como parte de un acuerdo B2B) simplemente no se puede enrutar a plataformas externas y pilas de infraestructura.

Dicho esto, sigue siendo una solución muy viable, y con tanto poder y recursos en manos de la implementación, es una solución difícil de argumentar.

Paraguas API

API Umbrella es diferente porque es una implementación gratuita y de código abierto . También es diferente en cómo maneja realmente la generación de análisis en sí. Muchos proveedores, incluidos los discutidos hasta ahora, requieren que los datos se envíen desde una API a su punto final; básicamente, está enviando datos desde una red de API a otra métrica de API y derivando estadísticas de esta interacción.

Si bien este no es un enfoque fundamentalmente malo, puede conducir a una mayor latencia. Esto, por supuesto, compensa algunos de los análisis que se generan y, como tal, puede resultar en análisis de los datos afectados por el sistema en lugar de los datos sin procesar en sí.

No es así como funciona API Umbrella, específicamente por cómo está diseñado el sistema. No es un sistema externo; más bien, es una capa entre su API y las conexiones externas. API Umbrella llama a esto un "proxy que se encuentra frente a sus API". Como parte de esto, existe un gran beneficio en la forma de un flujo de datos menos afectado y, por lo tanto, una mayor generación de análisis sin interrupciones.

Dicho esto, es una solución relativamente menos utilizada y, como tal, no tiene tantos datos, experiencia o recursos que la respalden como las otras soluciones de esta lista.

Conclusión

Cuando los dueños de negocios discuten sobre análisis , a menudo lo consideran una característica , o algo que sería bueno implementar pero que no es del todo necesario. Esto no puede estar más lejos de la verdad: optar por renunciar a las métricas es optar por no recibir información sobre la función, la interacción, el uso y la naturaleza de su API.

Esto tiene implicaciones obvias en términos técnicos, pero tiene implicaciones aún más claras en cuanto al éxito de su negocio y las posibilidades de adopción. En consecuencia, las métricas deben considerarse tan importantes como realmente lo son: un aspecto clave de un sistema de API saludable y un requisito absoluto para cualquier proveedor.

Esperamos que esto haya ayudado a explicarlo y enmarcar la conversación dentro de algunos KPI clave que son infinitamente importantes para la salud y el éxito de una API. Háganos saber en los comentarios a continuación cuáles son sus KPI preferidos y qué soluciones le gustaría ver discutidas en esta conversación.

Publicar un comentario

0 Comentarios