arrow_back

Depuración de aplicaciones en Google Kubernetes Engine

Unirse Acceder

Depuración de aplicaciones en Google Kubernetes Engine

1 hora 15 minutos 5 créditos

GSP736

Labs de autoaprendizaje de Google Cloud

Introducción

Cloud Logging, y su herramienta complementaria, Cloud Monitoring, son productos destacados y bien integrados a Google Kubernetes Engine. Este lab le 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.

Qué aprenderá

  • Cómo usar Cloud Monitoring para detectar problemas

  • Cómo 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á los problemas de una aplicación de demostración de microservicio de muestra implementada a un clúster de GKE. En esta aplicación de demostración hay muchos microservicios y dependencias entre ellos. Generará tráfico con un generador de cargas y luego usará Logging, Monitoring y GKE para encontrar el error (alerta/métricas), identificar la causa raíz con Logging y corregir o confirmar que el problema se haya solucionado con Logging y Monitoring.

f5227a639be42af5.png

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lea estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, que comienza a funcionar cuando hace clic en Comenzar lab, indica por cuánto tiempo tendrá a su disposición los recursos de Google Cloud.

Este lab práctico de Qwiklabs le permitirá llevar a cabo las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, le proporciona credenciales temporales nuevas que utilizará para acceder a Google Cloud durante todo el lab.

Qué necesita

Para completar este lab, necesitará lo siguiente:

  • Acceso a un navegador de Internet estándar (se recomienda el navegador Chrome)
  • Tiempo para completar el lab

Nota: Si ya tiene un proyecto o una cuenta personal de Google Cloud, no los use para este lab.

Nota: Si usa un dispositivo con Chrome OS, ejecute este lab en una ventana de incógnito.

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. Ícono del menú de navegación

Active Google Cloud Shell

Google Cloud Shell es una máquina virtual que cuenta con herramientas de desarrollo. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Google Cloud Shell proporciona acceso de línea de comandos a sus recursos de GCP.

  1. En GCP Console, en la barra de herramientas superior derecha, haga clic en el botón Abrir Cloud Shell.

    Ícono de Cloud Shell

  2. Haga clic en Continue (Continuar):

    cloudshell_continue

Toma unos minutos aprovisionar y conectarse con el entorno. Cuando está conectado, ya está autenticado y el proyecto está configurado en su PROJECT_ID . Por ejemplo:

Terminal de Cloud Shell

gcloud es la herramienta de línea de comandos para Google Cloud Platform. Viene preinstalada en Cloud Shell y es compatible con la función “tab-completion”.

Puede mostrar el nombre de la cuenta activa con este comando:

gcloud auth list

Resultado:

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

Puede mostrar el ID del proyecto con este comando:

gcloud config list project
	

Resultado:

[core]
project = <project_ID>
	

Resultado de ejemplo:

[core]
project = qwiklabs-gcp-44776a13dea667a6
	

Configuración de la infraestructura

Conéctese a un clúster de Google Kubernetes Engine y verifique que se haya creado en forma correcta.

En Cloud Shell, establezca la zona en gcloud:

gcloud config set compute/zone us-central1-b

Configure la variante del ID del proyecto:

export PROJECT_ID=$(gcloud info --format='value(config.project)')

Use el siguiente comando para ver el estado del clúster:

gcloud container clusters list

El estado del clúster será APROVISIONANDO. Espere un momento y vuelva a ejecutar el comando anterior hasta que el estado cambie a EN EJECUCIÓN. Esto puede demorar varios minutos. Verifique si se creó el clúster llamado central.

También puede supervisar el estado del progreso en Cloud Console dirigiéndose a Menú de navegación > Kubernetes Engine > Clústeres.

Cuando el estado de su clúster sea EN EJECUCIÓN, obtenga sus credenciales:

gcloud container clusters get-credentials central --zone us-central1-b

(Resultado)

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

