Implementing Service Monitoring Strategies practice questions

CUMULATIVE

Why wrong: Cumulative metrics are monotonically increasing counters, not suitable for utilization.

DELTA

Why wrong: Delta metrics represent changes over a time interval, but utilization is a point-in-time value.

COUNT

Why wrong: COUNT is a reducer, not a metric type.

Use the Cloud Monitoring API to directly ingest metrics from the application.

Why wrong: Direct API ingestion requires custom code and is not the standard approach with OpenTelemetry.

Configure the application to write logs in JSON format and create a log-based metric.

Why wrong: Log-based metrics are for extracting metrics from logs, not for direct OpenTelemetry metric emission.

Use the Operations Agent on the node to scrape metrics from the application.

Why wrong: The Operations Agent scrapes from known endpoints, but not designed for OTel metric ingestion.

Error Reporting

Why wrong: Error Reporting aggregates errors, not performance profiling.

Cloud Monitoring

Why wrong: Cloud Monitoring collects metrics, not profiling data.

Cloud Trace

Why wrong: Cloud Trace is for distributed tracing, not profiling.

Absent condition with duration 10 min, based on 'latency' metric.

Why wrong: Absent condition triggers when data is missing, not based on latency value.

Metric threshold condition with alignment period 10 min, reducer MEAN, based on 'latency' metric.

Why wrong: MEAN reducer averages the metric, not the 99th percentile.

Metric threshold condition with alignment period 10 min, reducer COUNT, based on 'latency' metric.

Why wrong: COUNT reducer counts data points, not percentiles.

Export logs to BigQuery and run a query every minute to count errors.

Why wrong: This is not real-time and requires additional cost/complexity.

Use the Cloud Monitoring API to create a custom metric for error counts from logs.

Why wrong: Custom metrics are not directly created from logs; log-based metrics are the correct approach.

Create an alert policy that triggers on error logs and counts them via a notification channel.

Why wrong: Alert policies do not produce metrics for dashboards.

PagerDuty

Why wrong: PagerDuty requires a Pub/Sub integration.

Slack

Why wrong: Slack requires using Cloud Pub/Sub and a webhook integration.

SMS

Why wrong: SMS is not directly supported; only mobile notifications via the Google Cloud mobile app.

To link to a dashboard that shows the alert's metric

Why wrong: Runbook URL should link to troubleshooting steps, not a dashboard.

To automatically trigger a Cloud Function when the alert fires

Why wrong: Runbook URL does not trigger automation; it is documentation.

To provide a direct link to the source code repository

Why wrong: Runbook URL should point to runbook documentation.

Enable automatic instrumentation by adding a Cloud Trace agent to the application.

Why wrong: Automatic instrumentation is available for some languages, but manual instrumentation via OpenTelemetry is the standard approach.

Write logs with trace IDs and use log-based metric to track traces.

Why wrong: Logs cannot generate traces; they can be correlated with traces.

Add trace statements using the Cloud Trace API directly.

Why wrong: The Cloud Trace API is low-level and not intended for direct application instrumentation.

Scorecard

Why wrong: Scorecards show a single value, not distributions.

Line chart

Why wrong: Line charts show trends over time, not distributions.

Stacked bar chart

Why wrong: Stacked bars show composition, not distributions.

Disable Cloud Trace and use only Cloud Monitoring metrics.

Why wrong: Disabling tracing is not adjusting sampling.

Modify the Cloud Trace API quota to limit trace ingestion.

Why wrong: API quota limits overall requests, not sampling rate.

Configure the trace sampling rate in the Cloud Monitoring alert policy.

Why wrong: Alert policies do not control trace sampling.

It reduces log storage costs by compressing data.

Why wrong: Structured logging does not inherently reduce storage costs.

It automatically creates log-based metrics from the log entries.

Why wrong: Log-based metrics must be explicitly created, though structured logs make it easier.

It allows logs to be shipped to BigQuery in real-time.

Why wrong: Logs can be exported to BigQuery regardless of format.

Metric threshold condition

Why wrong: Metric threshold requires a metric value; unreachability may not produce a metric.

Logs-based alerting

Why wrong: Logs-based alerting uses log entries, not metric absence.

Forecast condition

Why wrong: Forecast triggers based on predicted future values.

Cloud Logging agent

Why wrong: Cloud Logging agent is vendor-specific.

Stackdriver agents on each node

Why wrong: Stackdriver agents are Google-specific, not vendor-neutral.

Cloud Trace automatic instrumentation

Why wrong: Automatic instrumentation is Google-specific and not vendor-neutral.

Duration

Why wrong: Duration is the length of time the condition must be true; not used with evaluation frequency.

Condition threshold

Why wrong: Threshold is the value to compare against, not for reducing noise.

It can profile only Java applications

Why wrong: Cloud Profiler supports multiple languages: Java, Python, Go, Node.js.

It requires modifying application code to add profiling calls

Why wrong: Profiling agents integrate automatically without code changes.

It profiles all functions by default with no configuration

Why wrong: Profiling must be enabled and requires agent or library integration.

Use a GAUGE metric with reducer MAX

Why wrong: GAUGE metric represents a snapshot; MAX reducer gives the maximum value, not the 99th percentile.

Use a CUMULATIVE metric with reducer DELTA

Why wrong: CUMULATIVE metrics measure accumulated values; DELTA reducer gives the change, not percentile.

Use a DELTA metric with reducer COUNT

Why wrong: DELTA metric is for differences; COUNT reducer gives the number of data points, not a percentile.

Use the Cloud Monitoring API directly from the application to write metrics

Why wrong: This is vendor-specific and does not support traces/logs in a unified manner.

Use Prometheus client library and scrape metrics with Managed Service for Prometheus

Why wrong: Prometheus is metrics-focused; it does not natively support traces and logs.

Use the Stackdriver Monitoring client library

Why wrong: This is also vendor-specific and does not provide the vendor-neutral instrumentation OpenTelemetry offers.

Alerting policy with a condition on 'service' field

Why wrong: Alerting conditions use metrics, not log fields directly.

Gauge metric with the 'service' field as value

Why wrong: Gauge metrics require a numeric value; 'service' is a string.

Distribution metric with a histogram of the 'service' field

Why wrong: Distribution metrics require a numeric value; 'service' is a string.

Create a log-based counter metric and use a metric-absent condition

Why wrong: Metric-absent triggers when data stops, not when threshold is exceeded.

Use a Cloud Monitoring gauge metric with a custom value

Why wrong: Custom gauge metric would require application code to report the error count, which is unnecessary.

Use a logs-based alert with a threshold on the log entry count

Why wrong: Logs-based alerting does not support threshold on count directly; it requires a log-based metric.

Scorecard

Why wrong: Scorecards show a single aggregate value.

Line chart

Why wrong: Line charts show trends over time for a single metric per line.

Stacked bar chart

Why wrong: Stacked bar charts show cumulative values across categories.