Monitor Google Cloud with Sazabi

Last verified on Nov 8, 2026.

Google Cloud writes two kinds of records you care about. The first is what your workloads print: Cloud Run requests, Cloud Functions output, GKE container logs. The second is what happened to the cloud itself: who changed an IAM policy, which service account created a VM, which request was denied. Both go to Cloud Logging, and neither is much use when it sits in a project nobody is looking at.

Sazabi is AI-native observability and security. It reads Cloud Logging entries through Pub/Sub, so application logs and audit logs from several projects land in one place you can ask questions of.

What each source sends

Logs travel one way: a Cloud Logging sink routes entries to a Pub/Sub topic, and a pull subscription feeds Sazabi. The connected-account path provisions that for you with a service account key. Each project stream forwards every log entry in the project, Cloud Audit Logs included. The manual path has you build the sink and topic and run an OpenTelemetry Collector using the googlecloudpubsub receiver with the googlecloudlogentry_encoding extension. Neither path forwards Cloud Monitoring metrics or traces.

Audit logs get their own stream type. An organization or folder stream creates one aggregated sink with the children included, routing only Cloud Audit Logs: Admin Activity, Data Access, System Event and Policy Denied. Google documents the same four types for every project, folder and organization, and says an audit entry is a LogEntry whose protoPayload holds an AuditLog object (Google Cloud: Audit logs). Sazabi exposes these as searchable attributes:

• gcp.audit.method_name, gcp.audit.service_name and gcp.audit.resource_name
• gcp.audit.principal_email, gcp.audit.caller_ip and gcp.audit.user_agent
• gcp.audit.authorization_granted and gcp.audit.status_code
• gcp.log_name and gcp.insert_id

The agent has two more routes in. The MCP connector points at Google's per-product servers, with Cloud Logging as the default and Cloud Monitoring and BigQuery as alternatives, using a short-lived OAuth 2.0 access token. The gcloud CLI connection adds gcloud, gsutil and bq to the sandbox.

Questions it answers

• Who changed this IAM policy, from which address, and was it authorized?
• Which service account created or deleted resources in the last day?
• Did a Cloud Run revision start logging errors right after a deploy?
• Which requests were denied by policy, and for which principal?
• Which projects are forwarding, and which have gone quiet?

A worked example: tracing an IAM change

Say a service account gained a role it should not have. The audit entry for it is an Admin Activity record, and Sazabi keeps the fields you need as attributes. A made-up example of what you would read:

{
  "gcp.log_name": "projects/example-prod/logs/cloudaudit.googleapis.com%2Factivity",
  "gcp.audit.service_name": "cloudresourcemanager.googleapis.com",
  "gcp.audit.method_name": "SetIamPolicy",
  "gcp.audit.principal_email": "deploy-bot@example-prod.iam.gserviceaccount.com",
  "gcp.audit.caller_ip": "203.0.113.57",
  "gcp.audit.resource_name": "projects/example-prod",
  "gcp.audit.authorization_granted": true,
  "gcp.audit.status_code": 0
}

The last part of gcp.log_name says this is an Admin Activity entry, so it records a configuration change and not a read. The principal is a service account, and authorization_granted is true, so IAM allowed it. Ask the agent for the surrounding story:

sazabi logs ask "Show gcp.audit.method_name SetIamPolicy entries in the last 24 hours with principal_email, caller_ip and resource_name"

Next, look at what else that principal did in the same window. If a CI service account is calling SetIamPolicy from an address that is not your CI, that is the thing to chase. If the address is your CI and the call matches a deploy, the change was expected and you can review the role it granted.

What you pay for on the Google side

Google Cloud bills for Pub/Sub delivery and egress, and Sazabi does not. Sink filters decide the volume, and Google lets an aggregated sink filter run up to 20,000 characters, with up to 50 exclusion filters per sink (Google Cloud: Aggregated sinks). Data Access audit logs are off by default, except for BigQuery, and can be very high volume. If you add an organization stream and also project streams beneath it, Sazabi receives those projects' audit entries from both.

How it fits with other integrations

If your workloads run on another cloud, AWS covers the same role for CloudTrail and CloudWatch, and Cloudflare covers the edge in front of either. The collector route uses the OpenTelemetry integration. See cloud platforms for the full group and security for tools that produce audit data. For plans, see pricing.