Verifique 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 <none> 24d v1.16.13-gke.1 gke-central-default--pool-5ff4130f-ssd2 Ready <none> 24d v1.16.13-gke.1 gke-central-default--pool-5ff4130f-tz63 Ready <none> 24d v1.16.13-gke.1 gke-central-default--pool-5ff4130f-zfmn Ready <none> 24d v1.16.13-gke.1

Implemente la aplicación

Luego, implemente una aplicación de microservicios llamada Hipster Shop a su clúster a fin de crear una carga de trabajo para supervisar.

Ejecute el siguiente comando para clonar el repositorio:

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

Cambie al directorio microservices-demo:

cd microservices-demo

Instale la aplicación con kubectl:

kubectl apply -f release/kubernetes-manifests.yaml

Confirme que todo se ejecute en forma correcta:

kubectl get pods

El resultado debería ser similar al siguiente: Vuelva a ejecutar el comando hasta que todos los Pods tengan el estado En ejecución antes de continuar con el siguiente paso.

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

Haga clic en Revisar mi progreso para verificar el objetivo. Implemente la aplicación

Ejecute 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 necesite repetir el comando hasta que haya una IP externa asignada:

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

Por último, confirme que la aplicación se esté ejecutando:

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

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

200

Luego de que se haya implementado la aplicación, puede dirigirse a Cloud Console y ver el estado.

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

4699e006d643e0cb.png

Ahora haga clic en Ingress y servicios (Services & Ingress), y verifique que todos los servicios estén correctos. Quédese en esta pantalla a fin de configurar la supervisión para la aplicación.

Abra la aplicación

Desplácese a frontend-external y haga clic en los IP de los extremos del servicio.

3ceac1fa2e6341fd.png

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

c27b929771780db0.png

Cree una métrica basada en registros

Ahora configurará 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 buenas 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á la métrica basada en registros para contabilizar el número de errores en su servicio de frontend. Puede usar la métrica en los paneles y en las alertas.

Vuelva a Cloud Console y desde el menú de navegación abra Logging, y haga clic en Explorador de registros (Logs Explorer).

logging.png

En el cuadro Compilador de consultas (Query builder), agregue la siguiente consulta:

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

queryBuilder.png

Haga clic en Ejecutar consulta (Run Query).

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

Para crear las métricas basadas en registros, haga clic en Crear métrica (Create Metric).

create_metric.png

Asigne el nombre Error_Rate_SLI a la métrica y haga clic en Crear métrica (Create Metric) para guardar la métrica basada en registros:

8c94ae5ec9394f52.png

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

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

Cree una política de alertas

Las alertas permiten el reconocimiento oportuno de los problemas en sus aplicaciones de la nube, a fin de que pueda resolverlos con rapidez. Ahora podrá usar Cloud Monitoring para supervisar su disponibilidad de servicio de frontend, creando una política de alertas con base en la métrica basada en registros de errores de frontend que creó con anterioridad. Cuando se reúnen las condiciones de las políticas de alerta, Cloud Monitoring crea y muestra un incidente en la Cloud Console.

En el menú de navegación, abra Monitoring, haga clic en Alertas.

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

Nota: Si es necesario, haga clic en ¡Probar! para usar el flujo actualizado de creación de alertas.

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

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

Haga clic en Contenedor de Kubernetes > Métrica basada en registros (Kubernetes Container > Logs-Based Metric). Seleccione logging/user/Error_Rate_SLI y haga clic en Aplicar (Apply).

En la pantalla debería ver lo siguiente:

create_policy.png

Configure la función analítica consecutiva en Rate.

Haga clic en Siguiente.

Establezca 0.5 como valor del umbral.

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

Haga clic en Siguiente otra vez.

Inhabilite Usar el canal de notificaciones. Proporcione un nombre de alerta como SLI de la tasa de error y haga clic en Siguiente.

Revise la alerta y haga clic en Crear política.

