GSP484

Descripción general
Cuando se admite un sistema de producción que entrega solicitudes HTTP o proporciona una API, es importante medir la latencia de tus extremos para detectar cuándo el rendimiento de un sistema no funciona según las especificaciones. En los sistemas monolíticos, esta única medida de latencia puede ser útil para detectar y diagnosticar un comportamiento que se va deteriorando. No obstante, con las arquitecturas de microservicio modernas, esto resulta mucho más difícil porque una sola solicitud puede dar lugar a numerosas solicitudes adicionales a otros sistemas antes de que la solicitud pueda controlarse por completo.
El deterioro del rendimiento en un sistema subyacente puede afectar a todos los demás sistemas que dependen de él. Si bien la latencia se puede medir en cada extremo del servicio, puede resultar difícil correlacionar un comportamiento lento en el extremo público con un determinado subservicio que tiene un mal comportamiento.
Comienza a usar el seguimiento distribuido. El seguimiento distribuido utiliza metadatos que se pasan junto con las solicitudes para correlacionarlas en los diferentes niveles de servicio. Por medio de la recopilación de datos de telemetría de todos los servicios en una arquitectura de microservicio y la propagación de un ID de seguimiento desde una solicitud inicial hasta todas las solicitudes secundarias, los desarrolladores pueden identificar de forma mucho más fácil qué servicio está causando las demoras que afectan al resto del sistema.
Google Cloud proporciona el operations suite, un paquete de productos para controlar el registro, la supervisión y el seguimiento distribuido. El contenido de este lab se implementará en Kubernetes Engine y se demostrará una arquitectura de varios niveles que implementa el seguimiento distribuido. También aprovechará Terraform para compilar la infraestructura necesaria.
Los ingenieros de GKE Helmsman crearon este lab para ayudarte a comprender mejor la Autorización Binaria de GKE. Para ver esta demostración, ejecuta los comandos gsutil cp -r gs://spls/gke-binary-auth/* .
y cd gke-binary-auth-demo
en Cloud Shell. Te invitamos a hacer cualquier aporte que creas conveniente.
Configuración y requisitos
Antes de hacer clic en el botón Comenzar lab
Lee estas instrucciones. Los labs cuentan con un temporizador que no se puede pausar. El temporizador, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.
Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.
Para completar este lab, necesitarás lo siguiente:
- Acceso a un navegador de Internet estándar. Se recomienda el navegador Chrome.
Nota: Usa una ventana del navegador privada o de incógnito (opción recomendada) para ejecutar el lab. Así evitarás conflictos entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.
- Tiempo para completar el lab (recuerda que, una vez que comienzas un lab, no puedes pausarlo).
Nota: Usa solo la cuenta de estudiante para este lab. Si usas otra cuenta de Google Cloud, es posible que se apliquen cargos a esa cuenta.
Cómo iniciar tu lab y acceder a la consola de Google Cloud
-
Haz clic en el botón Comenzar lab. Si debes pagar por el lab, se abrirá un diálogo para que selecciones la forma de pago.
A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:
- El botón para abrir la consola de Google Cloud
- El tiempo restante
- Las credenciales temporales que debes usar para el lab
- Otra información para completar el lab, si es necesaria
-
Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).
El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.
Sugerencia: Ordena las pestañas en ventanas separadas, una junto a la otra.
Nota: Si ves el diálogo Elegir una cuenta, haz clic en Usar otra cuenta.
-
De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.
{{{user_0.username | "Username"}}}
También puedes encontrar el nombre de usuario en el panel Detalles del lab.
-
Haz clic en Siguiente.
-
Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.
{{{user_0.password | "Password"}}}
También puedes encontrar la contraseña en el panel Detalles del lab.
-
Haz clic en Siguiente.
Importante: Debes usar las credenciales que te proporciona el lab. No uses las credenciales de tu cuenta de Google Cloud.
Nota: Usar tu propia cuenta de Google Cloud para este lab podría generar cargos adicionales.
-
Haz clic para avanzar por las páginas siguientes:
- Acepta los Términos y Condiciones.
- No agregues opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
- No te registres para obtener pruebas gratuitas.
Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.
Nota: Para acceder a los productos y servicios de Google Cloud, haz clic en el menú de navegación o escribe el nombre del servicio o producto en el campo Buscar.
Activa Cloud Shell
Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.
-
Haz clic en Activar Cloud Shell
en la parte superior de la consola de Google Cloud.
-
Haz clic para avanzar por las siguientes ventanas:
- Continúa en la ventana de información de Cloud Shell.
- Autoriza a Cloud Shell para que use tus credenciales para realizar llamadas a la API de Google Cloud.
Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu Project_ID, . El resultado contiene una línea que declara el Project_ID para esta sesión:
Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}
gcloud
es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.
- Puedes solicitar el nombre de la cuenta activa con este comando (opcional):
gcloud auth list
- Haz clic en Autorizar.
Resultado:
ACTIVE: *
ACCOUNT: {{{user_0.username | "ACCOUNT"}}}
To set the active account, run:
$ gcloud config set account `ACCOUNT`
- Puedes solicitar el ID del proyecto con este comando (opcional):
gcloud config list project
Resultado:
[core]
project = {{{project_0.project_id | "PROJECT_ID"}}}
Nota: Para obtener toda la documentación de gcloud
, en Google Cloud, consulta la guía con la descripción general de gcloud CLI.
Clona la demostración
- Ejecuta el siguiente comando para clonar los recursos que se necesitarán en este lab:
git clone https://github.com/GoogleCloudPlatform/gke-tracing-demo
- Dirígete al directorio de esta demostración:
cd gke-tracing-demo
Configura tu región y zona
Algunos recursos de Compute Engine se encuentran en regiones y zonas. Una región es una ubicación geográfica específica donde puedes ejecutar tus recursos. Cada región tiene una o más zonas.
Nota: Para obtener más información sobre las regiones y zonas y ver una lista de todas ellas, consulta esta documentación.
Ejecuta el siguiente comando para configurar una región y zona para tu lab (puedes usar la región/zona más adecuada para tu caso):
gcloud config set compute/region {{{ project_0.default_region | REGION }}}
gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}
Arquitectura
El lab comienza con la implementación de un clúster de Kubernetes Engine. En este clúster, se implementará una aplicación web simple encabezada por un balanceador de cargas. La aplicación web publicará los mensajes que proporciona el usuario en un tema de Cloud Pub/Sub. La aplicación está instrumentada de tal manera que las solicitudes HTTP que recibe darán lugar a la creación de un seguimiento cuyo contexto se propagará en la solicitud a la API de publicación de Cloud Pub/Sub. Los datos de telemetría correlacionados de estas solicitudes estarán disponibles en la consola de Cloud Trace.

