Log-based metrics in GCP - Step-by-Step Execution

Process Flow - Log-based metrics

Logs Generated by Services

↓

Logs Collected in Cloud Logging

↓

Define Log-based Metric Filter

↓

Metric Created and Updated

↓

Metric Used for Monitoring/Alerting

↓

Review Metric Data and Adjust Filter

Logs are collected, filtered by a metric definition, then counted or measured to create metrics used for monitoring.

Execution Sample

GCP

resource.type = "gce_instance"
severity >= ERROR

This filter selects logs from GCE instances with severity ERROR or higher to create a custom error count metric.

Process Table

Step	Action	Filter Evaluation	Metric Update	Result
1	Log generated: INFO from GCE instance	Does not match severity >= ERROR	No metric increment	Metric remains 0
2	Log generated: ERROR from GCE instance	Matches filter	Increment metric by 1	Metric is 1
3	Log generated: WARNING from GCE instance	Does not match severity >= ERROR	No metric increment	Metric remains 1
4	Log generated: ERROR from other resource	Resource type mismatch	No metric increment	Metric remains 1
5	Log generated: CRITICAL from GCE instance	Matches filter	Increment metric by 1	Metric is 2
6	Metric used in alerting policy	Metric value = 2	Alert condition evaluated	Alert triggered if threshold exceeded
7	Filter updated to include WARNING	Future logs with WARNING match	Metric increments on WARNING logs	Metric count increases faster
8	No new logs	No filter match	Metric remains unchanged	Metric stable
9	End of trace	-	-	-

💡 No new logs or filter changes; metric updates stop.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	After 7	After 8	Final
Metric Count	0	0	1	1	1	2	2	3	3	3
Filter Severity Threshold	ERROR	ERROR	ERROR	ERROR	ERROR	ERROR	ERROR	WARNING	WARNING	WARNING

Key Moments - 3 Insights

Why does the metric not increment when a WARNING log appears before the filter update?

Because the filter only matches logs with severity ERROR or higher, WARNING is lower severity and does not match (see execution_table step 3).

What happens when the filter is updated to include WARNING logs?

Logs with WARNING severity now match the filter and increment the metric (see execution_table step 7 and variable_tracker showing filter change).

Why does a log from a different resource type not affect the metric?

The filter includes resource.type = "gce_instance", so logs from other resources do not match and do not increment the metric (see execution_table step 4).

Visual Quiz - 3 Questions

Look at the execution table at step 2. What is the metric count after processing the ERROR log?

A 0

B 2

C 1

D Error, metric not updated

💡 Hint

Check the 'Metric Update' and 'Result' columns at step 2 in the execution_table.

At which step does the filter change to include WARNING logs?

A Step 6

B Step 7

C Step 5

D Step 8

💡 Hint

Look at the 'Filter Severity Threshold' variable in variable_tracker and execution_table step descriptions.

If a CRITICAL log from a GCE instance is generated at step 10, what happens to the metric count?

A Metric count increments by 1

B Metric count decreases

C Metric count stays the same

D Metric resets to zero

💡 Hint

CRITICAL severity is higher than ERROR, so it matches the filter and increments the metric (see execution_table step 5).

Concept Snapshot

Log-based metrics count or measure logs matching a filter.
Define a filter on log fields like resource type and severity.
Matching logs increment the metric count.
Metrics can trigger alerts or dashboards.
Updating filters changes which logs count.
Useful for monitoring specific log events in GCP.

Full Transcript

Logs are generated by cloud services and collected in Cloud Logging. A log-based metric is created by defining a filter that selects logs based on criteria like resource type and severity. When logs match the filter, the metric increments or measures data accordingly. This metric can then be used for monitoring or alerting. For example, a filter selecting ERROR logs from GCE instances increments a custom metric each time such a log appears. If the filter is updated to include WARNING logs, those logs also increment the metric. Logs from other resource types do not affect the metric if the filter excludes them. This process helps track important events in logs and respond to them automatically.

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