Presentamos Log Tailing de Compute para mejorar la observabilidad y facilitar la depuración

Es innegable que la idea de una informática sin servidores resulta atractiva: ¿quién no querría disponer de arquitecturas descentralizadas y realizar despliegues globales sin tener que planear con antelación la disponibilidad de recursos? Por eso no debe sorprendernos que, según las previsiones de Gartner, en 2025 la mitad de las empresas de todo el mundo habrán desplegado entornos informáticos sin servidores, cuando la cifra actual es del 20 %. 

Hemos estado mejorando nuestro propio (y ya bastante potente) entorno informático sin servidores —Compute, que actualmente ya ejecuta tráfico de producción real— para que resulte más fácil resolver casos de uso en el edge utilizando lenguajes de programación conocidos, y crear aplicaciones avanzadas y lógica personalizada lo más cerca posible de los usuarios finales. Y hoy ponemos en marcha otra mejora que nos acerca un paso más a la tierra prometida de la informática sin servidores. 

Log Tailing de Compute permite a los clientes leer registros en tiempo casi real sin tener que utilizar servicios de terceros y facilita la depuración rápida de las aplicaciones en el edge durante el proceso de desarrollo. Veamos por qué y cómo. 

Observabilidad en el edge

La observabilidad mejorada de Compute muestra registros y estadísticas en tiempo real y permite exponer los datos de rastreo mediante herramientas habituales en el sector y la exportación a sistemas de terceros. A menudo, sin embargo, la informática sin servidores es solo una parte de la estrategia global de desarrollo de aplicaciones de la organización, combinada con otras tecnologías (2019 Community Survey). Componer una visión de extremo a extremo del rendimiento en un sistema heterogéneo y cada vez más distribuido no es tarea fácil. 

Hasta la fecha, para poder ver registros de aplicaciones y datos de depuración de un servicio Wasm activo de Compute, el usuario debía configurar una herramienta de gestión de registros de terceros y añadir un punto de conexión de registro a su servicio. Esto significa que una depuración sencilla y rápida sigue siendo más difícil de lo que nos gustaría. Log Tailing está aquí para cambiarlo. 

A diferencia de otras funciones de depuración incluidas en las soluciones de informática sin servidores, Log Tailing permite a los desarrolladores transmitir directamente sus propios mensajes de registro personalizados en el terminal que elijan, utilizando la interfaz de línea de comandos de Fastly y, al mismo tiempo, probar sus aplicaciones ejecutadas en la plataforma Compute de Fastly. Con ello, los desarrolladores obtienen visibilidad en tiempo real de la salida de stdout y stderr de su aplicación en el edge para resolver de forma eficaz los problemas sin necesidad de configurar (y pagar) servicios adicionales de gestión de registros de terceros (aunque los clientes sí tendrán que configurar el servicio de gestión de registros de terceros si quieren archivarlos para almacenarlos y analizarlos a largo plazo). 

El acceso a registros casi en tiempo real desde la CLI de Compute permite una rápida depuración en el bucle de desarrollo-inserción-validación. Esto significa que las aplicaciones pueden enviarse antes a producción, con capacidad para desarrollo y depuración en un mismo lugar. Sin duda, supone un gran impulso para los datos de observabilidad en entornos sin servidores en lapsos de tiempo cortos y recientes, compatibles con los ciclos de desarrollo rápidos.

¿Cómo se utiliza? 

Para ilustrar el uso correcto de Log Tailing, podemos empezar con el kit de inicio predeterminado para Rust de Compute, que incluye ejemplos de enrutamientos, respuestas sintéticas sencillas e invalidaciones de reglas de almacenamiento en caché. Tenemos previsto modificar el kit de inicio para que incluya varias instrucciones de impresión, algunas con salida en stdout y otras en stderr. Ten en cuenta que en este tutorial trabajaremos con la versión 1.0.0 de la CLI de Fastly.

// Pattern match on the request method and path.
match (req.method(), req.uri().path()) {
// If request is a `GET` to the `/` path, send a default response.
(&Method::GET, "/") => {
println!("Hello from the root path!");
Ok(Response::builder()
.status(StatusCode::OK)
.body(Body::from("Welcome to Fastly Compute@Edge!"))?)
}
// If request is a `GET` to the `/backend` path, send to a named backend.
(&Method::GET, "/backend") => {
println!("Hello from the /backend path!");
// Request handling logic could go here...
// E.g., send the request to an origin backend and then cache the
// response for one minute.
*req.cache_override_mut() = CacheOverride::ttl(60);
Ok(req.send(BACKEND_NAME)?)
}
// If request is a `GET` to a path starting with `/other/`.
(&Method::GET, path) if path.starts_with("/other/") => {
println!("Hello from the {} path", path);
// Send request to a different backend and don't cache response.
*req.cache_override_mut() = CacheOverride::Pass;
Ok(req.send(OTHER_BACKEND_NAME)?)
}
// Catch all other requests and return a 404.
_ => {
let client_ip = downstream_client_ip_addr().ok_or(anyhow!("could not get client ip"))?;
let geo = geo_lookup(client_ip).ok_or(anyhow!("no geographic data available"))?;
eprintln!("Bad request to path {} from someone in {}, {}", req.uri().path(), geo.city(), geo.country_code3());
Ok(Response::builder()
.status(StatusCode::NOT_FOUND)
.body(Body::from("The page you requested could not be found"))?)
}
}

