Cloud Monitoring

Cloud Monitoring recoge, guarda y analiza métricas. Las de la mayoría de los servicios de Google Cloud se recogen automáticamente, sin instalar nada.

Las consultas de gráficos y alertas se crean con menús, con PromQL o con expresiones de filtro de Monitoring. Metrics Explorer permite explorar series temporales rápidamente y guardar los gráficos en un panel.

Metrics scope: varios proyectos

Por defecto, un proyecto solo ve sus propias métricas. El metrics scope define qué proyectos (y cuentas de AWS) puede ver y monitorizar un proyecto. El proyecto que lo aloja es el proyecto de alcance (scoping project), y en él se guardan las políticas de alertas, las comprobaciones de disponibilidad, los paneles y los grupos.

Políticas de alertas

Una política de alertas describe cuándo avisar y a quién. Cuando los datos cumplen la condición, Monitoring crea una alerta (un registro persistente con el estado, enlaces a logs y un gráfico) y envía las notificaciones. Si la condición deja de cumplirse, cierra la alerta y lo notifica.

• Cada política tiene una condición, una lista de canales de notificación y una documentación opcional que aparece en la notificación (por ejemplo, un enlace al runbook).
• Las integraciones (GKE, Compute Engine, Cloud SQL…) ofrecen alertas recomendadas ya configuradas: solo eliges el canal.
• Una política no se puede limitar a ciertos horarios. Para pausarla en un mantenimiento se crea un snooze.
• Con gcloud las políticas se crean a partir de un archivo JSON con su definición.

gcloud monitoring snoozes create --display-name="Maintenance Week" \
  --criteria-policies="projects/my-project/alertPolicies/12345" \
  --start-time="2026-11-01T03:00:00Z" --end-time="2026-11-01T07:00:00Z"

Canales de notificación

Correo electrónico, Cloud Mobile App, PagerDuty, SMS, Slack, webhooks y Pub/Sub. Una política puede tener varios canales.

• Google recomienda varios tipos de canal por redundancia. Mobile App, PagerDuty, webhooks y Slack comparten el mismo servicio interno; si usas uno, añade correo o Pub/Sub como respaldo.
• SMS no es totalmente fiable: úsalo siempre con otro canal.
• Para automatizar acciones a partir de las notificaciones, usa webhooks o Pub/Sub; el formato de los demás puede cambiar.

Métricas personalizadas y basadas en logs

gcloud logging metrics create high_severity_count \
  --description="Number of high severity log entries" \
  --log-filter="severity > WARNING"

Las métricas basadas en logs definidas por el usuario se calculan también con los logs excluidos; las del sistema, solo con los incluidos.

Ops Agent

Es el agente principal para recoger telemetría de las VMs de Compute Engine: logs, métricas y trazas en un solo proceso. Usa Fluent Bit para los logs y OpenTelemetry Collector para métricas y trazas. Se configura con un archivo YAML.

• Sin configurar nada recoge los logs del sistema (syslog, Windows Event Log) y métricas como CPU, disco, memoria, swap, red y procesos.
• Integraciones con aplicaciones de terceros, métricas de Prometheus, métricas y trazas OTLP y métricas de GPU NVIDIA (DCGM).
• Usa la cuenta de servicio de la VM, que necesita roles/logging.logWriter y roles/monitoring.metricWriter. Hay que tener habilitadas las APIs de Cloud Logging y Cloud Monitoring.
• No debe convivir con los agentes heredados de Logging o Monitoring (duplicaría datos).
• Con políticas de agentes se instala en toda una flota de VMs Linux, nuevas y existentes, con un solo comando.
• No se admite en instancias EC2 de AWS ni en máquinas on-premises.

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

Managed Service for Prometheus

Servicio gestionado y multicloud para métricas de Prometheus y OpenTelemetry, sin operar servidores Prometheus. Se consulta con PromQL, así que siguen sirviendo los paneles de Grafana y las alertas existentes. Usa el mismo backend que Cloud Monitoring (Monarch) y guarda los datos 24 meses sin coste adicional.

En Cloud Run se usa un sidecar de Prometheus u OpenTelemetry.

Comprobaciones de disponibilidad y paneles

Las comprobaciones de disponibilidad públicas (uptime checks) envían peticiones HTTP, HTTPS o TCP periódicas desde varias ubicaciones del mundo a una URL, una VM, una app de App Engine, un servicio de Kubernetes, una revisión de Cloud Run o una instancia EC2. Al crearlas puedes añadir una política de alertas. Para recursos en una red privada están las comprobaciones privadas.

• No cargan recursos de la página ni ejecutan JavaScript, y por defecto no se autentican.
• Si el recurso está detrás de un firewall, hay que permitir las IP de los servidores de comprobación.
• Rol en la consola: roles/monitoring.editor.

Google Cloud crea paneles gestionados automáticamente para los recursos. Los paneles personalizados muestran gráficos de métricas, logs, grupos de errores, alertas, texto y eventos; se pueden importar desde Grafana o instalar desde plantillas.

Gemini Cloud Assist y Active Assist

Escenarios de examen

Trampas frecuentes del examen