GSP736

Descripción general

Cloud Logging y su herramienta complementaria, Cloud Monitoring, son productos destacados, integrados de manera completa a Google Kubernetes Engine. Este lab te enseña cómo funciona Cloud Logging con aplicaciones y clústeres de GKE y algunas prácticas recomendadas para la recopilación de registros a través de los casos de uso comunes de registro.

Objetivos

En este lab, aprenderás a hacer lo siguiente:

• Usar Cloud Monitoring para detectar problemas
• Usar Cloud Logging para solucionar problemas de una aplicación activa en GKE

La aplicación de demostración que se usa en el lab

Para usar un ejemplo concreto, solucionarás los problemas de una app de demostración de microservicios de muestra implementada a un clúster de GKE. En esta app de demostración, hay muchos microservicios y dependencias entre ellos. Generarás tráfico con un generador de cargas y, luego, usarás Logging, Monitoring y GKE para encontrar el error (alerta o métricas), identificar la causa raíz con Logging y corregir o confirmar que el problema se haya solucionado con Logging y Monitoring.

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, 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 de navegador privada o de Incógnito para ejecutar este lab. Así evitarás cualquier conflicto 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: Si ya tienes un proyecto o una cuenta personal de Google Cloud, no los uses en este lab para evitar cargos adicionales en tu cuenta.

Cómo iniciar su lab y acceder a la consola de Google Cloud

1. Haga clic en el botón Comenzar lab. Si debe pagar por el lab, se abrirá una ventana emergente para que seleccione su forma de pago. A la izquierda, se encuentra el panel Detalles del lab que tiene estos elementos:

   • El botón Abrir la consola de Google
   • Tiempo restante
   • Las credenciales temporales que debe usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haga clic en Abrir la consola de Google. El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.

   Sugerencia: Ordene las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ve el diálogo Elegir una cuenta, haga clic en Usar otra cuenta.

3. Si es necesario, copie el nombre de usuario del panel Detalles del lab y péguelo en el cuadro de diálogo Acceder. Haga clic en Siguiente.

4. Copie la contraseña del panel Detalles del lab y péguela en el cuadro de diálogo de bienvenida. Haga clic en Siguiente.

   Importante: Debe usar las credenciales del panel de la izquierda. No use sus credenciales de Google Cloud Skills Boost. Nota: Usar su propia Cuenta de Google podría generar cargos adicionales.

5. Haga clic para avanzar por las páginas siguientes:

   • Acepte los términos y condiciones.
   • No agregue opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No se registre para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Cloud en esta pestaña.

Nota: Para ver el menú con una lista de los productos y servicios de Google Cloud, haga clic en el Menú de navegación que se encuentra en la parte superior izquierda de la pantalla.

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.

1. Haz clic en Activar Cloud Shell en la parte superior de la consola 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 YOUR_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.

2. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

3. Haz clic en Autorizar.

4. Ahora, el resultado debería verse de la siguiente manera:

Resultado:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = <project_ID>

Resultado de ejemplo:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: Para obtener toda la documentación de gcloud, consulta la guía con la descripción general de gcloud CLI en Google Cloud.

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.

Ejecuta los siguientes comandos de gcloud en la consola de Cloud para establecer la región y la zona predeterminadas de tu lab:

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

Tarea 1: Configura la infraestructura

Conéctate a un clúster de Google Kubernetes Engine y verifica que se haya creado correctamente.

1. Configura la variable del ID del proyecto:

export PROJECT_ID={{{project_0.startup_script.project | Project ID}}}

2. Usa el siguiente comando para ver el estado del clúster:

gcloud container clusters list

El estado del clúster será PROVISIONING.

3. Espera un momento y vuelve a ejecutar el comando anterior hasta que el estado cambie a RUNNING. Esto puede demorar varios minutos.

4. Verifica si se creaste el clúster llamado central.

También puedes supervisar el estado del progreso en la consola de Cloud dirigiéndote a Menú de navegación > Kubernetes Engine > Clústeres.

5. Cuando el estado del clúster sea RUNNING, obtén sus credenciales:

gcloud container clusters get-credentials central --zone $ZONE

Resultado:

Fetching cluster endpoint and auth data. kubeconfig entry generated for central.

7. Verifica si se crearon los nodos:

kubectl get nodes

El resultado debería ser similar al siguiente:

NAME STATUS ROLES AGE VERSION gke-central-default-pool-5ff4130f-qz8v Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-ssd2 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-tz63 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-zfmn Ready 24d v1.27.2-gke.1200

Tarea 2: Implementa la aplicación

