Logging monitoring
Skill jpantsjoha/googlecloud-plugin/skills/logging-monitoring
Configure observability on GCP using Cloud Logging, Cloud Monitoring, Cloud Trace, and Cloud Profiler. Covers log sinks, log-based metrics, alerting policies, dashboards, and uptime checks. Owns the operational readiness evidence for gcp-ops. Use when the user mentions: logging setup, monitoring setup, alerting policy, dashboard GCP, error reporting, SLO monitoring. Use this to configure the observability resources themselves; use gcp-ops instead for SLO targets, runbooks and release gating.From its SKILL.md
npx -y skills add jpantsjoha/googlecloud-plugin --skill logging-monitoringAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.9 KB, as published. Nobody here has run it
Logging + Monitoring
Full observability stack for GCP workloads: Cloud Logging, Cloud Monitoring, Cloud Trace, and Cloud Profiler.
Core Patterns
Create a log sink (export to BigQuery for long-term retention)
gcloud logging sinks create SINK_NAME \
bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET \
--log-filter='resource.type="cloud_run_revision"' \
--project=PROJECT_ID
Create a log-based metric (count errors)
gcloud logging metrics create error-rate \
--description="Count of ERROR log entries" \
--log-filter='severity=ERROR' \
--project=PROJECT_ID
Create an alerting policy (notify on error spike)
# Best done via Terraform or Console for complex conditions
# CLI example for uptime check failure:
gcloud alpha monitoring policies create \
--policy-from-file=alerting-policy.json \
--project=PROJECT_ID
Uptime check
gcloud monitoring uptime create \
--display-name="Service Health Check" \
--resource-type=uptime-url \
--hostname=SERVICE_URL \
--path=/ \
--project=PROJECT_ID
Golden Signal Queries (Cloud Logging)
# 5xx errors on Cloud Run
resource.type="cloud_run_revision"
severity=ERROR
# Latency > 2s (requires structured logging with latency field)
resource.type="cloud_run_revision"
httpRequest.latency>"2s"
# GKE OOMKilled events
resource.type="k8s_container"
jsonPayload.reason="OOMKilling"
Safety Rules
- Log sinks can incur cost. Exporting logs to BigQuery, Cloud Storage, or Pub/Sub bills for storage and, in BigQuery's case, for queries over the exported data. Scope every sink with a tight
--log-filter— never exportseverity>=DEFAULT(i.e. everything) to a billable destination without intent. - Scope log filters narrowly. Broad filters (no
resource.type, noseverity) match high-volume logs and drive both ingestion and export cost. Always pinresource.typeand the minimumseverityyou need. - Exclusion filters reduce ingestion cost. Use log exclusions to drop high-volume, low-value logs (e.g. health-check 200s) before they are ingested and billed.
- Never log secrets. Application logs routed to Cloud Logging are readable by anyone with
roles/logging.viewer. Redact tokens, keys, and PII at the source; do not rely on downstream filtering. - Retention has a cost curve. Default retention is free to a point; extended retention on
_Default/custom buckets bills per GB. Set retention deliberately per bucket.