Log-based metrics in GCP - Commands & Configuration

Introduction

Sometimes you want to count or measure things happening in your logs automatically. Log-based metrics let you turn log messages into numbers you can watch and alert on.

When you want to count how many errors happen in your app from logs.

When you want to measure how often a specific event appears in logs over time.

When you want to create alerts based on unusual log activity.

When you want to track performance or usage by analyzing log entries.

When you want to visualize log data trends in dashboards.

Config File - log_metric.yaml

log_metric.yaml

apiVersion: logging.googleapis.com/v2
kind: LogMetric
metadata:
  name: error_count_metric
spec:
  description: "Count of error logs"
  filter: "severity=ERROR"
  metricDescriptor:
    metricKind: DELTA
    valueType: INT64
    unit: "1"

This file defines a log-based metric named error_count_metric that counts how many log entries have severity ERROR.

filter selects which logs to count.

metricDescriptor describes the metric type and value.

Commands

This command creates a log-based metric named error_count_metric that counts log entries with severity ERROR.

Terminal

gcloud logging metrics create error_count_metric --description="Count of error logs" --filter="severity=ERROR" --metric-descriptor-metric-kind=DELTA --metric-descriptor-value-type=INT64

Expected Output

Created [https://logging.googleapis.com/v2/projects/my-project/metrics/error_count_metric].

→

--description - Describes what the metric counts

→

--filter - Selects which log entries to include

This command lists all log-based metrics in the project to verify the new metric was created.

Terminal

gcloud logging metrics list

Expected Output

NAME                DESCRIPTION

error_count_metric  Count of error logs

This command deletes the log-based metric when it is no longer needed to keep metrics clean.

Terminal

gcloud logging metrics delete error_count_metric

Expected Output

Deleted [https://logging.googleapis.com/v2/projects/my-project/metrics/error_count_metric].

Key Concept

If you remember nothing else from this pattern, remember: log-based metrics turn log messages into numbers you can watch and alert on automatically.

Common Mistakes

Using a filter that matches no logs or too many logs

The metric will not count anything or will count irrelevant logs, making it useless or noisy.

Write a precise filter that matches only the log entries you want to measure.

Not verifying the metric after creation

You might think the metric works but it may not be created or configured correctly.

Always list and check your metrics after creating them to confirm.

Summary

Create a log-based metric with gcloud logging metrics create and a filter to select logs.

List metrics with gcloud logging metrics list to verify creation.

Delete metrics with gcloud logging metrics delete when no longer needed.

Practice

1. What is the main purpose of a log-based metric in Google Cloud?

easy

A. To delete old logs automatically

B. To count specific log entries and turn them into numbers you can monitor

C. To store logs permanently without any processing

D. To encrypt logs for security

Solution

1. Step 1: Understand what log-based metrics do

   Log-based metrics count log entries that match a filter and convert them into numerical data.

2. Step 2: Compare options to this definition

   Only To count specific log entries and turn them into numbers you can monitor describes counting logs and turning them into numbers for monitoring.

3. Final Answer:

   To count specific log entries and turn them into numbers you can monitor -> Option B

4. Quick Check:

   Log-based metrics = counting logs for monitoring [OK]

Hint: Log-based metrics count logs to create numbers you watch [OK]

Common Mistakes:

• Confusing log storage with metrics
• Thinking metrics delete or encrypt logs
• Assuming metrics store logs permanently

2. Which of the following is the correct way to create a log-based metric filter to count error logs with severity ERROR?

easy

A. severity != "ERROR"

B. severity = "ERROR"

C. severity:ERROR

D. severity == "ERROR"

Solution

1. Step 1: Recall the correct filter syntax for log-based metrics

   Google Cloud uses the syntax severity == "ERROR" to filter logs with severity ERROR.

2. Step 2: Check each option

   Double equals (==) is the correct equality operator; single equals (=) is invalid. Colon (:) is for substring matching, not exact equality. != excludes the value.

3. Final Answer:

   severity == "ERROR" -> Option D

4. Quick Check:

   Filter syntax uses == for equality [OK]

Hint: Use double equals sign for filter equality [OK]

Common Mistakes:

• Using single equals instead of double
• Using colon instead of equals
• Using not equals when filtering for ERROR

3. Given this log-based metric filter: resource.type = "gce_instance" AND severity >= "ERROR", what logs will this metric count?

medium

A. All logs from GCE instances with severity ERROR or higher

B. Only logs with severity exactly ERROR from any resource

C. All logs from any resource with severity ERROR or higher

D. Only logs from GCE instances with severity lower than ERROR

Solution

1. Step 1: Analyze the filter conditions

   The filter requires resource.type to be "gce_instance" and severity to be ERROR or higher (like CRITICAL).

2. Step 2: Match options to filter meaning

   All logs from GCE instances with severity ERROR or higher correctly states logs from GCE instances with severity ERROR or higher. Others either ignore resource type or severity condition.

3. Final Answer:

   All logs from GCE instances with severity ERROR or higher -> Option A

4. Quick Check:

   Filter = GCE instance + severity >= ERROR [OK]

Hint: AND means both conditions must be true [OK]

Common Mistakes:

• Ignoring resource.type condition
• Confusing severity >= ERROR with exact match
• Assuming severity lower than ERROR is included

4. You created a log-based metric with filter severity = "ERROR" OR severity = "CRITICAL", but the metric shows zero counts. What is the likely problem?

medium

A. The filter syntax is invalid; OR is not supported in log-based metric filters

B. Severity levels ERROR and CRITICAL do not exist

C. The logs do not have severity fields

D. The metric needs at least 24 hours to show data

Solution

1. Step 1: Check if the filter syntax is valid

   The syntax severity = "ERROR" OR severity = "CRITICAL" is valid; OR is supported in log-based metric filters.

2. Step 2: Understand impact of zero counts

   A valid filter with zero counts indicates no matching logs, likely because the logs do not have severity fields or lack ERROR/CRITICAL values.

3. Final Answer:

   The logs do not have severity fields -> Option C

4. Quick Check:

   Valid filter + zero = no matching logs [OK]

Hint: Zero metric despite valid filter usually means no matching log entries [OK]

Common Mistakes:

• Assuming filter syntax invalid
• Thinking OR unsupported
• Waiting 24 hours unnecessarily

5. You want to create a log-based metric that counts how many times a specific error message appears in logs from Cloud Functions. The error message is in the field jsonPayload.message. Which filter correctly counts logs where the message contains the word "timeout"?

hard

A. resource.type = "cloud_function" AND jsonPayload.message : "timeout"

B. resource.type = "cloud_function" AND jsonPayload.message = "timeout"

C. resource.type = "cloud_function" AND jsonPayload.message >= "timeout"

D. resource.type = "cloud_function" AND jsonPayload.message != "timeout"

Solution

1. Step 1: Understand how to filter logs containing a word

   The colon operator (:) is used to check if a field contains a substring in log filters.

2. Step 2: Check resource type and filter syntax

   resource.type = "cloud_function" AND jsonPayload.message : "timeout" correctly filters logs from Cloud Functions where jsonPayload.message contains "timeout".

3. Final Answer:

   resource.type = "cloud_function" AND jsonPayload.message : "timeout" -> Option A

4. Quick Check:

   Use : to check substring in log filters [OK]

Hint: Use colon : to find substring in log fields [OK]

Common Mistakes:

• Using equals instead of colon for substring
• Using comparison operators like >= incorrectly
• Filtering for not equals when looking for matches