A continuación, implementa una aplicación de microservicios llamada Hipster Shop en tu clúster para crear una carga de trabajo que puedas supervisar.

1. Ejecuta el siguiente comando para clonar el repo:

git clone https://github.com/xiangshen-dk/microservices-demo.git

2. Cambia al directorio microservices-demo:

cd microservices-demo

3. Instala la app con kubectl:

kubectl apply -f release/kubernetes-manifests.yaml

4. Confirma que todo se ejecute en forma correcta:

kubectl get pods

El resultado debería ser similar al siguiente:

NAME READY STATUS RESTARTS AGE adservice-55f94cfd9c-4lvml 1/1 Running 0 20m cartservice-6f4946f9b8-6wtff 1/1 Running 2 20m checkoutservice-5688779d8c-l6crl 1/1 Running 0 20m currencyservice-665d6f4569-b4sbm 1/1 Running 0 20m emailservice-684c89bcb8-h48sq 1/1 Running 0 20m frontend-67c8475b7d-vktsn 1/1 Running 0 20m loadgenerator-6d646566db-p422w 1/1 Running 0 20m paymentservice-858d89d64c-hmpkg 1/1 Running 0 20m productcatalogservice-bcd85cb5-d6xp4 1/1 Running 0 20m recommendationservice-685d7d6cd9-pxd9g 1/1 Running 0 20m redis-cart-9b864d47f-c9xc6 1/1 Running 0 20m shippingservice-5948f9fb5c-vndcp 1/1 Running 0 20m

5. Antes de continuar con el paso siguiente, vuelve a ejecutar el comando hasta que todos los Pods tengan el estado Running.

Haz clic en Revisar mi progreso para verificar el objetivo. Implementar la aplicación

6. Ejecuta lo siguiente para obtener la IP externa de la aplicación. Este comando solo mostrará la dirección IP una vez que el servicio se haya implementado, por lo que tal vez necesites repetir el comando hasta que haya una dirección IP externa asignada:

export EXTERNAL_IP=$(kubectl get service frontend-external | awk 'BEGIN { cnt=0; } { cnt+=1; if (cnt > 1) print $4; }')

7. Por último, confirma que la app se esté ejecutando:

curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP

La confirmación se verá de la siguiente manera:

200

Luego de que se haya implementado la aplicación, puedes dirigirte a la consola de Cloud y ver el estado.

En la página de Kubernetes Engine > Cargas de trabajo verás que todos los Pods están correctos.

8. Ahora haz clic en Ingress y servicios, y verifica que todos los servicios estén correctos. Quédate en esta pantalla y configura la supervisión para la aplicación.

Tarea 3. Abre la aplicación

1. Desplázate a frontend-external y haz clic en las IP de los extremos del servicio.

Con esto debería abrirse la aplicación y verse una página como la siguiente:

Tarea 4. Crea una métrica basada en registros

Ahora configurarás Cloud Logging para crear una métrica basada en registros, que es una métrica personalizada en Cloud Monitoring a partir de entradas de registros. Las métricas basadas en registros son útiles para contabilizar el número de entradas de registro y hacer un seguimiento de la distribución de un valor en sus registros. En este caso, usarás la métrica basada en registros para contabilizar el número de errores en tu servicio de frontend. Puedes usar la métrica en los paneles y en las alertas.

1. Vuelve a la consola de Cloud y desde el menú de navegación abre Logging, y haz clic en Explorador de registros (Logs Explorer).

2. Habilita Mostrar consultas y en el cuadro Compilador de consultas agrega la siguiente consulta:

resource.type="k8s_container" severity=ERROR labels."k8s-pod/app": "recommendationservice"

3. Haz clic en Ejecutar consulta (Run Query).

La consulta que estás usando te permite encontrar todos los errores del Pod de frontend. De todos modos, no deberías ver ningún resultado por el momento, ya que aún no hay errores.

4. Para crear las métricas basadas en registros, haz clic en Crear métrica (Create metric).

5. Asigna el nombre Error_Rate_SLI a la métrica y haz clic en Crear métrica (Create metric) para guardar la métrica basada en registros:

Ahora puedes ver la métrica en la lista de métricas definidas por el usuario en la página de métricas basadas en registros.

Haz clic en Revisar mi progreso para verificar el objetivo. Crear una métrica basada en registros

Tarea 5: Crea una política de alertas