Este es un ejemplo muy sencillo que te permitirá depurar una aplicación Wasm para ver qué rutas se están ejecutando. Después de desplegar esta aplicación, podemos utilizar curl para probar nuestra lógica de rutas observando la salida de Log Tailing, sin necesidad de establecer nuestro propio punto de conexión de registro.

En el ejemplo siguiente, el despliegue de la aplicación es

https://logtail-demo.edgecompute.app/

Si quieres empezar a usar el servicio Log Tailing y ya tienes acceso a Compute, solo necesitas contactar con el equipo de tu cuenta para que te lo establezca.

$ fastly log-tail --service-id=<redacted>
SUCCESS: Managed logging enabled on service <redacted>

En otro terminal, ejecutamos curl en nuestra aplicación:

$ curl https://logtail-demo.edgecompute.app/
$ curl https://logtail-demo.edgecompute.app/backend
$ curl https://logtail-demo.edgecompute.app/other/path
$ curl https://logtail-demo.edgecompute.app/notfound

Con ello, el resultado de Log Tailing imprimirá la secuencia (stdout para println y stderr para eprintln), un ID de petición único y el mensaje.

$ fastly log-tail --service-id=<redacted>
SUCCESS: Managed logging enabled on service <redacted>
| stdout | 4718faa4 | Hello from the root path! |
| stdout | 28dae28d | Hello from the /backend path! |
| stdout | 8b90d6a6 | Hello from the /other/path path |
| stderr | 9515856c | Bad request to path /notfound from someone in ft collins, USA |

Si cada petición contiene varias llamadas a println o eprintln, estas se ordenarán y agruparán en la salida. Podemos modificar nuestro controlador "/" para mostrarlo:

(&Method::GET, "/") => {
println!("Hello from the root path!");
println!("2nd println in this request");
println!("3rd println in this request");
println!("4th println in this request");
println!("5th println in this request");
Ok(Response::builder()
.status(StatusCode::OK)
.body(Body::from("Welcome to Fastly Compute@Edge!"))?)
}

Si tuviéramos que ejecutar dos comandos curl en https://logtail-demo.edgecompute.app/ simultáneamente, veríamos la salida agrupada por el ID único:

| stdout | 57bc24b2 | Hello from the root path! |
| stdout | 57bc24b2 | 2nd println in this request |
| stdout | 57bc24b2 | 3rd println in this request |
| stdout | 57bc24b2 | 4th println in this request |
| stdout | 57bc24b2 | 5th println in this request |
| stdout | 6e40d49a | Hello from the root path! |
| stdout | 6e40d49a | 2nd println in this request |
| stdout | 6e40d49a | 3rd println in this request |
| stdout | 6e40d49a | 4th println in this request |
| stdout | 6e40d49a | 5th println in this request |

El siguiente paso

Siempre os estamos hablando del edge y ahora con Compute os seguimos proponiendo formas nuevas de crear en el borde con las herramientas que necesitáis y queréis usar. Esta es solo una de las muchas mejoras que estamos ideando. Regístrate aquí para recibir noticias y novedades acerca de Compute. 

Edward Muller
Senior Manager, Data Team
Fecha de publicación:

4 min de lectura

Comparte esta entrada
Edward Muller
Senior Manager, Data Team

Como Senior Manager del equipo de datos de Fastly, Edward ayuda a garantizar que los registros de nuestros clientes alcancen los destinos deseados. Antes, fue Principal Engineer/Director en Heroku, propiedad de Salesforce, donde ayudó a crear los sistemas de registro y métricas de Heroku, trabajó en el ámbito de la compatibilidad con el lenguaje Go, ayudó a impulsar la adopción de objetivos de nivel de servicio y elaboró herramientas de automatización para bases de datos en la nube. Antes de Salesforce, contribuyó a la creación de una de las primeras empresas emergentes de PaaS, EngineYard. En su tiempo libre, se le puede ver paseando a su perro, jugando con sus hijos, haciendo de carpintero, imprimiendo en 3D y en diversos menesteres culinarios como barbacoas u horneados.

¿List@ para empezar?

Ponte en contacto o crea una cuenta.