Performance Log Fields

Table of Contents

Performance logs record every API call handled by a Kloudfuse query service, whatever its origin: a user in the UI, an API call from a service account or an MCP client, an internal service-to-service call, an alert evaluation, or a scheduled task such as a recording rule or a scheduled view. Each entry records who made the call, what it asked for, how long it took, and whether it failed.

Finding Performance Logs

Each query service writes its performance logs under its own source. Every performance entry carries the perf_log facet, so filter on that:

Filter What it selects

@perf_log="true"

Every performance log line from every service

@perf_log="true" and @msg="Finished API"

One line per completed API call. Use this as the base filter for all volume, latency, and error queries.

source="query-service" and @perf_log="true" and @msg="Finished API"

Completed calls for a single service

Every API call produces two lines. Received API is written when the request arrives and Finished API when the response is complete. Only the Finished API line carries the status, duration, and error fields. In addition, each Pinot query the call runs produces an Executed <table> Query line that carries the same kf_request_id, so a single request can be traced from receipt to every Pinot query it made.

Facets

All performance log fields are indexed as Facets. Not every service populates every field.

Identity and origin
Facet Type Description

User

string

Email of the user who issued the call, the service account name, or kloudfuse for alert evaluation and internal calls

kf_request_id

string

Request identifier shared by the Received API, Finished API, and Executed <table> Query lines of one call, and by the Pinot server logs for that call

method

string

HTTP method. Absent on scheduled tasks.

ViewName

string

Where the call came from. UI pages send their own view name, such as metrics-explorer, logs-search, apm-traces, or dashboard. MCP clients send kf-mcp. Calls with no explicit view are classified by origin: alert for alert evaluation, dashboard for dashboard panels, and service-account for API calls authenticated with a service account token. Scheduled views set it to the name of the view being refreshed.

DashboardName

string

Dashboard title, on calls made by a dashboard panel

PanelName

string

Panel title, on calls made by a dashboard panel

AlertName

string

Alert rule name, on alert evaluation calls

AlertFolder

string

Alert rule folder, on alert evaluation calls

Fromalert

string

true on alert evaluation calls
Query
Facet Type Description

api_name

string

Name of the operation. For REST endpoints it is the route pattern, such as /api/v1/query_range or /loki/api/v1/query. For GraphQL it is the operation name, such as GetLogsWithFuseQlStream. For scheduled work it is the task name, such as RuleManager, ViewEvaluator, or ScheduledSearch.

query

string

The query the call ran: a PromQL, FuseQL, LogQL, or TraceQL expression, or the GraphQL request body. Empty when the API has no query.

args

string

Remaining request parameters as a JSON object, for example start, end, step, and limit

time_range_ms

integer

Time range covered by the query, in milliseconds
Outcome
Facet Type Description

status_1

string

HTTP status code of the response, such as 200, 400, or 500. Scheduled tasks report 200 on success and 500 on failure.

duration_ms

integer

End-to-end duration of the call in milliseconds, measured at the service boundary and including Pinot execution time

is_error

string

true when the call failed. Absent on successful calls.

error_type

string

Failure class: BAD_REQUEST, UNAUTHORIZED, FORBIDDEN, NOT_FOUND, RESOURCE_EXHAUSTED, RATE_LIMITED, SERVICE_UNAVAILABLE, TIMEOUT, CANCELED, or INTERNAL_ERROR

error_component

string

Component that produced the failure, such as pinot, advanced-functions, ums, or the query service itself

error_user_msg

string

The error message returned to the caller

error_detail

string

Additional diagnostic detail, when available

The error types, their mapping to HTTP status codes, and the error payload the caller receives are documented in API Response Codes.