example - seguridad api rest
¿Cuál es la mejor manera de monitorear su API REST? (4)
He creado una API basada en el patrón RESTful y me preguntaba cuál es la mejor manera de monitorearlo. ¿Puedo recopilar de alguna manera estadísticas sobre cada solicitud y con cuánta profundidad puedo monitorear las solicitudes?
Además, ¿podría hacerse utilizando un software de código abierto (tal vez construyendo mi propio servicio de monitoreo) o necesito comprar un software de terceros?
Si pudiera lograrse utilizando software de código abierto, ¿por dónde empiezo?
(Estoy claramente predispuesto a responder esto ya que cofundé Runscope, que creo que es el líder en Monitoreo API, por lo que puede tomar todo esto con un poco de sal o confiar en mis años de experiencia trabajando con miles de clientes específicamente en esto problema :)
No conozco ninguna herramienta OSS específica para el monitoreo de la API REST (ful). Las herramientas de monitoreo de OSS de propósito general (como Graphite) definitivamente pueden ayudar a controlar las partes de su pila de API, pero no tienen ninguna característica específica de API.
Las herramientas de monitoreo de métricas comerciales (como Datadog) o Application Performance Monitoring (APM) como (New Relic o AppDynamics) tienen algunas características más específicas para los casos de uso de API, pero ninguna está centrada en ello. Estos son una parte útil de lo que llamamos un "enfoque de monitoreo en capas": comience con el monitoreo de API de alto nivel y use estas otras herramientas (rastreadores de excepciones, APM, registros sin procesar) para sumergirse en los problemas cuando surjan.
Entonces, ¿qué características específicas de API debería buscar en una herramienta de monitoreo de API? Los clasificamos en función de los tres factores que generalmente controla: disponibilidad / disponibilidad, rendimiento / velocidad y corrección / validación de datos.
Monitoreo de tiempo de actividad
En un nivel básico, querrá saber si sus API están disponibles para los clientes que necesitan llegar a ellas. Para "público" (es decir, disponible en la Internet pública, no necesariamente publicitada ... una API de back-end móvil es pública pero no necesariamente publicitada) APIs, querrá simular a los clientes que las están llamando lo más posible. Si tiene una aplicación móvil, es probable que la API tenga que estar disponible en todo el mundo. Por lo tanto, como mínimo, su herramienta de monitoreo de API debería permitirle ejecutar pruebas desde múltiples ubicaciones. Si no puede acceder a su API desde una ubicación, querrá recibir notificaciones por correo electrónico, Slack, etc.
Si su API está en una red privada (firewall corporativo, entorno de almacenamiento intermedio, máquina local, etc.), también querrá poder "verla". Hay una variedad de enfoques para esto (agentes, VPN, etc.) solo asegúrese de usar uno en el que su departamento de TI firme.
La distribución global de los agentes de prueba es una configuración costosa si usted se hospeda por cuenta propia, está construyendo internamente o utilizando una herramienta OSS. Debe asegurarse de que cada ubicación remota que configure (preferiblemente fuera de su clúster principal) tenga una alta disponibilidad y un completo monitoreo también. Esto puede ser costoso y consumir mucho tiempo muy rápidamente.
Supervisión del rendimiento
Una vez que haya verificado que sus API son accesibles, entonces querrá comenzar a medir qué tan rápido se están desempeñando para asegurarse de que no estén ralentizando las aplicaciones que las consumen. Los tiempos de respuesta sin procesar son la métrica mínima que debe seguir, pero no siempre es la más útil. Considere los casos en los que se agregan múltiples llamadas a la API en una vista para el usuario, o las acciones del usuario generan datos dinámicos o raramente llamados que pueden no estar presentes todavía en una capa de almacenamiento en caché. Estas tareas o flujos de trabajo de varios pasos pueden ser difíciles de monitorear con APM o herramientas basadas en métricas, ya que no tienen las capacidades para comprender el contenido de las llamadas a la API, solo su existencia.
La supervisión externa de la velocidad también es importante para obtener la representación más precisa del rendimiento. Si el agente de supervisión se encuentra dentro de su código o en el mismo servidor, es poco probable que tenga en cuenta todos los factores que experimenta un cliente real cuando realiza una llamada. Cosas como resolución de DNS, negociación SSL, balanceo de carga, almacenamiento en caché, etc.
Corrección y validación de datos
¿De qué sirve una API que está activa y es rápida si está devolviendo los datos incorrectos? Este escenario es muy común y, en última instancia, es una experiencia de usuario mucho peor. La gente entiende "abajo" ... no entienden por qué una aplicación les muestra datos incorrectos. Una buena herramienta de monitoreo de API le permitirá hacer una inspección profunda de las cargas útiles de mensajes que van y vienen. El análisis JSON y XML, las aserciones complejas, la validación de esquemas, las extracciones de datos, las variables dinámicas, los monitores de pasos múltiples y más son necesarios para validar completamente los datos que se envían de un lado a otro.
También es importante validar cómo los clientes se autentican con su API. Las buenas herramientas de monitoreo específicas de API comprenderán OAuth, la autenticación mutua con certificados de cliente, la autenticación de token, etc.
Esperemos que esto le dé una idea de por qué la monitorización de la API es diferente de las métricas "tradicionales", APM y las herramientas de registro, y cómo pueden jugar juntas para obtener una imagen completa de su aplicación.
Comience con la identificación de las necesidades básicas que cree que resolverá con el monitoreo. Trate de responder las dos preguntas "¿Qué quiero saber?" y "¿Cómo quiero actuar sobre esa información?".
Ejemplos de "¿Qué quiero saber?"
- Rendimiento en el tiempo
- Usuarios de API más grandes
- Las características de API más utilizadas
- Error en la API.
Ejemplos de "¿Cómo quiero actuar sobre esa información?"
- Revisar un cuadro de mandos de medidas conocidas.
- Esté alerta cuando algo cambie más allá de los límites esperados
- Rastreo de ejecución que llevó a ese estado.
- Revisar las mediciones durante toda la vida útil del sistema.
Si puede responder a esas preguntas, puede encontrar la solución de terceros adecuada que capture las métricas que le interesan, o inyectar sondas de monitoreo en la sección correcta de su API que le dirá lo que debe saber. Noté que usted es principalmente un usuario de Laravel , por lo que es probable que muchas de las métricas que desea conocer se puedan capturar agregando los filtros antes ( Registro de filtros antes de en un controlador ) y después ( Registro de un filtro de aplicación posterior ) con su aplicación , para medir el tiempo de respuesta y la finalización exitosa de la respuesta. Aquí es donde las respuestas al primer conjunto de preguntas son las más importantes ("¿Qué quiero saber?"), Ya que guiará dónde y qué mide en su aplicación.
Una vez que sepa dónde puede capturar los datos, la selección de la herramienta correcta se convierte en una cuestión de elegir entre (aproximadamente) dos clases de aplicaciones de monitoreo: aplicaciones de monitoreo altamente especializadas que están estrechamente vinculadas al funcionamiento de su aplicación, y software de monitoreo generalizado que es más parecido a una base de datos de series de tiempo.
No hay ejemplos populares (que yo sepa) de casos altamente especializados que sean de código abierto. Sin embargo, existen muchas soluciones comerciales: NewRelic, Ruxit, DynaTrace, etc. etc. Su función podría describirse fácilmente como similar a un perfilador remoto, con muchas otras funciones además. (Además, no olvide que un perfilador más tradicional puede ser útil para recopilar parte de la información que necesita, aunque definitivamente no suplantará el monitoreo de su aplicación, hay una gran cantidad de información valiosa que puede obtenerse de los perfiles incluso antes de comenzar. a la producción.)
En el lado general de las cosas, hay muchas más opciones de código abierto que personalmente conozco. La vida más larga es Graphite (una excelente introducción a la que se puede leer aquí: Medir cualquier cosa, Medir todo ), que es de uso bastante común entre muchos. Sin embargo, Graphite está lejos de ser la única opción, y puedes encontrar muchas otras opciones como Kibana e InfluxDB si deseas alojarte.
Muchas de estas opciones de código abierto también tienen opciones de alojamiento disponibles de varios proveedores. Además, encontrará que hay muchas opciones completamente comerciales disponibles en este campamento (de hecho, soy el fundador de una): Instrumental .
La mayoría de estas opciones comerciales existen porque a los propietarios de las aplicaciones les resulta bastante oneroso ejecutar su propia infraestructura de monitoreo además de ejecutar su aplicación real; mantener la disponibilidad de otro sistema distribuido no es una prioridad en muchas listas de deseos del personal de operaciones. :)
Estoy usando runscope.com para mi empresa. Si quieres algo gratis apicombo.com también puedes hacerlo. Básicamente, puede crear una prueba para su punto final de API para validar la carga útil, el tiempo de respuesta, el código de estado, etc. Luego, puede programar la prueba para que se ejecute. También proporcionan algunas estadísticas básicas.
He intentado varias aplicaciones y métodos para hacer eso, y lo mejor (para mi empresa y nuestros proyectos relacionados) es registrar pares clave = valor (entradas atómicas con toda la información asociada con esta operación como origen de IP, resultado de la operación, transcurrido tiempo, etc ... en archivos de registro específicos para cada nodo / servidor) y luego monitorizar con Splunk . Con sus datos REST y json, tal vez su enfoque sea diferente, pero también está bien soportado.
Es bastante fácil de instalar y configurar. Puede monitorear (casi) datos en tiempo real (tiempos de respuesta, resultados de operación), enviar notificaciones sobre eventos y hacer algo de DWH (y muchas otras cosas, hay muchos complementos).
No es de código abierto, pero puede probarlo gratis si usa menos de 50 MB de registros por día (así es como funcionó hace un tiempo, ya que ahora tengo una licencia de empresa, no estoy seguro al 100%).
Aquí hay un pequeño tutorial que explica cómo lograr lo que está buscando: http://blogs.splunk.com/2013/06/18/getting-data-from-your-rest-apis-into-splunk/