Nota: No creará un canal de notificaciones para este lab, pero deberá hacerlo para sus aplicaciones activas en producción, lo que le permite enviar notificaciones por correo electrónico, apps para dispositivos móviles, SMS, Pub/Sub y webhooks.

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

Active un error de aplicación

Ahora usará un generador de cargas a fin de crear algo de tráfico para su 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á paso a paso para identificar y corregir el error.

Desde el Menú de navegación, seleccione Kubernetes Engine, y, luego Ingress y servicios (Service & Ingress).

Encuentre el servicio loadgenerator-external, luego haga clic en el vínculo de extremos.

31ec23d3f5d42e8e.png

Como alternativa, puede 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ía estar en la página de generador de carga Locust:

16853817b5cba2ca.png

Locust es un generador de cargas de código abierto que le permite cargar una aplicación web de prueba. Puede simular cierta cantidad de usuarios de manera simultánea y presionar los extremos de su aplicación a cierta tasa.

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

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

90d88d8c7bcd809c.png

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

fc400e03937ef0fa.png

Haga clic en la pestaña Failures para ver los errores que comienzan a aparecer. Puede ver que hay un gran número de 500 errores.

bb15983ca59467a4.png

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

907b0b1ffeb28f49.png

Confirme las alertas y los errores de aplicación

En Cloud Console, desde el Menú de navegación, haga clic en Monitoring, y luego en Alertas (Alerting). Debería ver un incidente de logging/user/Error_Rate_SLI. Si no ve un incidente en el momento, espere un minuto o dos y actualice su página. Puede tomar hasta 5 minutos que la alerta se active.

Haga clic en el vínculo del incidente:

incidents.png

Esto le llevará a la página de detalles. Haga clic en el vínculo de Ver registros (View logs) para ver los registros del Pod.

incident_details.png

También puede hacer clic en la etiqueta Error en el panel de registro para consultar solo los errores.

Como alternativa, puede hacer clic en el campo de vista previa de consultas a fin de ver el compilador de consultas, luego haga clic en Gravedad en el menú desplegable, agregue Error a la consulta. Haga clic en el botón Agregar y luego haga clic en Ejecutar consulta (Run Query). El menú desplegable permite agregar varios valores de intensidad.

El resultado agregará severity=ERROR a su consulta. Una vez que haya hecho esto, debe tener todos los errores del Pod recommendationservice.

266b24ced4e1f7e8.png

Vea los detalles de los errores cuando expanda un evento de error. Por ejemplo:

c9c267cc1865d963.png

Expanda el textPayload. Haga clic en el mensaje de error y seleccione Agregar campo a línea de resumen (Add field to summary line) para que los mensajes de error aparezcan como un campo de resumen:

94adf8d4717a0b3e.png

Desde ahí puede 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 todos modos, aún no está claro cuál es la causa raíz de los errores.

900dcc7807b9044d.png

Si vuelve a consultar el diagrama de arquitectura, el recommendationservice provee una lista de recomendaciones del servicio de frontend. De todos modos. tanto el servicio de frontend como el de recommendationservice invocan ProductCatalogService para la lista de productos.

ca416c3d4491bb07.png

Para el próximo paso, verá las métricas del sospechoso principal, ProductCatalogService, para cualquier anomalía. Sin embargo, puede desglosar los registros para ver estadísticas.

Solucione problemas con el panel y los registros de Kubernetes

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

Consulte la sección de Cargas de trabajo (Workloads).

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

ccf430faaf71a1f1.png

A continuación, vea si hay algo interesante en sus registros.

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

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

GKE-OiC.png

  1. En la página de resumen, haga clic en el vínculo Registros de contenedor (Registros de contenedor) de la página de detalles de implementación.

c0c3d037c56b6379.png

Usted está en la página Explorador de registros otra vez, ahora con una consulta predefinida de forma específica filtrada para los registros del contenedor que estuvo 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.

