Query Statistics Field Descriptions

Review a summary of the customer administrator query statistics fields and some possible failure message cases.

Each query stats entry contains a set number of fields that describe properties of the query. Some of the contents are lower-level and are helpful for the ChaosSearch team when troubleshooting queries. Other fields are higher-level and can be useful for a customer administrator. The following table describes the customer administrator fields.

Field

Description

QueryStats.context.authority.principal

User executing the query

QueryStats.context.authority.worker_limit

The maximum worker quota for the principal executing a query

QueryStats.context.cacheHitPercent

Percentage of the query serviced from cache versus from object storage

QueryStats.context.query

The actual elastic query executed. This can include one or many requests.

QueryStats.context.query_id

Unique ID for the query. This can be provided to ChaosSearch if there are questions about a particular query.

QueryStats.context.task_queue_message

Completion message of the query, success or failure explanation. See Expected "Failed" Query Scenarios for a list of messages.

QueryStats.context.task_queue_status

Status of the query, which can be success or failed

QueryStats.context.segment_stats.totalChunks

The total number of segments read to service the query

QueryStats.timing.elasticfrontend_agg_render_ms

QueryStats.timing.elasticfrontend_agg_rollup_ms

Two measures of total time spent completing and rendering the data in Kibana

QueryStats.sourceName

The view against which the query was executed

QueryStats.timestamp

Timestamp at which the query was executed. This can be different than the log record timestamp.

QueryStats.timing.query_futureModelDefinition_ms

Time in milliseconds spent resolving the schema of all indexes required to service the request

QueryStats.timing.query_parsing_ms

Time in milliseconds spent parsing the query

QueryStats.timing.query_planning_ms

Time in milliseconds spent planning optimal query execution

QueryStats.timing.query_total_ms

The total wall clock time in milliseconds spent executing the query

TaskStats.workerPools

The pool of workers to service the query. The majority of customers have a single pool called "Default."

TaskStats.workerTimeMs

The aggregated time in milliseconds spent by all workers servicing the query

Expected Failed Status Scenarios

There are certain situations in which a query can have a "failed" status for an expected and non-problematic cause.

Relevant Fields

Description

QueryStats.context.task_queue_message: "chaossumo.dataedge.DataEdgeWorkerPool$InsufficientWorkersError$: Capacity limit reached. Please wait for pending tasks to complete."

QueryStats.context.task_queue_status: failed

QueryStats.message: started

TaskStats.state: Done(Complete)

A capacity limit reached message can happen when there are no available workers to serve a query because of other indexing and query activity. Consider clicking Burst to add temporary additional workers. However, if these errors persist, contact your Customer Success engineer.

QueryStats.context.task_queue_message: chaossumo.orchestration.TaskManager$ManagedTaskCanceled$: Task cancelled

QueryStats.context.task_queue_status: failed

QueryStats.message: Query completed

TaskStats.state: Done(Canceled)

A "task cancelled" error can occur after an explicit cancellation or if a user starts a new query while a previous one was running (a principal can have one query running at a time). For example, when a user submits Query 1, navigates to another page or tab, and submits Query 2 before Query 1 is completed, Query 1 will be canceled and Query 2 will start running.

QueryStats.message: pending

TaskStats.state: Done(Canceled)

Similar to the "task cancelled" error condition, this condition occurs when the original query is in a slightly different state.


Did this page help you?