Introducción a Terraform
De acuerdo con los principios de la infraestructura como código y de la infraestructura inmutable, Terraform admite escrituras de descripciones declarativas del estado deseado de la infraestructura. Cuando se aplica el descriptor, Terraform usa las APIs de Google Cloud para aprovisionar y actualizar los recursos para que coincidan. Terraform compara el estado deseado con el estado actual para poder realizar cambios incrementales sin tener que borrar todo y volver a empezar. Por ejemplo, Terraform puede crear proyectos de Google Cloud, instancias de procesamiento, etc., incluso configurar un clúster de Kubernetes Engine y, luego, implementar aplicaciones en él. Cuando los requisitos cambian, el descriptor se puede actualizar, y Terraform ajustará la infraestructura de nube según corresponda.
En este ejemplo, se iniciará un clúster de Kubernetes Engine con Terraform. Luego, utilizarás los comandos de Kubernetes para implementar una aplicación de demostración en el clúster.
De forma predeterminada, los clústeres de Kubernetes Engine en Google Cloud se lanzan con un colector preconfigurado basado en Fluentd que reenvía los eventos de registro del clúster a Cloud Monitoring. La interacción con la aplicación de demostración producirá eventos de seguimiento que se verán en la IU de Cloud Trace.
Ejecuta Terraform
Hay tres archivos de Terraform que se proporcionan con esta demostración, ubicados en el subdirectorio /terraform
del proyecto. El primer archivo, main.tf
, es el punto de partida de Terraform. Describe las funciones que se utilizarán, los recursos que se manipularán y los resultados que se obtendrán. El segundo archivo es provider.tf
, que indica qué proveedor de servicios en la nube y qué versión serán los destinatarios de los comandos de Terraform, en este caso, Google Cloud. El último archivo es variables.tf
, que contiene una lista de variables que se usan como entradas en Terraform. Cualquier variable a la que se haga referencia en main.tf
que no tenga valores predeterminados configurados en variables.tf
tendrá como resultado mensajes al usuario en el entorno de ejecución.
Tarea 1: Inicialización
Dado que la autenticación se configuró anteriormente, ya puedes implementar la infraestructura.
- Ejecuta el siguiente comando desde el directorio raíz del proyecto:
cd terraform
Actualiza el archivo provider.tf
Quita la versión del proveedor de Terraform del archivo de secuencia de comandos provider.tf
.
- Edita el archivo de secuencia de comandos
provider.tf
:
nano provider.tf
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "3.84.0"
}
}
}
provider "google" {
project = var.project
}
- Guarda el archivo con CTRL + X > Y > Intro.
Después de la modificación, el archivo de secuencia de comandos provider.tf
debería verse así:
...
provider "google" {
project = var.project
}
Desde aquí, inicializa Terraform:
- Ingresa lo siguiente:
terraform init
Esto descargará las dependencias que Terraform requiere: el proyecto de Google Cloud y la zona de Google Cloud en la que se debe implementar la aplicación de demostración. Terraform solicitará estos valores si todavía no los conoce. De forma predeterminada, buscará un archivo llamado terraform.tfvars
o archivos con un sufijo .auto.tfvars
en el directorio actual para obtener esos valores.
Esta demostración proporciona una secuencia de comandos conveniente para solicitar la zona y el proyecto, y mantenerlos en el archivo terraform.tfvars
.
- Ejecuta lo siguiente:
../scripts/generate-tfvars.sh
Nota: Recibirás un mensaje de error si el archivo ya existe.
La secuencia de comandos usa valores previamente configurados del comando de gcloud
. Si no se configuraron, el mensaje de error indicará cómo deben configurarse. Los valores existentes se pueden ver con el siguiente comando:
gcloud config list
- Si los valores mostrados no se corresponden con el lugar en el que deseas ejecutar la aplicación de demostración, cambia los valores en
terraform.tfvars
por los que prefieras.
Tarea 2: Implementación
- Una vez que inicialices Terraform, puedes ver el trabajo que Terraform realizará con el siguiente comando:
terraform plan
Este comando se puede usar para verificar visualmente que la configuración es correcta, y Terraform te informará si detecta algún error. Si bien no es necesario, se recomienda ejecutarlo siempre antes de cambiar la infraestructura con Terraform.
- Después de la verificación, indícale a Terraform que configure la infraestructura necesaria:
terraform apply
Se muestran los cambios que se realizarán y se te pide que confirmes con yes
.
Nota: Si recibes advertencias de baja relacionadas con la variable de zona, ignóralas y avanza en el lab.
Mientras esperas que se complete tu compilación, configura el espacio de trabajo de Cloud Monitoring para usar más adelante en el lab.
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si implementaste correctamente la infraestructura necesaria con Terraform, verás una puntuación de evaluación.
Usar Terraform para configurar la infraestructura necesaria
Crea un permiso de métricas de Monitoring
Configura un permiso de métricas de Monitoring que esté vinculado a tu proyecto de Google Cloud. Sigue estos pasos para crear una cuenta nueva que incluya una prueba gratuita de Monitoring.
- En la consola de Cloud, haz clic en el menú de navegación (
) > Ver todos los productos > Observabilidad > Monitoring.
Cuando se abra la página de Descripción general de Monitoring, tu proyecto de permisos de métricas estará listo.
Tarea 3: Implementa la aplicación de demostración
-
En Cloud Shell, cuando veas el mensaje Apply complete!
, vuelve a la consola.
-
En el menú de navegación, dirígete a Kubernetes Engine > Clústeres para ver tu clúster.
-
Haz clic en Menú de navegación, luego desplázate hacia abajo hasta la sección Estadísticas y haz clic en Pub/Sub para ver el tema y la suscripción.
-
Ahora, implementa la aplicación de demostración con el comando de kubectl
de Kubernetes:
kubectl apply -f tracing-demo-deployment.yaml
Una vez que la aplicación se implementó, se puede ver en Kubernetes Engine > Cargas de trabajo. También puedes ver el balanceador de cargas que se creó para la aplicación en la sección Ingress y servicios de la consola.
Es posible que la aplicación demore unos minutos en implementarse. Si la consola de tus cargas de trabajo se parece a la siguiente y tiene el estado "No tiene disponibilidad mínima":

