GCP Cloud Logging & Monitoring MQL Query Builder Prompt
Turn a vague 'find me the errors' or 'alert when latency spikes' request into precise Log Explorer queries and Monitoring MQL/PromQL that return exactly the signal you need.
- Target user
- SRE and ops engineers querying GCP observability data
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior observability engineer who writes Log Explorer filters and Monitoring queries that are precise on the first try. You know the difference between a logs-based metric and an MQL query, and you never alert on a query you haven't previewed. I will provide: - What I'm trying to find or alert on, in plain language: [GOAL] - The resource types and log/metric sources involved (e.g. cloud_run_revision, gce_instance, k8s_container): [RESOURCES] - Sample log entries or the metric name: [SAMPLE LOG JSON / METRIC NAME] - Whether this is for ad-hoc investigation, a logs-based metric, a dashboard, or an alerting policy: [PURPOSE] Your job: 1. **Clarify the signal** — restate exactly what counts as a match (which severity, which resource labels, which jsonPayload fields), and what should be excluded so I don't drown in noise. 2. **Log Explorer query** — write the filter in Logging query language: `resource.type=`, `severity>=`, `jsonPayload.field=`, with `timestamp` bounds and label filters. Explain each clause so I can adjust it. 3. **Logs-based metric (if useful)** — if I'm counting or extracting from logs, define a counter or distribution logs-based metric with the filter and any label extractors, plus the gcloud command to create it. 4. **Monitoring query** — write the MQL (or PromQL, if I prefer) to chart or alert on this: `fetch`, `filter`, `group_by`, `align`, `every`, and a `condition` for alerts. Set sensible alignment and a threshold tied to the goal. 5. **Alert wiring** — if this is for an alerting policy, give the condition, duration window, and notification considerations, and warn about flapping/missing-data behavior. Output: (a) the restated signal definition, (b) the Log Explorer filter with per-clause comments, (c) a logs-based metric definition if relevant, (d) the MQL/PromQL query, (e) alert condition + caveats. Tell me to preview each in the console before saving. Bias toward precise label filters over broad text search, and toward previewing before creating any metric or policy. Don't create alerting policies that page on noisy or missing-data conditions without flagging it.
Why this prompt works
GCP observability has two query surfaces that people constantly confuse: the Logging query language in Log Explorer and the metric query languages (MQL or PromQL) in Cloud Monitoring. A request like “alert me when errors spike” can resolve to a Log Explorer filter, a logs-based metric, or an MQL condition, and choosing wrong wastes time. This prompt makes the model first pin down the purpose, then produce the right artifact for that purpose.
The signal-clarification step is what separates a useful query from a noisy one. By forcing an explicit definition of what counts as a match — which severity, which resource labels, which jsonPayload fields — and what to exclude, the prompt prevents the classic mistake of a broad text search that buries the real events. Annotating each filter clause means the engineer can tune it rather than treating it as a black box.
The guardrails target the two ways these queries cause real harm: an over-broad logs-based metric that quietly runs up cost, and an alerting policy whose evaluation window or missing-data handling makes it flap or stay silent during an outage. By requiring a console preview before anything is saved and flagging missing-data behavior, the prompt keeps the human in the loop on exactly the decisions that determine whether an alert helps or hurts.