Post Top Ad

Your Ad Spot

sábado, 1 de agosto de 2020

Cómo solucionar problemas de API sin servidor

La creación de API es un orden de magnitud, el caso de uso más común que vemos para las arquitecturas sin servidor. ¿Y por qué no? Es muy fácil combinar API Gateway y AWS Lambda para crear puntos finales API que tengan toda la infraestructura de recuperación ante desastres y gestión de carga que necesita de forma predeterminada. Combine eso con Serverless Framework y crearlos es tan fácil como:
1functions:
2  myfunction:
3    handler: myhandlerfile.myhandlerfunction
4      events:
5        - http:
6          path: myendpoint
7          method: get
Pero, ¿cómo hacemos para depurar y solucionar problemas de nuestras API? CloudWatch dentro de AWS nos brinda (más o menos) acceso fácil a nuestros registros de Lambda, y podemos activar el registro de API Gateway. Pero esto no nos proporciona toda la información que necesitamos si nuestra API comienza a tener problemas.
Esta es prácticamente la razón por la que creamos Serverless Framework Pro, como una forma de ayudar a los usuarios de Serverless Framework a monitorear y depurar sus servicios Serverless; Las API son las principales entre ellas.
Y si esta es la primera vez que escuchas sobre esto, permíteme presentarte el panel de control de Serverless Framework Pro con un video de YouTube de 2 minutos para ponerte al día.
Si desea saber cómo conectar uno de sus servicios al tablero, asegúrese de tener instalada la versión más reciente de Serverless ( npm i -g serverlesso si usa la versión binaria serverless upgrade) y luego ejecute el comando serverlessen la misma carpeta que su servicio. Se lo guiará a través de la configuración de todo.

Inicie sesión en CloudWatch

Cuando intentas depurar debes tener datos para ayudarte a determinar qué puede haber causado algún problema. La forma más fácil de hacerlo es asegurarse de usar el método de registro de su tiempo de ejecución cuando lo necesite. Por ejemplo, en un NodeJS Lambda, podemos capturar cualquier error que surja cuando hacemos llamadas a otros recursos de AWS como DynamoDB, por ejemplo. Escribir código que desconecte los datos de error apropiados en este caso puede verse más o menos así:
1const query = {
2  TableName: process.env.DYNAMODB_USER_TABLE,
3  KeyConditionExpression: '#id' = ':id',
4  ExpressionAttributeNames: {
5    '#id': id
6  },
7  ExpressionAttributeValues: {
8    ':id':'someid'
9  }
10}
11let result = {}
12try {
13  const dynamodb = new AWS.DynamoDB.DocumentClient()
14  result = await dynamodb.query(userQuery).promise()
15} catch (queryError) {
16  console.log('There was an error attempting to retrieve the data')
17  console.log('queryError', queryError)
18  console.log('query', query)
19  return new Error('There was an error retrieving the data: ' + queryError.message)
20}
Con esta disposición, significa que si por alguna razón nuestra consulta a DynamoDB se equivocó, mirar los registros indicaría exactamente por qué. Y el mismo patrón se puede aplicar a casi todos los tipos de código que tienen la posibilidad de generar errores durante la ejecución.

Monitoreo agregado

Antes de que podamos solucionar cualquier error específico, a menudo puede ser difícil saber si hay algún error en primer lugar. Especialmente cuando se trata de un sistema de producción ocupado, puede ser difícil saber si sus usuarios están experimentando algún error y aquí es donde Serverless Framework Pro se destaca con la pantalla de descripción general del servicio.
Al echar un vistazo a los gráficos proporcionados aquí, puede ver de inmediato si alguna solicitud de API o invocaciones de Lambda han regresado como errores y de alguna manera han afectado a sus usuarios, incluso si ellos mismos no lo saben.
Imagen que muestra barras de error
Con la imagen de arriba, no necesito esperar a que un usuario se queje o informe un error, puedo ver instantáneamente que algunos errores comienzan a suceder alrededor de las 7 p.m. Pero no termina ahí. Sería aún mejor si no se me exige que esté viendo estos cuadros y solo me notifiquen si algo sucede.
Aquí es donde entran las notificaciones de Serverless Framework Pro. Al ingresar a la configuración de mi aplicación y elegir notificaciones en el menú, puedo configurar que se me envíen notificaciones a una dirección de correo electrónico o varias, a un canal de Slack, llamar a un webhook o incluso enviar la notificación a SNS para que pueda tener mi propia función Lambda, por ejemplo, procese esas notificaciones como quiera.
Opciones de notificaciones
Puede configurarlos por servicio y por etapa y tener tantas configuraciones de notificación como desee; quizás las etapas de desarrollo informan por correo electrónico ya que no son críticas, pero los errores en la producción siempre van a un canal de Slack para todo el equipo.

