Query Statistics Field Descriptions

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. 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 TaskInfo.state: Done(Canceled)	Similar to the "task cancelled" error condition, this condition occurs when the original query is in a slightly different state.