What's the difference between a system metric and a log-based metric in Cloud Monitoring?

System metrics (CPU utilization, request count) are emitted automatically by GCP services with no setup. A log-based metric is one you define yourself, extracted by counting or aggregating matching entries in Cloud Logging — useful for anything a resource doesn't report as a metric on its own, like a specific application error string.

Do I need to install anything to get Compute Engine metrics?

Basic metrics (CPU, disk, network) are collected automatically. Memory and process-level metrics require installing the Ops Agent on the VM, because the hypervisor can see CPU and disk activity from outside the guest OS but has no visibility into what's using RAM inside it.

What's the difference between an alerting policy's condition and its notification channel?

The condition defines when to fire — a metric crossing a threshold for a sustained duration. The notification channel defines who hears about it — email, Slack, PagerDuty, SMS. One policy can have one condition and multiple channels, so the same trigger can page an engineer and post to a channel at the same time.

Why did my alerting policy not fire even though the metric clearly crossed the threshold?

Most conditions require the threshold to be breached for a minimum sustained duration (the default is often several minutes), specifically to avoid paging on a brief, self-correcting spike. A one-second breach that recovers before the duration elapses never fires — check the condition's duration setting before assuming monitoring is broken.

Is Cloud Monitoring free?

The first 150 MiB of metric data ingested per billing account per month is free, which covers light use of GCP's own default metrics comfortably; custom and log-based metrics count toward that volume and can push a busy project past the free allotment.

Cloud Monitoring Basics | SkillByExample

Cloud Monitoring collects metrics automatically for most GCP resources, but the two things that actually make it useful — turning application log lines into metrics, and getting paged when something crosses a threshold — both require deliberate setup. This lesson does both against the web-1 VM from the Compute Engine lesson.

Reading a metric that already exists

gcloud monitoring time-series list \
    --filter='metric.type="compute.googleapis.com/instance/cpu/utilization" AND resource.labels.instance_id="4123456789012345678"' \
    --format="table(points[0].value.doubleValue, points[0].interval.endTime)"

DOUBLE_VALUE   END_TIME
0.0412         2026-09-13T10:59:47Z
0.0398         2026-09-13T10:58:47Z
0.0405         2026-09-13T10:57:47Z

CPU utilization here is a fraction (0.0412 = 4.12%), collected every 60 seconds with zero setup — this is the baseline every GCP resource ships with, before any custom instrumentation.

Creating a log-based metric

Suppose the app on web-1 writes a line like ERROR: payment declined to its logs on failure. Turn occurrences of that string into a counted metric:

gcloud logging metrics create payment-declines \
    --description="Count of declined payment attempts" \
    --log-filter='resource.type="gce_instance" AND textPayload:"payment declined"'

Created metric [payment-declines].

gcloud logging metrics list --format="table(name,filter)"

NAME                FILTER
payment-declines    resource.type="gce_instance" AND textPayload:"payment declined"

From this point forward, every matching log line increments a real Monitoring metric named logging.googleapis.com/user/payment-declines — visible in the same time-series API as any built-in metric.

Generating log entries to see the metric move

gcloud compute ssh web-1 --zone=us-central1-a \
    --command='logger "ERROR: payment declined for order 4471"'

Updating project ssh metadata...done.

gcloud monitoring time-series list \
    --filter='metric.type="logging.googleapis.com/user/payment-declines"' \
    --format="table(points[0].value.int64Value, points[0].interval.endTime)"

INT64_VALUE  END_TIME
1            2026-09-13T11:04:12Z

Creating an alerting policy

cat > policy.json <<'EOF'
{
  "displayName": "High payment decline rate",
  "combiner": "OR",
  "conditions": [
    {
      "displayName": "More than 5 declines in 5 minutes",
      "conditionThreshold": {
        "filter": "metric.type=\"logging.googleapis.com/user/payment-declines\" AND resource.type=\"gce_instance\"",
        "comparison": "COMPARISON_GT",
        "thresholdValue": 5,
        "duration": "300s",
        "aggregations": [{"alignmentPeriod": "300s", "perSeriesAligner": "ALIGN_SUM"}]
      }
    }
  ],
  "notificationChannels": []
}
EOF

gcloud alpha monitoring policies create --policy-from-file=policy.json

Created alertPolicies/12345678901234567890.

duration: 300s means five declines have to accumulate and stay over the threshold for five minutes — a single burst that clears immediately won’t page anyone, by design.

Practice

1. Attach an email notification channel to the policy created above.

gcloud alpha monitoring channels create \
    --display-name="On-call email" \
    --type=email \
    --channel-labels=email_address=you@gmail.com

Created notification channel [projects/skillbyexample-437219/notificationChannels/9988776655].

gcloud alpha monitoring policies update alertPolicies/12345678901234567890 \
    --add-notification-channels=projects/skillbyexample-437219/notificationChannels/9988776655

Updated.

A policy with an empty notificationChannels list, as created above, will fire silently in the Console but never actually notify anyone — this step is what makes it page.

2. List all existing alerting policies on the project.

gcloud alpha monitoring policies list --format="table(displayName,enabled)"

DISPLAY_NAME                 ENABLED
High payment decline rate    True

3. Generate enough log entries to actually trigger the alert, and check its incident state.

for i in $(seq 1 6); do
  gcloud compute ssh web-1 --zone=us-central1-a \
      --command="logger \"ERROR: payment declined for order 44$i\""
done

gcloud alpha monitoring policies describe alertPolicies/12345678901234567890 \
    --format="value(name)" | xargs -I{} gcloud logging read \
    'resource.type="cloud_monitoring_condition"' --limit=1

timestamp: '2026-09-13T11:12:04Z'
severity: WARNING
textPayload: 'Incident opened for policy "High payment decline rate"'

Six declines cleared the threshold of five, and after the five-minute sustained window an incident opened — visible in the Console under Monitoring → Alerting → Incidents.

4. Create a dashboard widget-free check: query the metric over the last hour with a chart-friendly aggregation.

gcloud monitoring time-series list \
    --filter='metric.type="logging.googleapis.com/user/payment-declines"' \
    --interval-start-time="$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
    --interval-end-time="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

points:
- interval:
    endTime: '2026-09-13T11:12:00Z'
  value:
    int64Value: '6'
- interval:
    endTime: '2026-09-13T11:04:00Z'
  value:
    int64Value: '1'

5. Delete the alerting policy and the log-based metric.

gcloud alpha monitoring policies delete alertPolicies/12345678901234567890 --quiet
gcloud logging metrics delete payment-declines --quiet

Deleted.
Deleted [payment-declines].

The underlying log entries in Cloud Logging aren’t affected by either deletion — only the metric definition and the policy watching it are removed.

Next: GCP cost and billing — reading a billing report, the architecture framework pillars, and a real On-Demand vs Committed Use vs Spot price comparison.

Reading a metric that already exists

Creating a log-based metric

Generating log entries to see the metric move

Creating an alerting policy

Practice

Frequently Asked Questions