Recuperando detalles del error

Como ahora puedo ver y recibir alertas de errores, necesito alguna forma de ayudarme a descubrir cuál es el error y cómo solucionarlo. Esto se vuelve relativamente fácil con Serverless Framework Pro nuevamente.
Descripción general que muestra errores
Empiezas con una pantalla de resumen como esta y veo algunos errores. Déjame hacer clic en eso ...
Lista de errores
Ahora puedo ver información resumida sobre los errores dentro de ese período de tiempo. Déjame seleccionar uno para profundizar más
Pila de seguimiento y registros
Desplazándome un poco hacia abajo en la siguiente vista, puedo ver que Serverless Framework Pro me está dando un seguimiento de la pila de la línea de código en mi controlador que arrojó el error, así que sé exactamente dónde buscar. Y debido a mis console.loglíneas detalladas , mi registro de CloudWatch me muestra los datos relacionados con el error. (Obviamente, he generado deliberadamente un error para fines de demostración aquí, pero lo mismo se aplica también a los errores reales).
NOTA : los registros de CloudWatch se extraen de su cuenta de AWS. No se almacenan en ningún lugar dentro de Serverless Framework Pro, por lo que cuando abro esta vista detallada, Serverless Framework Pro realiza una solicitud a su cuenta de AWS para recuperar los registros. Si elimina el registro de CloudWatch de su cuenta, tampoco será visible aquí.

Es mejor prevenir que curar

Hasta ahora hemos estado buscando cómo reaccionar ante los errores. Pero incluso podemos ir un paso más allá y estar atentos a los problemas que pueden causar un problema más adelante. Por ejemplo, si tenemos funciones de Lambda que generalmente se ejecutan durante un cierto período de tiempo, digamos entre 50 y 100 ms, y de repente hay un pico en el que nuestras Lambdas se ejecutan durante más de 200 ms, esto podría indicar un posible problema de elaboración; tal vez algún proveedor intermedio esté teniendo problemas y si pudiéramos recibir alguna advertencia con anticipación, tal vez podríamos evitar eso en el pase. Lo mismo podría aplicarse para el recuento de invocación. Tal vez generalmente tengamos un flujo de actividad muy constante en nuestras invocaciones Lambda y cualquier aumento repentino en las invocaciones es algo que necesitamos saber.
Serverless Framework Pro ya crea estas alertas automáticamente y usted puede optar por recibir notificaciones de estas alertas mediante el sistema de notificaciones que se muestra anteriormente.

Ajuste de rendimiento

La resolución de problemas no tiene que ser todo sobre errores. Es posible que necesitemos cumplir con ciertos criterios de rendimiento, y Serverless Framework Pro también nos brinda formas de evaluar esto.
Evaluar el tiempo de ejecución
Cada función Lambda puede tener un valor de tamaño de memoria establecido. Pero esta configuración no es solo para la memoria y también afecta la asignación de CPU y red de manera lineal; si duplica la memoria, duplicará la CPU y la red efectivas. Al hacer clic en la sección de funciones en el menú de la izquierda y luego seleccionar una función específica, puede ver estadísticas de duración con líneas verticales discontinuas para la implementación. Ahora puede ver de inmediato cómo un cambio que realiza afecta el tiempo promedio de ejecución de sus invocaciones después de una implementación.
Cambio de duración de la función
Y puede hacer exactamente lo mismo para el uso de memoria ...
SDK y solicitudes HTTP
A menudo, en un Lambda necesitamos realizar solicitudes a otros servicios de AWS a través del AWS SDK o incluso solicitudes HTTP a otros servicios de terceros, y estos pueden tener un impacto definitivo en el rendimiento de nuestros puntos finales. Ser capaz de medir este impacto sería realmente útil.
Una vez más, Serverless Framework Pro hace posible investigar esto. Dentro de la vista detallada de un Lambda, podemos ver la sección de tramos que nos indicará si nuestras solicitudes salientes son más lentas de lo que deberían ser. ¿Recuerda el problema con los servicios de terceros mencionados anteriormente? Bueno, con los tramos podemos ver cuánto tiempo pueden tomar las solicitudes y luego tomar las medidas adecuadas.
Se extiende por AWS SDK

