docs: document credentials_base64 and add Google Cloud Storage monitoring guide

[AvilaJulio]

Problem

Google Cloud Storage is listed as a supported sink on the Monitoring Integrations page, but the docs never explain how to authenticate it.

The gcp_cloud_storage sink reads a service account key from a file path (credentials_path), and falls back to GOOGLE_APPLICATION_CREDENTIALS or the instance service account. None of those are actionable for a customer: you can't upload a file to a deployment, and the Vector agent runs in Cube's infrastructure, so the instance service account isn't in the customer's GCP project.

The supported mechanism — the credentials_base64 sink option — was undocumented, so the feature was effectively undiscoverable. This came up in a customer question that also surfaced a related misconception: that the BigQuery data source service account is reused for log export.

Changes

New page — admin/monitoring/monitoring-integrations/gcs.mdx, following the structure of the existing S3 and CloudWatch guides: service account setup, log export, Query History export, and troubleshooting.

Overview page — new Credentials files section documenting credentials_base64 generically, since the option is sink-agnostic (only credentials_path is GCP-specific). It accepts a Base64-encoded JSON credentials file, either inline or as a $CUBE_CLOUD_MONITORING_* environment variable reference, and is mounted into the Vector agent at /etc/credentials/<sink name>.json.

Also documented, because both generate support tickets:

• Sinks using credentials_base64 must be named with lowercase letters, numbers, and dashes only — the sink name becomes a Kubernetes object name, so [sinks.gcp_cloud_storage] silently fails.
• Sinks authenticate independently from data sources. A BigQuery service account is never reused for log export.

Navigation — registered in docs.json and added a card to the overview card group.

Verification

• docs.json parses as valid JSON; the diff is a single added line.
• scripts/check_links.py reports no broken links in either changed file. (It reports many pre-existing failures elsewhere in the repo, unrelated to this change.)
• No legacy Nextra components; Mintlify components only.
• Anchor targets (#credentials-files, #query-history-export, #environment-variables) verified to exist.

Behavior documented here was read off the credentials_base64 handling in the Cube Cloud operator rather than inferred, including the accepted value forms, the JSON validation step, the mount path, and the sink naming constraint.

🤖 Generated with Claude Code