- Actualiza la página hasta que veas "OK" o "Sin errores" en la barra de estado.

Por cierto, el extremo se puede adquirir de manera programática con el siguiente comando:
echo http://$(kubectl get svc tracing-demo -n default -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si implementaste correctamente la aplicación de demostración, verás una puntuación de evaluación.
Implementar la aplicación de demostración
Tarea 4: Validación
Genera datos de telemetría
Una vez implementada la aplicación de demostración, deberías ver una lista de tus servicios expuestos.
- En la ventana de Kubernetes, haz clic en Ingress y Service para ver los servicios expuestos.

- Haz clic en el extremo que se encuentra al lado del balanceador de cargas
tracing-demo
para abrir la página web de la aplicación de demostración en una pestaña nueva de tu navegador.
Ten en cuenta que tu dirección IP probablemente será diferente a la del ejemplo anterior. La página que se muestra es simple:

- Agrega la cadena
?string=CustomMessage
a la URL y observa que se muestra el mensaje:

Como puedes ver, si no se proporciona un parámetro string
, utiliza el valor predeterminado Hello World
. La aplicación se utiliza para generar datos de telemetría de seguimiento.
- Reemplaza ‟CustomMessage” por tus propios mensajes para generar algunos datos de análisis.
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si generaste los datos de telemetría correctamente, verás una puntuación de evaluación.
Generar datos de telemetría
Examina los seguimientos
-
En la consola, selecciona el menú de navegación > Trace > Explorador de seguimiento. Deberías ver un gráfico que muestra los eventos de seguimiento trazados en un cronograma con la latencia como métrica vertical.
-
Haz clic en el botón de activación Volver a cargar automáticamente para ver los datos más recientes.