Las alertas permiten el reconocimiento oportuno de los problemas en tus aplicaciones de la nube, para que puedas resolverlos con rapidez. Ahora podrás usar Cloud Monitoring para supervisar tu disponibilidad de servicio de frontend creando una política de alertas en función de la métrica basada en registros de errores de frontend que creaste con anterioridad. Cuando se reúnen las condiciones de las políticas de alerta, Cloud Monitoring crea y muestra un incidente en la consola de Cloud.

1. En el menú de navegación, abre Monitoring, y haz clic en Alertas.

2. Luego de que el lugar de trabajo se haya creado, haz clic en Crear política (Create Policy) en la parte superior.

Nota: Si es necesario, haz clic en Pruébalo para usar el flujo actualizado de creación de alertas.

3. Haz clic en el menú desplegable Seleccionar una métrica (Select a metric). Inhabilita la opción Mostrar solo recursos y métricas activos (Show only active resources & metrics).

4. En el campo Filtrar por nombre de recurso y métrica (filter by resource and metric name), escribe Error_Rate.

5. Haz clic en Kubernetes Container > Métricas basadas en registros (Logs-based metrics). Selecciona logging/user/Error_Rate_SLI y haz clic en Aplicar (Apply).

En la pantalla deberías ver lo siguiente:

6. Configura la función de ventana progresiva en Rate.

7. Haz clic en Siguiente.

8. Establece 0.5 como valor del umbral.

Como era de esperar, no se genera ningún error y tu aplicación cumple su objetivo de nivel de servicio (SLO) de disponibilidad.

9. Haz clic en Siguiente otra vez.

10. Inhabilita Usar el canal de notificaciones.

11. Proporciona un nombre de alerta como Error Rate SLI y haz clic en Siguiente.

12. Revisa la alerta y haz clic en Crear política.

Nota: No crearás un canal de notificaciones para este lab, pero deberías hacerlo para tus aplicaciones activas en producción, porque te permite enviar notificaciones por correo electrónico, apps para dispositivos móviles, SMS, Pub/Sub y webhooks.

Haz clic en Revisar mi progreso para verificar el objetivo. Crear una política de alertas

Activa un error de aplicación

Ahora usarás un generador de cargas para crear algo de tráfico para tu aplicación web. Como hay un error que se ingresó en forma intencional en esta versión de la aplicación, cierto volumen de tráfico activará errores. Trabajarás paso a paso para identificar y corregir el error.

1. Desde el Menú de navegación, selecciona Kubernetes Engine, y, luego Ingress y servicios (Services & Ingress).

2. Encuentra el servicio loadgenerator-external, luego haz clic en el vínculo de endpoints.

Como alternativa, puedes abrir una ventana o pestaña nueva del navegador, y copiar y pegar la IP en el campo URL, por ejemplo: http://\[loadgenerator-external-ip\]

Ya deberías estar en la página de generador de carga Locust:

Locust es un generador de cargas de código abierto que te permite cargar una aplicación web de prueba. Puedes simular una cantidad determinada de usuarios que alcanza los extremos de tu aplicación de manera simultánea a una tasa determinada.

1. Simula 300 usuarios usando la app con una tasa de generación de 30. Locust agregará 30 usuarios por segundo hasta que alcance los 300 usuarios.

2. Para el campo de host, usarás frontend-external. Copia la URL de la página de Ingress y servicios, asegúrate de excluir el puerto. Por ejemplo:

3. Haz clic en el botón Start swarming. Deberías tener cerca de 300 usuarios para alcanzar las URL predefinidas en pocos segundos.

4. Haz clic en la pestaña Failures para ver los errores que comienzan a aparecer. Puedes ver que hay una gran cantidad del error 500.

Mientras tanto, si haces clic en algún producto de la página principal, verás que está muy lenta o que recibes errores como el siguiente si haces clic en un producto:

Confirma las alertas y los errores de aplicación

1. En la consola de Cloud, desde el Menú de navegación, haz clic en Monitoring y luego en Alertas (Alerting). Deberías ver un incidente de logging/user/Error_Rate_SLI. Si no ves un incidente en el momento, espera un minuto o dos y actualiza la página. Puede tomar hasta 5 minutos que la alerta se active.

2. Haz clic en el vínculo del incidente:

Esto te llevará a la página de detalles.

3. Haz clic en el vínculo de VER REGISTROS (VIEW LOGS) para ver los registros del Pod.

4. También puedes hacer clic en la etiqueta Error en el campo Logs para consultar solo los errores.

Como alternativa, puedes hacer clic en el campo de vista previa de búsquedas para ver el compilador de consultas, luego haz clic en Gravedad en el menú desplegable y agrega Error a la búsqueda. Haz clic en el botón Agregar y luego haz clic en Ejecutar consulta (Run Query). El menú desplegable permite agregar varios valores de intensidad.