Empujar datos en tiempo de ejecución

Sin embargo, no todos los datos que queremos ver son tan sencillos y fáciles de capturar como hemos visto hasta ahora. A veces necesitamos poder analizar métricas y datos que solo están disponibles en tiempo de ejecución. Es por eso que Serverless Framework Pro SDK incorpora una serie de características para ayudar a rastrear estos datos un poco más fácil. De forma predeterminada, Serverless Framework Pro sobrecarga el objeto de contexto en tiempo de ejecución y proporciona algunas funciones adicionales para usar para la captura de datos en tiempo de ejecución.
Todas estas opciones están documentadas en el sitio web sin servidor e incluyen opciones para los tiempos de ejecución de Node y Python.
Error de captura
Puede haber casos en los que nos gustaría saber acerca de un posible error sin realmente devolver un error al usuario final que realiza la solicitud. Entonces, en su lugar, podemos usar el método captureError:
1if (context.hasOwnProperty('serverlessSdk')) {
2  context.serverlessSdk.captureError('Could not put the user')
3}
4return {
5    statusCode: 200,
6    headers: {
7      'Access-Control-Allow-Origin': '*',
8      'Access-Control-Allow-Credentials': true,
9      'Access-Control-Allow-Headers': 'Authorization'
10    }
11  }
Como puede ver en lo anterior, simplemente enviamos un mensaje de error, pero finalmente devolvemos una respuesta 200. Y nuestro monitoreo lo mostrará como un error.
Errores capturados
Capturar Span
Y podemos hacer lo mismo para capturar cualquier código que tarde en ejecutarse. Podemos envolver ese código en nuestro propio intervalo personalizado y ver los datos de rendimiento disponibles para nosotros:
1if(context.hasOwnProperty(‘serverlessSdk’)) {
2  await context.serverlessSdk.span('HASH', async () => {
3    return new Promise((resolve, reject) => {
4      bcrypt.hash("ARANDMOMSTRING", 13, () => {
5        resolve()
6      })
7    })
8  })
9}
Lo anterior produce el siguiente lapso:
Alcance personalizado del hash
Puede decir de inmediato, solo mirando eso, que su enfoque para cualquier optimización debe estar en ese lapso HASH. Intentar optimizar cualquier otra cosa no tendría sentido.
Etiqueta de captura
Por último, existe una forma de capturar pares clave-valor de las invocaciones en tiempo de ejecución que se pueden filtrar en la vista del explorador. Tal vez un ejemplo hará que esto sea un poco más fácil de entender.
Ha creado un proceso de pago que captura los datos de la tarjeta de crédito de un usuario y luego los pasa a un proveedor de pagos externo. Muchos de nosotros habremos construido tal funcionalidad en el pasado. Y generalmente lo que sucede es que la respuesta, después de pasar esos detalles, indicará éxito o fracaso e incluso explicará por qué falló; falta de fondos, tarjeta vencida, rechazada por el banco, etc. Podemos etiquetar estos diversos estados para que podamos buscarlos más fácilmente. Básicamente, le permite pasar una clave, un valor y datos de contexto adicionales si lo necesita:
1if (paymentProvider.status === ‘success’) {
2  context.serverlessSdk.tagEvent('checkout-status', event.body.customerId, paymentProvider.response
3  });
4}
Esto le permite encontrar todas las invocaciones relacionadas con un ID de cliente específico, por lo que si alguna vez necesitamos encontrar registros muy específicos del proveedor de pagos que procesa los detalles de la tarjeta, podemos filtrar fácilmente por ese ID de cliente.

Serverless Framework Pro tiene un nivel gratuito generoso para que cualquiera que cree una aplicación Serverless pueda usar. No requiere nada más que registrarse aquí .
Si desea ver estas características en acción, no dude en [suscribirse a nuestro seminario web] [https://serverless.zoom.us/webinar/register/WN_7GpfDR5sT-qsUmovARuvrg] el 6 de febrero.

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas