Primeros pasos con Compute y el registro en tiempo real de Fastly

Senior Software Engineer, Fastly

02 de noviembre de 2021

¿Quieres saber cómo funciona la edge computing? Anímate a probar nuestra plataforma sin servidores sin ningún tipo de compromiso, con la prueba gratuita que hemos puesto en marcha hace poco.

Desarrollar aplicaciones con WebAssembly (o Wasm) en Compute para las cachés en el edge de Fastly requiere un cambio de paradigma: ya no se trata de configurar el comportamiento de la CDN con Varnish Configuration Language (VCL), sino de programar con un estilo parecido al del software tradicional, ya sea en Rust, JavaScript o AssemblyScript.

Tanto si ya conoces VCL como si Compute es totalmente nuevo para ti, te interesará saber cómo emitir la salida de texto de diagnóstico desde tus aplicaciones Wasm para solucionar problemas puntuales o para capturar indicadores clave de forma continua.

Hay dos formas de emitir la salida desde las aplicaciones Wasm de Compute, que se corresponden con las dos categorías distintas de destinos en los que se capturan o retienen los mensajes emitidos.

STDIO tradicional
El entorno host captura la salida a los descriptores de archivo stdout y stderr, y la dirige a un destino del que se puede hacer un seguimiento, de forma similar a la salida que se redirige a un terminal o archivo. En Compute, esta funcionalidad se denomina Log Tailing, y es compatible con la CLI de Fastly. Además, Log Tailing permite capturar y mostrar los errores de tiempo de ejecución de la aplicación Wasm no gestionados.
Marco de registro
El marco de registro de Compute permite añadir una estructura formal, codificar la intención y configurar un sistema de destino para la salida emitida. Los destinos de los mensajes de registro pueden ser cualquiera de las integraciones disponibles en nuestra plataforma de envío de registros: Apache Kafka, S3, Splunk y muchas más. Los registros pueden clasificarse en categorías según su importancia (información, advertencia o error) y, al llegar a su destino, pueden procesarse de forma automática conforme a estos y otros criterios arbitrarios.

Esta entrada del blog te mostrará los pasos básicos para generar mensajes en STDIO y para realizar un seguimiento de esa salida con la CLI de Fastly. Además, aprenderás cómo configurar un punto de conexión de envío de registros, emitir registros en tu aplicación y confirmar que se han entregado en el destino de registro que tú elijas. Para el envío de registros, usaremos como agregador de registros de destino Azure Event Hubs, un bus de servicio compatible con el protocolo Apache Kafka. Si prefieres usar otro destino, deberás ajustar en consecuencia la configuración de los puntos de conexión de registro, tal y como se explica en nuestra documentación sobre el envío de registros.

Inicializar un proyecto

Para no complicar demasiado este tutorial, nos ceñiremos a las herramientas de la CLI. Imagino que ya has creado una cuenta de cliente de Fastly, has instalado la CLI de Fastly y has instalado Rust. Si no es así, este el momento perfecto para hacer todo eso. Ten en cuenta que en este tutorial trabajaremos con la versión 1.0.0 de la CLI de Fastly. Si usas otra versión, algunas marcas de comandos pueden ser distintas. Y una cosa más: aunque aquí usemos Rust, puedes lograr los mismos resultados con JavaScript y AssemblyScript.

Primero crearemos un token de la CLI compatible. Vamos a suponer que eres el administrador de la cuenta y que puedes ejecutar el siguiente comando para generar el token de la API de todos los comandos de configuración de la CLI que van a aparecer en este tutorial. No olvides especificar una fecha y hora de caducidad adecuadas en el token.

fastly auth-token create --password=<your-Fastly-acct-password> \
--name='My WASM API Token' --scope=global \
--expires 2021-12-31T23:59:59Z

Deberías ver algo que empiece más o menos así:

SUCCESS: Created token ‘<token-string>’ ...

La cadena entrecomillada es el valor del token de la API de Fastly. A continuación, ejecuta el siguiente comando y especifica el token que has creado, cuando se te pida:

fastly configure

Con esto ya puedes crear, configurar y administrar tus servicios de Fastly y aplicaciones Wasm de Compute.

Crea un servicio Wasm con el siguiente comando:

fastly service create --name=MyService --type=wasm

Ten en cuenta que el comando de arriba crea específicamente un servicio Wasm de Fastly, y no el tradicional servicio VCL. Si tienes curiosidad, verás que este nuevo servicio aparece en la aplicación web de Fastly.

Como mínimo, el servicio necesitará un nombre de dominio exclusivo para que se active su configuración de servicio, así que necesitaremos saber el identificador de servicio de tu nuevo servicio. Ejecuta este comando para obtener el identificador del servicio:

fastly service list

La respuesta contendrá el identificador del servicio en la columna del identificador. Fíjate, además, en que el tipo de servicio en la salida generada sea wasm.

Ejecuta el siguiente comando, dándole un nombre concreto al subdominio, para asignar un dominio a tu servicio Wasm:

fastly domain create --name=<your-name>.edgecompute.app \
--version=latest --service-id=<your-Fastly-service-ID>

En nuestra plataforma, los servicios Wasm de Compute deben tener nombres de dominio con sufijos de nivel superior de edgecompute.app, puesto que este es el dominio de nivel superior asociado a nuestra infraestructura de CDN. Sin embargo, en tus despliegues de Compute en entornos de producción, puedes asignar el alias que más te convenga mediante registros CNAME en los ajustes de tu proveedor de servicios de nombres de dominio.

Por poner un ejemplo más interesante, asignaremos un par de hosts de origen del backend a nuestro servicio Wasm: www.w3.org y www.iana.org. Sustituirán al servidor de origen real, que será el que ofrezca tu contenido web. Ejecuta estos dos comandos para añadir los dos backends:

fastly backend create --name=backend_name --address=www.w3.org \
--override-host=www.w3.org --use-ssl --ssl-sni-hostname=www.w3.org \
--ssl-cert-hostname='*.w3.org' --version=latest \
--service-id=<your-Fastly-service-ID>


fastly backend create --name=other_backend_name \
--address=www.iana.org --override-host=www.iana.org --use-ssl \
--ssl-sni-hostname=www.iana.org \
--ssl-cert-hostname='*.iana.org' --version=latest \
--service-id=<your-Fastly-service-ID>

Ahora que ya tienes configurados los servicios de origen del backend, solo te queda crear y actualizar el código Wasm para completar la configuración inicial de la aplicación Wasm. Por suerte, la CLI te lo pone muy fácil, ya que puedes hacerlo a través de sus kits de inicio de Wasm.

Ejecuta el siguiente comando, confirmando tu nombre de usuario, y selecciona el kit de inicio de Rust que vas a usar:

fastly compute init --language=Rust --directory=./MyEdgeComputeApp \
--name=MyEdgeComputeApp \
--description='My first Compute@Edge app'

Cambia los directorios por MyEdgeComputeApp y revisa el contenido, prestando especial atención a los archivos de ./src. Modifica ./fastly.toml en el directorio raíz del proyecto de modo que las configuraciones de backend de los servicios sean las que aparecen en esta lista:

[setup]

 [setup.backends]

    [setup.backends.backend_name]
      address = "www.w3.org"
      description = "A backend able to serve `/articles` path"
      port = 443

    [setup.backends.other_backend_name]
      address = "www.iana.org"
      description = "A backend able to serve `/anything` path"
      port = 443

Puedes prescindir de la configuración anterior y dejar que la CLI gestione en exclusiva tus backends, pero el proceso de publicación de Wasm de la CLI también podría usar el archivo ./fastly.toml para configurar automáticamente los backends de tu aplicación Wasm.

Ejecuta estos comandos para compilar y desplegar tu aplicación Wasm:

fastly compute build
fastly compute deploy --service-id=<your-Fastly-service-ID>

Llegados a este punto, se activará tu servicio Wasm de Compute y podrá atender peticiones.

Puedes recuperar cualquiera de las siguientes URL de tu servicio y observar sus respuestas:

```
https://<your-name>.edgecompute.app/
```

https://<your-name>.edgecompute.app/articles

https://<your-name>.edgecompute.app/anything

Las rutas /articles y /anything deberían dar como resultado respuestas HTTP 404 en las páginas de destino de www.w3.org y www.iana.org. Voy a dejar que seas tú quien averigüe cómo hacer que el código Rust en ./src/main.rs resuelva estas rutas como páginas válidas, así como las rutas de los artefactos de página en ambos sitios.

¡Bravo! Ya has desplegado tu aplicación Wasm de Compute y lo tienes todo listo para dar los siguientes pasos: emitir la salida del programa y registrarla en recopiladores de registros externos desde tu aplicación. Veamos ahora cómo completar cada uno de estos pasos.

Depurar la impresión con la CLI

En esta parte, veremos cómo emitir y supervisar sencillas instrucciones de impresión desde la aplicación Wasm de Compute.

Vuelve a tu MyEdgeComputeApp del paso anterior y añade la siguiente línea a ./src/main.rs, debajo de fn main(mut req: Request) -> Result<Response, Error> {:

fn main(mut req: Request) -> Result<Response, Error> {
    // Log request path to stdout.
    println!("Request received for path {}", req.get_path());
    // Filter request methods...
    match req.get_method() {
    ...

Compila y vuelve a desplegar tu aplicación Wasm:

fastly compute build
fastly compute deploy --service-id=<your-Fastly-service-ID>

Ten en cuenta que, al ejecutar este paso de despliegue, la versión de configuración de tu servicio Wasm avanzará automáticamente a la siguiente y se activará con el paquete de la aplicación Wasm recién publicado.

En tu terminal, escribe el siguiente comando para iniciar el seguimiento de la salida desde tu aplicación Wasm:

fastly log-tail --service-id=<your-Fastly-service-ID>

Es posible que enseguida aparezcan algunos mensajes de registro que digan que ya se había activado el seguimiento de la salida en tu servicio Wasm, pero esto simplemente sucede como consecuencia de la configuración inicial.

Para ver cómo funciona el seguimiento de la salida de la aplicación, recupera la URL de tu servicio Wasm; por ejemplo, https://<your-name>.edgecompute.app/. Luego recupera las otras dos rutas virtuales del mismo subdominio: /articles y /anything.

Como mínimo, estas peticiones de recuperación deberían dar como resultado una salida similar a esta:

stdout | 5ee29b16 | Request received for path /
stdout | f438ba38 | Request received for path /articles
stdout | 44c848ca | Request received for path /anything

Si has emitido las peticiones desde un navegador web, puede ser que veas más entradas correspondientes a JavaScript y a los artefactos de imágenes. Si ni siquiera ves la salida prevista inicialmente, intenta volver a emitir las peticiones de recuperación. El valor hash junto a cada mensaje de salida es un identificador de correlación de cada petición, de modo que una sola petición puede generar varios mensajes de salida. A continuación veremos cómo sucede esto. Pulsa ^C para salir.

Vuelve a tu MyEdgeComputeApp y añade el siguiente código debajo de "/articles" => {:

       "/articles" => {
            eprintln!("Request will be redirected to {}", BACKEND_NAME);
            // Request handling logic could go here...  E.g., send the request to an origin backend
            ...

Una vez más, compila y vuelve a desplegar tu aplicación Wasm:

fastly compute build
fastly compute deploy --service-id=<your-Fastly-service-ID>

Ahora, vuelve a hacer un seguimiento de la salida de tu aplicación Wasm:

fastly log-tail --service-id=<your-Fastly-service-ID>

Emite una petición de recuperación para https://<your-name>.edgecompute.app/articles y observa la salida supervisada. Deberías ver líneas de código parecidas a estas:

stdout | ad3d576e | Request received for path /articles
stderr | ad3d576e | Request will be redirected to backend_name

A simple vista, no parece nada del otro mundo, ¿verdad? Sin embargo, si te fijas, puedes ver que ocurren un par de cosas:

Tienes dos mensajes emitidos en dos flujos de salida distintos: stdout y stderr.
Ambas salidas se han generado a partir de una sola petición, que en el ejemplo anterior se identifica mediante ad3d576e.

Por cierto, la CLI también permite filtrar la salida por tipo de flujo (por si te lo estás preguntando).

¿Qué hemos observado en esta parte? Que si usas flujos de salida STDOUT y STDERR de Rust, puedes emitir información valiosa desde la aplicación Wasm de Compute, y que si usas fastly log-tail, puedes realizar un seguimiento de la salida emitida y mostrarla de forma local en tu sistema. Un último punto importante es que fastly log-tail también te permite retroceder en el tiempo y mostrar la salida emitida que se capturó en un intervalo de tiempo especificado. Si esto te interesa, tienes toda la información en la documentación sobre esta funcionalidad.

Tu aplicación Wasm de Compute te parece fascinante, ¿verdad? Pero, ¿qué pasa si quieres desplegarla en producción pero no quieres aprovechar los flujos de salida estándar de tu terminal? O quizás te gustaría poder almacenar y consultar mejor la información de registro emitida. Es más, ¿y si resulta que lo que quieres es automatizar el proceso de análisis de registros para identificar anomalías o detectar oportunidades de negocio cruciales a partir de las peticiones que recibe tu aplicación Wasm?

¡Pues estás de suerte! La solución a todo esto es nuestra plataforma de envío de registros, que está disponible para los servicios y aplicaciones Wasm de la misma forma que para las configuraciones de VCL tradicionales. En las siguientes partes veremos en detalle cómo configurar y registrar complejos puntos de conexión de agregación de registros desde la aplicación Wasm y nos aseguraremos de que los registros están disponibles en la plataforma de análisis.

Configurar puntos de conexión de registro

Para poder enviar los registros a los sistemas de agregación, primero tenemos que configurar unos cuantos puntos de conexión. Vamos a configurar un punto de conexión de Kafka en la nube y otro en Azure mediante Event Hubs. Usaremos la primera de las configuraciones de nuestro ejemplo y consultaremos la documentación sobre la plataforma Microsoft Azure si necesitamos más información sobre el servicio. También usaremos las herramientas de Kafka de forma muy rudimentaria, ya que lo único que nos importa es la integración de extremo a extremo real.

Si ya has instalado la CLI de Azure y has creado una cuenta de Azure (bastará con que tengas una de prueba), inicia sesión a través de la CLI. Es posible que tengas que iniciar sesión con el identificador de inquilino para autenticarte correctamente:

az login --tenant <your-tenant-ID>

En la salida del comando anterior deberían aparecer tus suscripciones de Azure activas, y bastará con una de tipo Basic. Fíjate en el identificador de suscripción de la salida del comando. Ejecuta los siguientes comandos para montar un clúster de Event Hubs en Azure. En estos comandos se usa como ubicación de destino la región «Oeste del centro de EE. UU.», pero puedes ejecutar az account list-locations y cambiarla por la que prefieras.

az group create --location westcentralus --name MyAzureGroup \
--subscription <your-subscription-ID>

az eventhubs namespace create --name <your-unique-namespace> \
--resource-group MyAzureGroup --enable-kafka true \
--location westcentralus --sku Standard \
--subscription <your-subscription-ID> \
--enable-auto-inflate false

az eventhubs eventhub create --resource-group MyAzureGroup \
--namespace-name <your-unique-namespace> --name MyEventHub \
--message-retention 1 --partition-count 1 --enable-capture false \
--subscription <your-subscription-ID>

az eventhubs eventhub authorization-rule create \
--eventhub-name MyEventHub --name Fastly \
--namespace-name <your-unique-namespace> \
--resource-group MyAzureGroup --rights Listen Send \
--subscription <your-subscription-ID>

az eventhubs eventhub authorization-rule keys list \
--eventhub-name MyEventHub --name Fastly \
--namespace-name <your-unique-namespace> \
--resource-group MyAzureGroup \
--subscription <your-subscription-ID>

Si el nombre de tu espacio de nombres de Event Hubs no está disponible, prueba con otro. El último de los comandos anteriores mostrará la cadena de conexión segura de Azure Event Hubs ("primaryConnectionString"), que vas a necesitar para configurar el punto de conexión Kafka para el envío de registros de Fastly en los siguientes pasos.

Con los comandos anteriores se configura un único Event Hub parecido a un tema de Kafka. Pero ¿qué pasa si tenemos dos canalizaciones de procesamiento de datos diferentes para distintos tipos de eventos y queremos analizar por separado estas categorías de eventos? Vamos a configurar otro Event Hub exclusivamente para esto. Ejecuta los siguientes comandos para inicializar un bus de eventos secundario para distintos eventos:

az eventhubs eventhub create --resource-group MyAzureGroup \
--namespace-name <your-unique-namespace> --name MyOtherEventHub \
--message-retention 1 --partition-count 1 --enable-capture false \
--subscription <your-subscription-ID>

az eventhubs eventhub authorization-rule create \
--eventhub-name MyOtherEventHub --name Fastly \
--namespace-name <your-unique-namespace> \
--resource-group MyAzureGroup --rights Listen Send \
--subscription <your-subscription-ID>

az eventhubs eventhub authorization-rule keys list \
--eventhub-name MyOtherEventHub --name Fastly \
--namespace-name <your-unique-namespace> \
--resource-group MyAzureGroup \
--subscription <your-subscription-ID>

Como ya hemos visto, el último de los comandos anteriores mostrará la cadena de conexión segura de Azure Event Hubs ("primaryConnectionString"), que vas a necesitar para configurar específicamente el segundo punto de conexión Kafka para el envío de registros de Fastly.

Ejecuta el siguiente comando en la CLI para añadir a tu servicio Wasm de Compute el primer punto de conexión de Azure Event Hubs que has creado:

fastly logging kafka create --name=AzureEventHubs --version=latest \
--topic=MyEventHub \
--brokers=<your-unique-namespace>.servicebus.windows.net:9093 \
--service-id=<your-Fastly-service-ID> --required-acks=-1 --use-tls --max-batch-size=2048 \
--use-sasl --auth-method=plain --username='$ConnectionString' \
--password='<value-of-first-Azure-primaryConnectionString>' --autoclone --placement=none

Ten en cuenta que, cuando ejecutes este comando, se creará una nueva versión del borrador de la configuración del servicio que, sin embargo, no estará activa. La activaremos más adelante, cuando publiquemos el código actualizado de tu aplicación Wasm. Fíjate también en que, en el comando, el punto de conexión de registro se denomina «AzureEventHubs» y ten en cuenta que tendrás que usar ese mismo nombre de punto de conexión de registro en el código de tu aplicación Wasm.

Ejecuta el siguiente comando en la CLI para añadir a tu servicio Wasm de Compute el segundo punto de conexión de Azure Event Hubs que has creado:

fastly logging kafka create --name=AnotherAzureEventHubs --version=latest \
--topic=MyOtherEventHub \
--brokers=<your-unique-namespace>.servicebus.windows.net:9093 \
--service-id=<your-Fastly-service-ID> --required-acks=-1 --use-tls --max-batch-size=2048 \
--use-sasl --auth-method=plain --username='$ConnectionString' \
--password='<value-of-second-Azure-primaryConnectionString>' --autoclone --placement=none

Fíjate también en el nombre de este segundo punto de conexión de registro, «AnotherAzureEventHubs»; lo usarás en tu código para dirigir eventos específicos únicamente al destino de registro correspondiente.

Para confirmar la configuración de los dos puntos de conexión de registro de tu servicio Wasm de Compute, ejecuta el siguiente comando:

fastly logging kafka list --version=latest --service-id=<your-Fastly-service-ID>

Deberías ver en la salida los dos puntos de conexión, «AzureEventHubs» y «AnotherAzureEventHubs», uno al lado del otro.

Añadir registros listos para el entorno de producción

Ahora que ya tienes configurados los puntos de conexión de registro de tu servicio Wasm, puedes hacer referencia a ellos desde el código de la aplicación Wasm.

Para eso, primero tienes que añadir las dependencias necesarias de nuestro proyecto Rust, MyEdgeComputeApp. Busca el archivo ./Cargo.toml y edítalo para incluir las siguientes dependencias:

[dependencies]
fastly = "^0.8.0"
log-fastly = "0.8.0"
log = "0.4.14"
fern = "0.6"
chrono = "0.4"

La documentación de la caja log-fastlyse puede consultar online.

Si tu editor está integrado con el lenguaje de programación Rust, podrá extraer estas dependencias de inmediato, o bien se descargarán cuando vuelvas a compilar esta aplicación Wasm. No obstante, ten en cuenta que puede ser que cuando leas esto haya nuevas versiones de las dependencias. Confirma cuáles son las versiones más recientes y utiliza esas.

En ./src/main.rs, añade el siguiente código de inicialización debajo de fn main(mut req: Request) -> Result<Response, Error> {:

fn main(mut req: Request) -> Result<Response, Error> {
    let logger: Box<dyn log::Log> = Box::new(log_fastly::Logger::builder()
        .max_level(log::LevelFilter::Info)
        .default_endpoint("AzureEventHubs")
        .endpoint("AnotherAzureEventHubs").build()
        .expect("Unable to init Fastly logger"));
    fern::Dispatch::new()
        .format(|out, message, record| {
            out.finish(format_args!(
                "{}[{}] {}",
                chrono::Local::now().format("[%Y-%m-%d][%H:%M:%S]"),
                record.level(),
                message
            ))
        })
        .chain(logger)
        .apply()?;

    ...

Busca la cláusula de coincidencia “/articles” y añade una instrucción de registro debajo:

       "/articles" => {
            log::info!("Processing request to {}", req.get_path());
            ...

Busca la cláusula de coincidencia del prefijo de ruta “/anything” y añade una instrucción de registro debajo:

       path if path.starts_with("/anything") => {
            log::warn!(target: "AnotherAzureEventHubs", "Processing request to {}", req.get_path());
            ...

Compila y vuelve a desplegar tu aplicación Wasm:

fastly compute build
fastly compute deploy --service-id=<your-Fastly-service-ID>

Ten en cuenta que el despliegue se realizará en la última versión del borrador de configuración de tu servicio Wasm y que, al desplegarse, se activará esa versión.

Emite cuatro o cinco peticiones de recuperación en https://<your-name>.edgecompute.app/articles. Luego emite cuatro o cinco peticiones de recuperación en https://<your-name>.edgecompute.app/anything.

Ahora vamos a recuperar los mensajes que tu aplicación Wasm debería haber enviado a los diversos puntos de conexión de Azure Event Hubs.

Descarga y extrae Apache Kafka de https://kafka.apache.org/downloads, pero ten en cuenta que solo usaremos el cliente Kafka de esa distribución. Para usar la distribución de Kafka es necesario tener instalado Java en el sistema, pero puedes hacer lo mismo con otro cliente de Kafka, como kafkacat/kcat, y ajustar las marcas de la línea de comandos de forma correspondiente. Después de extraer los artefactos de Kafka, el directorio actual pasa a ser la raíz de ese archivo, así que tendrás que cambiar el directorio actual a ./bin.

Crea un archivo, ./azure_client.properties, con el siguiente contenido:

sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="$ConnectionString" \
    password="<value-of-first-Azure-primaryConnectionString>";
sasl.mechanism=PLAIN
security.protocol=SASL_SSL

Ejecuta el siguiente comando para leer los eventos de Kafka publicados desde tu primera instancia de Azure Event Hubs:

./kafka-console-consumer.sh --bootstrap-server \
<your-unique-namespace>.servicebus.windows.net:9093 \
--topic MyEventHub \
--consumer.config ./azure_client.properties --from-beginning

La respuesta debería generar una salida parecida a la siguiente:

[2021-09-16][21:00:08][INFO] Processing request to /articles
[2021-09-16][21:00:08][INFO] Processing request to /articles
[2021-09-16][21:00:09][INFO] Processing request to /articles
[2021-09-16][21:00:09][INFO] Processing request to /articles
[2021-09-16][21:00:09][INFO] Processing request to /articles

Pulsa ^C para salir de kafka-console-consumer.sh.

Si no ves mensajes como los de arriba y, sin embargo, se genera una salida que indica que el cliente de Kafka se ha desconectado, es posible que el firewall de tu sistema operativo o de tu componente de red local esté bloqueando la conexión de kafka-console-consumer.sh a Azure Event Hubs. Como esto puede suceder, configura el firewall para permitir el acceso al puerto 9093 en el dominio windows.net.

La marca de tiempo de cada mensaje de registro refleja el momento en que se creó el mensaje. Como puedes ver, la línea de registro que hemos añadido a nuestro código Rust para gestionar las peticiones a “/articles” aparece como el mensaje en nuestro primer Azure Event Hub. Estos mensajes se registran en el nivel de registro INFO. Como habrás visto, no se genera ningún mensaje de registro asociado a la gestión de las peticiones a “/anything” .

A continuación, crea otro archivo, ./another_azure_client.properties, con el siguiente contenido:

sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="$ConnectionString" \
    password="<value-of-second-Azure-primaryConnectionString>";
sasl.mechanism=PLAIN
security.protocol=SASL_SSL

Ejecuta el siguiente comando para leer los eventos de Kafka publicados desde tu segunda instancia de Azure Event Hubs:

./kafka-console-consumer.sh --bootstrap-server \
<your-unique-namespace>.servicebus.windows.net:9093 \
--topic MyOtherEventHub \
--consumer.config ./another_azure_client.properties --from-beginning

La respuesta debería generar una salida parecida a la siguiente:

[2021-09-16][21:02:06][WARN] Processing request to /anything
[2021-09-16][21:02:07][WARN] Processing request to /anything
[2021-09-16][21:02:07][WARN] Processing request to /anything
[2021-09-16][21:02:10][WARN] Processing request to /anything
[2021-09-16][21:02:10][WARN] Processing request to /anything

Pulsa ^C para salir de kafka-console-consumer.sh. Como puedes observar, solo se generan mensajes de registro asociados a la gestión de las peticiones a “/anything”, registradas en el nivel de registro WARN. Sin embargo, no se generan mensajes sobre la gestión de las peticiones a “/articles”.

Este ejemplo que hemos visto del envío a puntos de conexión de registro distintos también es válido para el envío a distintos proveedores de servicios en la nube, y no se limita únicamente a Kafka. Puedes dirigir mensajes de registro diferentes de forma exclusiva o redundante a distintos destinos de integración compatibles con nuestro envío de registros, como Amazon S3, Google BigQuery, Splunk y muchos más. El uso de nuestra funcionalidad de envío de registros en tus servicios Wasm de Compute te permite segmentar tus flujos de mensajes de registro en distintos destinos, según la intención; por ejemplo, para detectar anomalías o con fines de inteligencia empresarial.

Cuando termines este tutorial, consulta la documentación de la CLI de Azure para saber cómo deshacerte de los recursos aprovisionados, como el grupo de recursos. Es posible que haya que eliminar el espacio de nombres de Event Hubs y el Event Hub subyacente antes de eliminar el grupo.

Conclusión

¡Enhorabuena! En este tutorial has aprendido a configurar un servicio Wasm de Compute, y a compilar y publicar tu aplicación Rust en ese servicio. Además, ahora ya sabes cómo emitir salida a STDOUT y STDERR, y cómo hacerle un seguimiento desde la línea de comandos. Por último, has aprendido a configurar Azure Event Hubs como destino del envío de registros, has añadido instrucciones de registro formales a tu aplicación Wasm programada en Rust y has comprobado que los registros se emiten correctamente a su destino de Azure Event Hubs. ¡Lo has clavado!

Tómate tu tiempo para explorar más a fondo nuestra CLI, los servicios Wasm de Compute y el envío de registros. Si aún no has utilizado Compute y quieres probarlo, tenemos una oferta por tiempo limitado que te permitirá hacer pruebas y configurarlo durante tres meses y sin coste alguno; además, ofrecemos hasta 100 000 USD/mes en saldo durante seis meses.