2535e56aae8ea188.png

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, busque el mensaje de registro en el código.

En Cloud Shell, ejecute el siguiente comando:

grep -nri 'successfully parsed product catalog json' src

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

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

Para ver el archivo fuente, haga clic en el botón Abrir editor (Open Editor) del menú de Cloud Shell, y luego en Open in New Window. (Si ve el error No se puede cargar la página porque las cookies de terceros están inhabilitadas, haga clic en el ojo en la parte superior de la página de Chrome).

a3250c575390919d.png

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

93c9981272a13ab4.png

Con un poco más de esfuerzo puede 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 busca la variable reloadCatalog en el código, puede ver que está controlado por la variable de entorno ENABLE\_RELOAD y escribe un mensaje de registro para su estado.

cf7083d2031e533.png

Revise de nuevo los registros, agregue este mensaje a su consulta y determine si hay alguna entrada existente.

Vuelva a la pestaña donde tiene abierto el Explorador de registros y agregue la siguiente línea a la consulta:

jsonPayload.message:"catalog reloading"

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

resource.type="k8s_container" resource.labels.location="us-central1-b" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

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

b6c5202d81c2f1cb.png

En este punto, se puede estar seguro de que el error es causado por la sobrecarga de volver a cargar el catálogo en cada solicitud. Cuando aumentó la carga, la sobrecarga hizo que el servicio falle y se genere el error.

Corrija el problema y verifique el resultado

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

Haga clic en el botón Open terminal para volver a la terminal de Cloud Shell si se ha cerrado.

Ejecute 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"

Borre esas dos líneas para inhabilitar la recarga cuando ejecute lo siguiente:

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

Luego vuelva a aplicar el archivo de manifiesto:

kubectl apply -f release/kubernetes-manifests.yaml

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

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

a5ec7a95d8b4c404.png

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

743fb0a69ccb98e2.png

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

Vuelva al generador de cargas, haga clic en el botón Reset Stats en la parte superior derecha. El porcentaje de fallas se restablece y no debería ver que se incremente más.

213688aa3238649f.png

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

Felicitaciones

Usted ha usado 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ía para reducir problemas de sus aplicaciones de GKE en un entorno de producción.

Primero, implementó la aplicación a GKE y configuró una métrica y una alerta para errores de frontend. Luego generó cargas y notó que la alerta se activaba. Desde la alerta, redujo el problema a servicios particulares con Cloud Logging. Luego, usó Cloud Monitoring y la IU de GKE para observar las métricas de los servicios GKE. A fin de solucionar el problema, luego implementó una configuración actualizada en GKE y confirmó que la corrección solucionaba los errores en los registros.

CloudOpsGKE_125x135.png

Finalice su Quest

Este lab de autoaprendizaje forma parte de la Quest de Qwiklabs Google Cloud's Operations Suite on GKE. Una Quest es una serie de labs relacionados que forman una ruta de aprendizaje. Si completa esta Quest, obtendrá la insignia que se muestra arriba como reconocimiento de su logro. Puede hacer públicas sus insignias y agregar vínculos a ellas en su currículum en línea o en sus cuentas de redes sociales. Inscríbase en una Quest y obtenga un crédito inmediato de finalización si ha realizado este lab. Consulte por otras Quests de Qwiklabs disponibles.

Realice su próximo lab

Continúe su Quest con Cloud Logging en Kubernetes Engine o consulte estas sugerencias:

Próximos pasos/Más información

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

Google Cloud Training & Certification

Aproveche al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarlo a ponerse en marcha rápidamente y a seguir aprendiendo. Para que pueda realizar nuestros cursos cuando más le convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: según demanda, presenciales y virtuales. Las certificaciones lo ayudan a validar y demostrar sus habilidades y experiencia en las tecnologías de Google Cloud.

Última actualización del manual: 14 de abril de 2022
Prueba más reciente del lab: 14 de abril de 2022

Copyright 2020 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.