Nota: Selecciona los puntos para expandir la vista.
- Haz clic en uno de los puntos en el gráfico. Verás un gráfico con dos barras, en el que la barra superior es más larga que la inferior.
La barra superior se conoce como el intervalo raíz y representa la duración de la solicitud HTTP, desde el momento en que llega el primer byte hasta el momento en que se envía el último byte de la respuesta. La barra inferior representa la duración de la solicitud que se realiza cuando se envía el mensaje al tema de Pub/Sub.
Dado que el control de la solicitud HTTP está bloqueado por la llamada a la API de Pub/Sub, resulta evidente que la gran mayoría del tiempo dedicado a la solicitud HTTP está ocupado por la interacción de Pub/Sub. Esto demuestra que, cuando se instrumenta cada nivel de tu aplicación, puedes identificar fácilmente dónde están los cuellos de botella.
Extrae mensajes de Pub/Sub
Como se describe en la sección Arquitectura en este documento, los mensajes de la aplicación de demostración se publican en un tema de Pub/Sub.
Estos mensajes se pueden consumir desde el tema con la CLI de gcloud
:
gcloud pubsub subscriptions pull --auto-ack --limit 10 tracing-demo-cli
Resultado:
DATA: Hello World
MESSAGE_ID: 4117341758575424
ORDERING_KEY:
ATTRIBUTES:
DELIVERY_ATTEMPT:
DATA: CustomMessage
MESSAGE_ID: 4117243358956897
ORDERING_KEY:
ATTRIBUTES:
DELIVERY_ATTEMPT:
Extraer los mensajes del tema no tiene ningún impacto en el seguimiento. En esta sección, simplemente se proporciona un consumidor de los mensajes para fines de verificación.
Supervisión y registro
La supervisión y el registro de Cloud no son el tema de esta demostración, pero vale la pena señalar que la aplicación que implementaste publicará los registros en Cloud Logging y las métricas en Cloud Monitoring.
-
En la consola, selecciona Menú de navegación > Monitoring > Explorador de métricas.
-
En el campo Selecciona una métrica, selecciona Instancia de VM > Instancia > Uso de CPU y, luego, haz clic en Aplicar.
Deberías ver un gráfico de esta métrica trazado para diferentes Pods que se ejecutan en el clúster:
-
Para ver los registros, selecciona Menú de navegación > Logging.
-
En la sección Campos de registro, configura los siguientes parámetros:
-
TIPO DE RECURSO:
Kubernetes Container
-
NOMBRE DEL CLÚSTER:
tracing-demo-space
-
NOMBRE DEL ESPACIO DE NOMBRES:
default

