This a timechart showing the average number of HTTP requests made per second to the LogScale cluster across all nodes.

This time chart shows the 50th, 90th, 99th and 100th percentile of the response times. This is how long it takes for LogScale to respond to an HTTP request.

Each HTTP request will log an HTTP status code. This timechart shows the distribution of HTTP status codes greater than 400 per second over the last 24 hours across the LogScale cluster.

This timechart shows the average requests per second across all LogScale nodes in the Ingest Endpoint: either the /api/v1/ingest or /services/collector/ endpoint.

This timechart shows again the average requests per second across all LogScale nodes in the Ingest Endpoint, but then splits it by the endpoint that has been accessed.

Each HTTP request will log an HTTP status code. This timechart in particular shows the distribution of HTTP status codes greater than 400 per second over the last 24 hours across the LogScale cluster that is trying to hit any of our Ingest endpoints. So this will show errors relating to the ingest.

When you send ingest to LogScale via a log shipper, LogScale will log details about the HTTP request containing the shipped logs. This timechart shows the 50th, 75th and 99th percentile of the contentLength size in bytes within that HTTP request. This is useful to help identify if log shippers are sending requests that are larger than expected.

See LogScale Limits & Standards for more information.

When LogScale receives an HTTP request to its ingest endpoint, it will log how long until LogScale receives it and sends a response back. This can be useful to identify if there is any lag between log shippers sending the data and the LogScale cluster responding. This timechart shows the 50th, 75th and 99th percentile of this response time in milliseconds.

When a query is submitted to LogScale, a node is responsible for co-ordinating that query. This timechart shows the number of query submits per minute for each host.

On a healthy system, one would expect this to be evenly distributed between LogScale nodes on which node receive this submission.

This timechart shows the number of queries submitted on each repository in a cluster per minute.

This can be useful to identify the repositories that are receiving most of the query load in a system. If it's also a high volume datasource, top repositories on this graph might be a good candidate for [tagging] to increase query performance.

In LogScale, a streaming query can be defined as queries that only Queries and has no Aggregations, or a non live query that uses aggregates. A live query that uses aggregate functions won't use the streaming queries Search API, but the Creating a Query Job.