El resultado agregará severity=ERROR a tu consulta. Una vez que hayas hecho esto, debes tener todos los errores del Pod recommendationservice.

5. Revisa los detalles de los errores expandiendo un evento de error. Por ejemplo:

6. Expande textPayload.

7. Haz clic en el mensaje de error y elige Agregar campo a la línea de resumen (Add field to summary line) para que los mensajes de error aparezcan como un campo de resumen:

Desde ahí puedes confirmar que hay muchos errores del servicio para el servicio recommendationservice. Basado en los mensajes de error, parece que recommendationservice no se pudo conectar a algún servicio para conseguir productos o recomendaciones. De cualquier manera, aún no está claro cuál es la causa raíz de los errores.

Si vuelves a consultar el diagrama de arquitectura, recommendationservice provee una lista de recomendaciones del servicio de frontend. Sin embargo, tanto el servicio de frontend como el de recommendationservice invocan ProductCatalogService para la lista de productos.

Para el próximo paso, examinarás las métricas de la fuente más probable de los problemas, ProductCatalogService, en busca de anomalías. Sin embargo, puedes desglosar los registros para ver estadísticas.

Soluciona problemas con el panel y los registros de Kubernetes

1. Uno de los primeros lugares en donde puedes ver las métricas es en la sección Kubernetes Engine de la consola de Monitoring (Menú de navegación > Monitoring> Paneles > GKE).

2. Consulta la sección Cargas de trabajo (Workloads).

3. Navega hacia Kubernetes Engine > Cargas de trabajo (Workloads) > productcatalogservice. Puedes ver que el Pod del servicio falla y se reinicia de forma constante.

A continuación, observa si hay algo interesante en los registros.

Hay dos modos de llegar con facilidad a tus registros de contenedores:

1. Haz clic en la pestaña Registros (Logs) para obtener una vista rápida de los registros más recientes. Luego, haz clic en el botón de vínculo externo en la esquina superior derecha del panel de registros para volver al Explorador de registros.

2. En la página de resumen, haz clic en el vínculo Registros de contenedores (Container logs) de la página Detalles de la implementación.

Estás en la página Explorador de registros otra vez, ahora con una consulta predefinida filtrada de forma específica para los registros del contenedor que estuviste viendo en GKE.

Desde el visor de registros, tanto los mensajes de registro como el histograma muestran que el contenedor analiza en forma repetida el catálogo de productos en un corto período. Parece ser muy ineficiente.

En la parte inferior de los resultados de las consultas, puede haber un error de entorno de ejecución como el siguiente:

panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation

Esto podría ser la causa de que el Pod falle.

Para entender mejor la razón, busca el mensaje de registro en el código.

1. En Cloud Shell, ejecuta el siguiente comando:

grep -nri 'successfully parsed product catalog json' src

Tu resultado debería verse como el siguiente, que tiene el nombre del archivo fuente con un número de línea:

src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")

2. Para ver el archivo fuente, haz clic en el botón Abrir editor (Open Editor) del menú de Cloud Shell y, luego, en Abrir en una ventana nueva. (Si ves el error No se puede cargar el editor de códigos porque las cookies de terceros no están habilitadas, haz clic en el ojo en la parte superior de la página de Chrome).

3. Haz clic en el archivo microservices-demo/src/productcatalogservice/server.go, desplázate hasta la línea 237 y encontrarás los registros de método de readCatalogFile con este mensaje:

Con un poco más de esfuerzo puedes ver que la variable booleana reloadCatalog es verdadera y que el servicio vuelve a cargar y analizar el catálogo de productos cada vez que se lo invoca, lo que parece innecesario.

Si buscas en el código la variable reloadCatalog, puedes ver que está controlado por la variable de entorno ENABLE\_RELOAD y escribe un mensaje de registro para su estado.

Revisa de nuevo los registros, agrega este mensaje a tu consulta y determina si hay alguna entrada existente.

1. Vuelve a la pestaña donde tienes abierto el Explorador de registros y agrega la siguiente línea a la consulta:

jsonPayload.message:"catalog reloading"

La consulta completa en tu compilador de consultas será la siguiente:

resource.type="k8s_container" resource.labels.location="{{{project_0.startup_script.zone | ZONE}}}" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

2. Haz clic en Ejecutar consulta una vez más y encontrarás el mensaje "Enable catalog reloading" en el registro contenedor. Esto confirma que la función de volver a cargar el catálogo está habilitada.

