query_logs
Inspect service logs with error/warning summaries. Filter by service, labels, or severity, and aggregate counts or top patterns server-side.
Instructions
Fetch recent log entries for ONE service over a look-back window, with a pre-computed summary (error/warning counts and the most frequent error patterns). When to use: to inspect what a service actually logged, or to investigate an error spike surfaced by detect_anomalies / get_service_health. For numeric metrics use query_metrics instead. Golden rule: filter + aggregate server-side — pass labels to scope and aggregate (count_over_time/sum/topk) to get numbers, not raw rows. A high-volume window returned raw will blow past your context limit. Prerequisites: get the exact service name from list_services (the service must expose a logs signal). Behavior: read-only, no side effects. Returns the matching log entries (newest first, capped by limit) plus a summary with total/error/warn counts and top recurring error patterns. No matches yields an empty result with a zeroed summary; an unreachable backend yields a structured explanatory error, never an exception.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| service | No | Required (unless `raw_query` is set). Exact, case-sensitive service name exactly as returned by `list_services` (e.g. 'payment-service'). | |
| query | No | Optional. Filter expression matched against the log message; regular expressions are supported. Omit to return all entries in the window. | |
| labels | No | Optional. Exact-match filters on backend-extracted log fields (e.g. {"method":"GET","status":"200","url":"/","environment":"prod"}). All AND'd together and compiled to LogQL label filters applied after `| json`, so structured JSON fields become first-class selectors — far more reliable than regex on the raw message. Combine with `aggregate` to filter then group. Backends without label extraction ignore it. | |
| duration | No | Optional. Look-back window ending at 'now', written as <number><unit> with unit s|m|h|d (e.g. '5m', '1h', '24h'). Default: '5m'. | |
| level | No | Optional. Return only entries at this severity. Default: all levels. | |
| aggregate | No | Optional. Server-side aggregation pushed down to LogQL metric queries — returns grouped counts, not raw rows, so you get a number instead of a haystack (and never hit `limit`). Honours `labels`/`query` filters. Example: {"op":"topk","by":["url"],"k":10} for the busiest paths; {"op":"count_over_time","step":"15m"} for a request-count time series. | |
| limit | No | Optional. Maximum number of log entries to return (most recent first). Default: 100. Ignored when `aggregate` is set. | |
| bypass_redaction | No | Optional. When true, request that PII/secret redaction be skipped for this single call. The server only honours this when the calling identity is authorised to bypass — a credential listed in OMCP_KEY_BYPASS_REDACTION, or the anonymous identity when the operator set OMCP_BYPASS_REDACTION_ANON=true; otherwise the request still gets redacted output. Default: false. | |
| raw_query | No | Optional escape hatch: a verbatim LogQL log query, run as-is — for selectors/pipelines the curated params can't express. When set, `service`/`labels`/`level`/`query` are ignored and it is mutually exclusive with `aggregate` (express aggregation in the LogQL itself). DISABLED by default; the operator must enable the raw-query capability (OMCP_RAW_QUERY=on) or the call is refused. Redaction still applies to the returned log lines. |