Tarea 5: Soluciona problemas en tu propio entorno
Se pueden diagnosticar varios errores posibles con el comando kubectl
.
Por ejemplo, se puede mostrar una implementación:
kubectl get deployment tracing-demo
Resultado:
NAME READY UP-TO-DATE AVAILABLE AGE
tracing-demo 1/1 1 1 21m
Puedes obtener más información con describe
:
kubectl describe deployment tracing-demo
Este comando mostrará una lista de Pods implementados:
kubectl get pod
Resultado:
NAME READY STATUS RESTARTS AGE
tracing-demo-59cc7988fc-h5w27 1/1 Running 0 23m
Una vez más, los detalles del Pod se pueden ver con describe
:
kubectl describe pod tracing-demo
-
Toma nota del nombre del Pod para usarlo en el próximo paso.
-
Una vez que sepas el nombre del Pod, usa ese nombre para ver los registros de forma local:
kubectl logs <LOG_NAME>
Resultado:
10.60.0.1 - - [22/Jun/2018:19:42:23 +0000] "HEAD / HTTP/1.0" 200 - "-" "-"
Publishing string: Hello World
10.60.0.1 - - [22/Jun/2018:19:42:23 +0000] "GET / HTTP/1.1" 200 669 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"
La secuencia de comandos de instalación falla con Permission denied
cuando se ejecuta Terraform.
Las credenciales que utiliza Terraform no proporcionan los permisos necesarios para crear recursos en los proyectos seleccionados. Asegúrate de que la cuenta detallada en gcloud config list
tenga los permisos necesarios para crear recursos. Si los tiene, vuelve a generar las credenciales predeterminadas de la aplicación con
gcloud auth application-default login
.
Tarea 6: Eliminación
- Qwiklabs se encargará de cerrar todos los recursos utilizados en este lab, pero esto es lo que debes hacer para limpiar tu propio entorno y así reducir los costos y ser un buen ciudadano de la nube:
terraform destroy
Al igual que con apply
, Terraform solicitará un yes
para confirmar tu intención.
Dado que Terraform realiza un seguimiento de los recursos que creaste, puedes eliminar el clúster, el tema de Pub/Sub y la suscripción de Pub/Sub.
Nota: Si aparecen advertencias de baja relacionadas con la variable de zona, ignóralas.
¡Felicitaciones!
Próximos pasos y más información
Los siguientes son algunos materiales relevantes para realizar una mayor investigación:
Kubernetes
Kubernetes es una plataforma de organización de contenedores popular en las arquitecturas de microservicio. Google Cloud proporciona una versión administrada de
Kubernetes llamada Kubernetes Engine.
OpenCensus
OpenCensus proporciona bibliotecas estandarizadas para capturar y publicar datos de telemetría de seguimiento. Se proporcionan bibliotecas para varios lenguajes populares y se admiten numerosas plataformas de seguimiento, como Cloud Monitoring y Zipkin. La demostración que se describe en este documento utiliza OpenCensus para publicar datos de telemetría en Cloud Monitoring.
Spring Sleuth
Spring Sleuth brinda instrumentación de aplicaciones Java que usan el framework popularSpring. Spring Sleuth admite una abstracción de los recopiladores de telemetría de seguimiento distribuidos para que los desarrolladores puedan cambiar sin problemas entre Zipkin, Cloud Monitoring y otros motores de seguimiento.
Cloud Monitoring
Operations es un paquete de productos en Google Cloud que ofrece funciones de registro, supervisión, seguimiento y otras relacionadas. Este documento y la demostración se enfocan especialmente en la función que Cloud Trace proporciona.
Terraform
Terraform es una herramienta declarativa de infraestructura como código que habilita que los archivos de configuración se puedan usar en la automatización de la implementación y de la evolución de la infraestructura en la nube.
Zipkin
Zipkin es una herramienta de seguimiento distribuido que ayudó a popularizar la práctica.
Las aplicaciones que ya están instrumentadas para Zipkin pueden adaptar sus datos de telemetría de Zipkin a los eventos de Cloud Monitoring con un recopilador de Zipkin. Se puede
implementar en Kubernetes Engine.
Finaliza el lab
Cuando completes el lab, haz clic en Finalizar lab. Tu cuenta y los recursos que usaste se quitaron de la plataforma del lab.
Tendrás la oportunidad de calificar tu experiencia en el lab. Selecciona la cantidad de estrellas que corresponda, ingresa un comentario y haz clic en Enviar.
La cantidad de estrellas indica lo siguiente:
- 1 estrella = Muy insatisfecho
- 2 estrellas = Insatisfecho
- 3 estrellas = Neutral
- 4 estrellas = Satisfecho
- 5 estrellas = Muy satisfecho
Puedes cerrar el cuadro de diálogo si no deseas proporcionar comentarios.
Para enviar comentarios, sugerencias o correcciones, usa la pestaña Asistencia.
Última actualización del manual: 16 de junio de 2025
Prueba más reciente del lab: 16 de junio de 2025
Copyright 2024 Google LLC. Este software se proporciona tal como está, sin garantías ni declaraciones para ningún uso o propósito. El uso que hagas de él está sujeto a tu acuerdo con Google.