En este punto, puedes tener la certeza de que el error es causado por la sobrecarga de volver a cargar el catálogo en cada solicitud. Cuando aumentaste la carga, la sobrecarga hizo que el servicio falle y se genere el error.

Tarea 6. Corrige el problema y verifica el resultado

Sobre la base del código y en lo que ves en los registros, puedes intentar corregir el problema inhabilitando que el catálogo se vuelva a cargar. Ahora quitarás la variable de entorno ENABLE_RELOAD del servicio de catálogo de productos. Una vez que realices los cambios de variante, puedes volver a implementar la aplicación y verificar que los cambios hayan solucionado el problema en cuestión.

1. Haz clic en el botón Abrir terminal para volver a la terminal de Cloud Shell si se ha cerrado.

2. Ejecuta el siguiente comando:

grep -A1 -ni ENABLE_RELOAD release/kubernetes-manifests.yaml

El resultado mostrará el número de línea de la variable de entorno en el archivo de manifiesto:

373: - name: ENABLE_RELOAD 374- value: "1"

3. Borra esas dos líneas para inhabilitar que se vuelva a cargar cuando ejecutes lo siguiente:

sed -i -e '373,374d' release/kubernetes-manifests.yaml

4. Luego vuelve a aplicar el archivo de manifiesto:

kubectl apply -f release/kubernetes-manifests.yaml

Notarás que el productcatalogservice está configurado. Los demás servicios no han cambiado.

5. Regresa a la página de detalles de la implementación (Menú de navegación > Kubernetes Engine > Cargas de trabajo > productcatalogservice), y espere hasta que el Pod se ejecute de manera exitosa. Espera de 2 a 3 minutos o hasta que puedas confirmar que dejó de fallar.

6. Si haces clic en el vínculo de Registros de contenedores otra vez, verás que los mensajes repetidos de successfully parsing the catalog json (análisis exitoso de catálogo json) han desaparecido:

7. Si te diriges de nuevo a la URL de la app web y haces clic en los productos de la página principal, es mucho más responsiva y no deberías encontrar ningún error de HTTP.

8. Vuelve al generador de carga, haz clic en el botón Reset Stats en la parte superior derecha. El porcentaje de fallas se restablece y no deberías ver que se incremente más.

Todo lo anterior indica que el problema se corrigió. Si aún ves el error 500, espera unos minutos más e intenta hacer clic en un producto otra vez.

Felicitaciones

Usaste Cloud Logging y Cloud Monitoring para encontrar un error en una versión mal configurada de manera intencional de la app de demostración de microservicios. Este es un proceso de solución de problemas similar al que usarías para reducir problemas de tus aplicaciones de GKE en un entorno de producción.

Primero, implementaste la app en GKE y configuraste una métrica y una alerta para errores de frontend. Luego generaste una carga y notaste que la alerta se activaba. Desde la alerta, redujiste el problema a servicios particulares con Cloud Logging. Luego, usaste Cloud Monitoring y la IU de GKE para observar las métricas de los servicios GKE. Para solucionar el problema, luego implementaste una configuración actualizada en GKE y confirmaste que la corrección solucionaba los errores en los registros.

Finaliza la Quest

Este lab de autoaprendizaje forma parte de la Quest Google Cloud's Operations Suite on GKE. Una Quest es una serie de labs relacionados que forman una ruta de aprendizaje. Si completas esta Quest, obtendrás una insignia como reconocimiento por tu logro. Puedes hacer públicas tus insignias y agregar vínculos a ellas en tu currículum en línea o en tus cuentas de redes sociales. Inscríbete en esta Quest y obtén un crédito inmediato de realización. Consulta el catálogo de Google Cloud Skills Boost para ver todas las Quests disponibles.

Realiza tu próximo lab

Continúa tu Quest con Cloud Logging en Kubernetes Engine o consulta estas sugerencias:

• Cloud Operations para GKE
• Usa la herramienta de APM de Cloud Monitoring para solucionar problemas relacionados con la confiabilidad de sitios

Próximos pasos/Más información

• Este lab se basa en esta entrada de blog sobre cómo usar Logging para tus aplicaciones ejecutadas en GKE.
• La publicación de seguimiento sobre cómo los equipos de DevOps pueden usar Cloud Monitoring y Logging para detectar problemas con rapidez también puede ser de tu interés.

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 31 de julio de 2023

Prueba más reciente del lab: 31 de julio de 2023

Copyright 2024 Google LLC. All rights reserved. Google y el logotipo de Google son marcas de Google LLC. Los demás nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que estén asociados.