Elasticsearch and OpenSearch checks
Every check Verbiqo can run on an Elasticsearch cluster (7.17 and later) or an OpenSearch cluster (2.0 and later), and on a search you paste, grouped by area. Verbiqo reads the monitoring and metadata APIs with the role from Set up Elasticsearch or OpenSearch (OpenSearch’s), and never reads a document. OpenSearch below says what differs there. The checks are grouped into areas, one section each below. You never type an area’s name: you ask a question, and Verbiqo runs the areas it needs.
How to read this page. Each section is one area. Why it helps says what you get from it. Ask is a question to type that runs it. The table under it lists what Verbiqo checks there: you do not run those one by one. When a check finds a problem, it appears under the answer as a finding, with its evidence and a suggested fix.
How areas are chosen
Ask in your own words
Attach the cluster with
/esand the connection’s name (/es logs), then ask, for example why is the cluster yellow?The model picks the areas
It reads the question and says which areas it needs. Verbiqo reads only what those areas need.
Words as a safety net
The words in the middle column below also bring their area in, even when the model leaves it out, and decide on their own when the model is unavailable. You do not need to use them: they are listed so you can see why an area was read.
| Area | Words that always bring it in | Ask, for example |
|---|---|---|
| The cluster review | recovery, rebalancing, balance, allocation, relocating, ingest, pipelines, translog, merges, replication, followers, CCR, anomaly, review, health, check-up, audit, red, yellow, unassigned, shards, disk, watermark, heap, memory, GC, breaker, rejections, oversharding, mapping, fields, templates, index model, index design, data model, ILM, lifecycle, snapshots, backups, stability, improve, recommendations, what is wrong, problems, cluster, nodes, master | Review the cluster, Why is the cluster yellow?, Why is recovery slow?, Why aren’t the shards balancing?, Is any ingest pipeline failing? |
| Right now | slow, latency, hanging, stuck, timeouts, rejected, 429, busy, load, CPU, hot threads, right now, currently, spike, backpressure, queue | Searches are slow right now, what is going on? |
| A search query | paste the query (JSON, or a GET index/_search { … } request) with analyze, optimise, rewrite, improve, why is this query slow | Why is this query slow? GET products/_search { … } |
| Search performance | search performance, searches are slow, search latency, relevance, query cache, request cache, caches, segments, force merge, pagination, top queries, slowest queries, improve search | How can I improve search performance? Which indices take the most search time? What were the slowest searches yesterday? |
| Why a value does or does not match | paste the query and put the value in quotes, with doesn’t match, doesn’t find, no results, analyzer, tokenize | Why doesn’t this find "Red Shirt"? GET products/_search { … } |
| Sizing, tiers and cost | capacity, sizing, how long until, fill up, growth, scale out, headroom, planning, how many nodes | Do we need more nodes? |
| What happened | what happened, timeline, incident, yesterday, at 3pm, when did, root cause | What happened on the cluster yesterday? |
| The cluster’s own security | security, secure, anonymous, authentication, TLS, HTTPS | Is this cluster secure? |
| Security events in the logs | logons, sign-ins, brute force, password spray, privilege, administrators, audit log, cleared, attack, intrusion, suspicious, alerts, incidents, ssh, sudo, lockouts, accounts created, threats, breach | Any suspicious logons in the last 24 hours? |
| Credentials in the logs | secrets, credentials, passwords, API keys, tokens, private keys, leaked, exposed, plain text, in the same question as logs | Are any passwords or keys leaked in our logs? |
| Upgrade readiness | upgrade, deprecated, deprecation, migrate, breaking changes, end of life | Can we upgrade to 9.0? Which clients use deprecated features? |
| What Verbiqo can see | what should I enable, readiness, permissions, privileges, roles | What should I enable? |
A question that carries a query is about that query: the cluster is reviewed as well only when the question also mentions the cluster, nodes, shards, disk or heap. The two log areas search only the log indices the connection names (Set up); a connection without them never reads a document.
The cluster review
Why it helps: Checks the whole cluster in one pass (health, shards, disk, heap, pipelines, settings), so you see every problem with its fix at once.
Ask Review the cluster. Or about one part of it: Why is the cluster yellow? Is any ingest pipeline failing?
A question about one part still runs the whole review, so a problem elsewhere is not missed.
Health and shards
| Check | What it looks for |
|---|---|
| Unassigned shards | Primaries (red) and replicas (yellow) not assigned, each with the cluster’s own reason from allocation explain and a suggested fix. |
| Health indicators | The cluster’s own health report (8.7+): disk, ILM, SLM, master stability, shard capacity and others, with its diagnosis. |
| Oversized shards | Shards larger than 50 GB: slow to recover and relocate. |
| Document limit | Shards near Lucene’s limit of about 2.1 billion documents. |
| Oversharding | Index series whose shards average under 1 GB: heap and master load for nothing. |
| Shards near the per-node limit | Nodes close to cluster.max_shards_per_node. |
| Unbalanced shards | One node holding far more shards than another, with the cluster’s own reason: allocation explain asked about a shard on the fullest node (rebalancing waits for a green cluster, awareness, filters, the disk watermark, the per-index cap, or the allocator counting it balanced), and a suggested fix for that reason. |
| Rebalancing under way | Where the role may read the allocator’s desired balance (8.6 and later): how many shards are not yet where it wants them, and from which nodes; or that nothing is left to move, so the imbalance is by its own weights. Asked whether it is still rebalancing, Verbiqo says which, after the answer; where the role cannot read the desired balance it says that the answer is not known, rather than “no” from recoveries alone. |
| Shard cap per index | index.routing.allocation.total_shards_per_node set so low that the index’s copies cannot all be placed with one node gone; a warning when shards are unassigned because of it. |
| Idle data node | A data node holding no shards. |
| Allocation or rebalancing restricted | cluster.routing.allocation.enable or rebalance.enable left restricted, often after maintenance. |
Disk
| Check | What it looks for |
|---|---|
| Watermarks | Nodes past the low, high or flood-stage disk watermark, and what each stage stops. |
| Watermarks raised | Watermarks set above the defaults, leaving less room for merges and relocations. |
| Write blocks | Indices refusing writes (read_only_allow_delete after flood stage, or a manual block). |
| Uneven disk | Disk use far apart between data nodes, with the cluster’s own reason why shards stay on the fullest one. |
Recoveries
The recoveries running when you ask, each with its own elapsed and throttled time (_cat/recovery and _recovery). Nothing is said when none is running.
| Check | What it looks for |
|---|---|
| Held back by the speed limit | Recoveries that spent 30% or more of their time waiting on indices.recovery.max_bytes_per_sec, with the setting to raise while the cluster recovers. |
| Replaying a large translog | A shard in the translog stage with a million or more operations to replay: it was not flushed before its node went down. Flush before planned restarts. |
| Barely moving | A recovery under 10% after 30 minutes without being throttled: usually the source node or the network. |
| Waiting their turn | Many shards waiting while recoveries run two at a time per node (node_concurrent_recoveries). |
| Running | Recoveries in progress with none of the above: their stage, progress and speed. |
Ingest, merges and the translog
From each node’s counters, which run since the node started.
| Check | What it looks for |
|---|---|
| Pipeline failures | An ingest pipeline that failed documents, with the processor that failed most. |
| Slow pipeline | A pipeline taking 30% or more as long as indexing itself, with its slowest processor. |
| Merges throttled | Merges throttled for half their time or more; a warning when indexing itself was slowed for an hour or more to let them catch up. |
| Large unflushed translog | Nodes with 2 GB or more of translog not yet flushed: replayed one operation at a time after a restart. |
| Bulk requests too small | Clients whose last request was a bulk, with 1,000 or more requests averaging under 100 KB: overhead spent per request. 5 to 15 MB a request is the usual sweet spot. |
| Bulk requests too large | Clients sending bulk requests averaging 100 MB or more: held in memory while parsed, so heap pressure, breakers and rejections. |
| Connections not reused | Most of the nodes’ recent client connections made one or two requests and closed: a client opening a connection per request. |
The client checks read each node’s recent HTTP clients (user agent, address, requests and bytes): a recent window, not full history, and a load balancer in front shows as one address. Whether replicas or refresh should be off during a bulk load depends on what the load is, so it is advice when you ask why indexing is slow, not a finding.
Nodes, heap and memory
| Check | What it looks for |
|---|---|
| Heap high | A node’s heap use high. |
| Heap above 31 GB | Heap too large for compressed object pointers. |
| Heap above half the memory | Heap leaving too little memory for the file system cache. |
| Circuit breakers | Breakers that tripped, by breaker. |
| Rejections | Search and write thread pools rejecting work. |
| Swapping | Nodes using swap. |
| Fielddata | Fielddata holding a large share of heap, and fielddata enabled on text fields. |
| File descriptors | A limit below 65,535, or most descriptors in use. |
| Masters | An even or too-small number of master-eligible nodes, or no dedicated masters in a larger cluster. |
| Mixed versions | Nodes running different versions. |
Indices and mappings
| Check | What it looks for |
|---|---|
| Empty indices | Indices older than a day with no documents. |
| Deleted documents | Indices with over 25% deleted documents. |
| No replicas | Indices with no replica: one node lost is data lost. |
| Mapping explosion | Indices near their field limit. |
| Refresh interval | Write-heavy indices still refreshing every second. |
Lifecycle and snapshots
| Check | What it looks for |
|---|---|
| ILM errors | Indices stuck on a failed lifecycle step, with the step and the error. |
| ILM stopped | Index lifecycle management stopped or stopping. |
| No lifecycle | Series of dated indices with no lifecycle policy. |
| Data stream health | Data streams that are yellow or red. |
| Snapshots | No repository, no SLM policy, a policy that failed on its last run, or one that has not succeeded for too long. |
| Snapshot running long | A snapshot in progress for six hours or more, with how much it has copied and how fast. |
| Snapshots getting slower | The latest snapshot taking twice as long as the median of the ten before it, and 30 minutes or more. |
| Partial snapshot | The latest snapshot in a repository missing failed shards: those indices cannot be restored from it. |
The index model
How indices are mapped, templated and sharded, judged per series (logs-2026.10.01 and logs-2026.10.02 are one series). Each finding names the indices and fields, with the template change; changes apply to indices created after them. Ask Review our index design or Are our mappings and templates right?
| Check | What it looks for |
|---|---|
| Strings indexed twice | A series whose newest index has 10 or more strings mapped by dynamic mapping as both text and keyword. Most fields need one: keyword for identifiers, hosts and statuses; match_only_text for log messages. Suggests a dynamic template so new strings become keyword. Which fields are searched as full text Verbiqo cannot see, so it says to check first. |
| Type changes within a series | A field that is, say, long in one index and keyword in the next: aggregations break across the series and Kibana shows a conflict. Changes within one family (two number types, text and keyword) are not counted. |
| No index template | A series of three or more indices that no template, composable or legacy, creates: shard count from the default, mappings from dynamic mapping. |
| Legacy templates | Templates in _template, deprecated since 7.8; a warning where a composable template matches the same index, because the legacy one is then ignored. |
| Shards that do not divide over the nodes | A series of 50 GB or more whose shard copies do not divide over the data nodes (5 primaries with a replica on 3 nodes: 4, 3 and 3). Suggests the count that divides evenly while keeping shards nearest 10 to 50 GB. |
Also in the review, elsewhere on this page: field counts near the limit, fielddata on text fields, identifiers mapped as numbers, dates stored as strings, shard sizes, and series with no lifecycle.
Cross-cluster replication and machine learning
Read when the cluster has them; a cluster without them is not reported as unreadable. Replication is read from both sides: on a follower cluster, each follower’s stats and status (paused ones included) and the remote cluster connections; on a leader cluster, when the question is about replication, the leases followers hold on its history (a read that grows with the number of shards, so not taken for every review). Every follower is also listed in the review: its leader, how far behind, when it last read, failed reads and writes, and how much of read time is spent outside the leader (network and queues). The monitoring role reads all of it.
| Check | What it looks for |
|---|---|
| Replication stopped | A follower index whose following stopped on an error, with the error and the resume request. |
| Follower lagging | A follower 100,000 or more operations behind its leader, or not read from for five minutes. |
| Follower about to lose its history | A follower not read from for 6 hours or more: the leader keeps history for it only while its retention lease lasts (12 hours by default), after which it cannot catch up and must be recreated. |
| Follower paused | A follower index paused: not replicating at all, with the resume request. |
| Reads failing, retrying | A follower whose reads from the leader fail and are retried, with the error. |
| Remote cluster not connected | A remote cluster down: critical when followers or auto-follow use it. |
| Follower reading faster than it writes | A follower’s write buffer at 80% of its limit: the follower cluster’s indexing is the bottleneck, not the network. |
| Auto-follow failing | Leader indices an auto-follow pattern failed to follow, with the reason. |
| Stale lease on the leader | On a leader cluster, a follower that has not renewed its lease for an hour (it renews every 30 seconds while replicating): critical from 6 hours. |
| ML job failed | An anomaly detection job in the failed state (needs monitor_ml). |
| ML memory limit | A job at its model memory limit: it stops learning new entities. |
Tasks
| Check | What it looks for |
|---|---|
| Long searches | Searches running for more than 30 seconds. |
| Long tasks | Reindex, update or delete by query, force merge or bulk running for over 30 minutes. |
| Pending cluster tasks | Tasks queued for the master. |
Settings, security and licence
| Check | What it looks for |
|---|---|
| Security off | Anyone who can reach the cluster can read, change and delete everything. |
| Wildcard deletes | action.destructive_requires_name false. |
| Painless regular expressions | Scripts allowed unlimited regular expressions. |
| Scripts unrestricted | Every script type allowed in every context (a hardening note). |
| Adaptive replica selection off | Searches not steered away from slow copies. |
| Recovery and rebalance concurrency | Set too high (recoveries starve searches and indexing) or too low (a lost node takes longer to rebuild). |
| Shards per node raised | cluster.max_shards_per_node raised, hiding oversharding. |
| Default data path | Data kept under the installation directory, where an upgrade can remove it. |
| Memory lock off | bootstrap.memory_lock off on hosts that have swap. |
| Default cluster name | The cluster called elasticsearch: another node on the network could join it. |
| Version | A 7.x release, or a version behind the last minor of its line (7.17 or 8.19). |
| Licence | A licence expired or expiring. |
The security review checks security on, HTTPS and anonymous requests refused (with a request sent without credentials) as controls across every saved connection, with the certificate, mapped to CIS Controls, ISO 27001 and SOC 2.
Upgrade readiness
Why it helps: Shows what blocks an upgrade and which clients still use deprecated features, so the upgrade does not break them.
Ask Which clients use deprecated features?
Ask about a version (Can we upgrade to 9.3?) or about upgrading in general (Can we upgrade?, the next major). After the answer, Verbiqo says in its own words, from Elastic’s and OpenSearch’s upgrade rules rather than the model’s memory:
- The path to that version. Within a major version: straight to it. To the next major: only from its bridging minor (5.6, 6.8, 7.17; 8.18 to 9.0, 8.19 to 9.1 or later; OpenSearch 1.3 and 2.19), so an earlier minor goes there first. Further: one major at a time, each step listed. Lower than the running version: a downgrade, which is not possible in place; a snapshot taken before the upgrade is the way back. A major newer than Verbiqo knows is said to be unknown.
- Release order (Elasticsearch): the target must also be released after the running version, so a late 8.19 patch cannot go to an early 9.x release. In practice, a current patch release; Elastic’s release notes give the dates.
- Indices the target cannot open: read from the version that created each index. A major version opens indices from the major before it only; Elasticsearch 9 also opens 7.x indices with a write block, read-only. Each is named, system indices apart (Kibana’s Upgrade Assistant migrates those), with what to do: reindex, delete, or for 9.x a write block.
- The order: Elasticsearch first, then Kibana at the same version, then Fleet Server and APM, then Beats, Elastic Agent and Logstash (OpenSearch before OpenSearch Dashboards).
- The deprecation log: what it found, or why it could not be read (not named on the connection, refused, or not created yet because nothing deprecated was used).
- What it did not read: deprecated settings and mapping changes, which Kibana’s Upgrade Assistant lists.
| Check | What it looks for |
|---|---|
| Indices the target cannot open | Indices created two or more major versions before the target (7.x indices for 9.x unless write-blocked; 6.x for 8.x): the upgrade will not start with them. |
| Breaking on the next major version | Deprecated features logged at CRITICAL in the period (a week unless you name one): what each is, how often, and which clients use it. |
| Other deprecations | Deprecated features logged at WARN: to be removed later. |
The deprecation info API (_migration/deprecations) needs the manage privilege, which Verbiqo does not accept. The log says which clients and requests will break; Kibana’s Upgrade Assistant lists the index-level changes it does not.
Right now: the live sample
Why it helps: When searches are slow now, it samples what the nodes are doing, so you know which search or task is to blame.
Ask Searches are slow right now, what is going on?
Verbiqo reads every node’s counters twice, 5 seconds apart (2 to 30, see sampling), then the tasks running and the hot threads.
| Check | What it looks for |
|---|---|
| Rejections | Searches and writes rejected during the sample, per node. |
| Garbage collection | A node spending a large share of the sample in GC. |
| Slow searches | Search time per shard query on each node during the sample. |
| Indexing throttled | Indexing throttled because merges fall behind. |
| Hot node | One node much busier than the others. |
| Long searches now | Searches running 10 seconds or more; their query is taken from the task and analyzed, without running it again. |
| Stuck tasks | A reindex, update or delete by query, force merge or snapshot running 5 minutes or more whose progress did not move during the sample. |
| Hot threads | What the busiest threads are doing: a Painless script, an aggregation, a merge, a search. |
A search query: analyze and rewrite
Why it helps: Explains why one search is slow and rewrites it, without running it, so you can fix that search.
Ask Why is this query slow? GET products/_search { … }
Verbiqo reads the query against the index’s real mapping, validates it, and with read on the index profiles it with no documents returned. Then it shows the query rewritten, with each change listed.
Speed
| Check | What it looks for |
|---|---|
| Leading wildcard | A wildcard, regular expression or query_string starting with * or ?: every term in the field is read. |
| Short prefix | A prefix query of one or two characters. |
| Fuzzy | Fuzzy matching with many expansions, or fuzzy and regex syntax arriving from user input. |
| All fields | A query_string searching every field. |
| Scripts | A script query or script score running for every matching document. |
| Runtime fields | Fields computed at query time. |
| Joins | has_child and has_parent queries. |
| Large terms | A terms query with thousands of values. |
| Filter context | Exact-match clauses scored when they could be cached filters. |
| Unrounded now | Date ranges on now without rounding, which defeats the cache. |
| Deep pagination | A large from, or from + size beyond the result window; search_after instead. |
| Large responses | Many documents in one response, full _source, many highlighted fields. |
| Exact hit counts | track_total_hits: true counting every match. |
| Scan by score | Reading many documents with match_all in score order. |
| Debugging left on | profile or explain left on. |
Aggregations
| Check | What it looks for |
|---|---|
| Bucket explosion | Nested terms aggregations whose buckets multiply. |
| Large terms aggregation | A terms aggregation asking for very many buckets. |
| Deep nesting | Aggregations nested several levels deep. |
| Tiny interval | A date histogram with an interval too small for its range. |
| Cardinality precision | A precision_threshold set far higher than needed. |
Correctness
| Check | What it looks for |
|---|---|
| Term query on text | A term query on an analyzed field: it misses most values. |
| Wildcard on text | A wildcard that matches single analyzed words, not the whole value. |
| Range on keyword | A range on a keyword field, compared as text ("9" > "10"). |
| Sort or aggregate on text | Sorting or aggregating on a text field. |
| Ignored should clauses | should clauses silently ignored next to a must or filter. |
Search performance across the cluster
Why it helps: Finds the slowest and most expensive searches across the cluster, so you fix the ones that matter.
Ask What were the slowest searches yesterday?
Read with every cluster review, and led by a question about search.
| Check | What it looks for |
|---|---|
| Filter cache churn | The query (filter) cache answering under 10% of lookups while evicting heavily: filters that never repeat, such as an unrounded now. |
| Request cache rarely hits | Size-0 searches (dashboards, aggregations) rarely reused: indices refreshed every second, or an unrounded now. |
| Read-only indices not merged | Indices no longer written, still in 30 or more segments per shard, with the force merge to run off-peak. An index still written is left alone. |
| Result window raised | index.max_result_window above 10,000: deep pages that can exhaust the heap; search_after instead. |
| Bucket limit raised | search.max_buckets raised above the default. |
| Identifiers mapped as numbers | Fields named like IDs or codes mapped as long or integer: exact lookups are faster on keyword. |
| Dates mapped as strings | Fields named like dates mapped as keyword or text: ranges and sorts compare text, not time. |
| Top queries fan out | OpenSearch: top queries searching 100 or more shards. |
| Busiest indices | Where search and indexing time goes, by index, since their shards started. |
| Slow index searches | Indices whose searches are slow on average, with the slow log settings to capture them. |
| Slow searches per tier | A warm or cold tier whose searches take much longer than hot. |
| Slow log, from the cluster’s own log indices | Where the slow log is shipped into the cluster (logs-elasticsearch.slowlog-*) and named in the connection’s Log indices: the slowest searches of the period, with their index and query, and the two slowest queries analyzed without running them again. |
| Slow log, from Splunk | Slow searches grouped by query shape, the slowest analyzed. See Log findings. |
Why a value does or does not match
Why it helps: Explains why a document does or does not match a search, from the analyzers and mappings, so you can fix the mapping or the query.
Ask Why doesn’t this find "Red Shirt"? GET products/_search { … }
Paste the query and put the value you expected it to find in quotes. Verbiqo asks the cluster how the query’s text is searched and what the value becomes in the same field, using _validate/query with explain. So the field’s real analyzer, normalizer and synonyms apply, no document is read, and the monitoring role is enough. (The _analyze API would need manage on Elasticsearch.)
| Check | What it says |
|---|---|
| What the query searches for | For each clause, the field, its type and analyzer, and the terms it looks for: match on name (text, analyzer standard): searches for [red] [shirts], all of them. |
| Singular and plural | The value becomes [shirt] but the query wants [shirts]: no stemming on the field; search a sub-field with a language analyzer. |
| Term query on text | A term query is not analyzed: [Red Shirt] as one term against [red] [shirt]; use match, or the keyword sub-field. |
| Case on keyword | [SKU-00012] against [sku-00012], compared exactly; a lowercase normalizer or case_insensitive. |
| All terms required | operator: and excluding a document for one missing term; minimum_should_match instead. |
| Phrases | Whether the terms appear together and in order. |
Sizing, tiers and cost
Why it helps: Shows how much room the cluster has, how tiers are used and where cost goes, so you size nodes from evidence.
Ask Do we need more nodes?
| Check | What it looks for |
|---|---|
| Node count | How many data nodes the data needs at the high watermark, now and in 90 days; never fewer than an index’s copies. |
| Tier under-used | A tier using a small share of its disk. |
| Memory to disk | A tier’s memory-to-disk ratio against what the tier is for. |
| Writes off the hot tier | Write indices with shards outside the hot tier. |
| Loaded tier | Nodes in a tier at 85% CPU or heap: the whole tier (add nodes) or some (uneven shards). |
| Replicas on warm and cold | Older indices keeping two or more replicas. |
| Frozen cache | A frozen node with no shared cache. Its hit rates need manage, which Verbiqo does not take. |
| Coordinating nodes | None in a cluster of ten or more data nodes, or ones sitting idle. |
| Vector memory | The memory dense_vector fields need against the page cache. |
| Indexing failures | Documents that failed to index. |
| Node machines too large | Asked about capacity, each data node’s CPU history from a connected metrics source; a tier whose every node is far larger than its load. |
Disk runway to each watermark is on Capacity checks.
OpenSearch
Why it helps: Says which checks differ on OpenSearch, so you know what an answer there covers.
Ask Is this OpenSearch cluster healthy?
OpenSearch 2.0 and later gets the same checks, read through its own APIs where it differs from Elasticsearch:
| Area | On OpenSearch |
|---|---|
| The account | Read from the security plugin. OpenSearch will not tell an account its own permissions, so an account with a role that writes (all_access, *_full_access and others) or with security REST API access is refused by name, and a custom role is reported as not verifiable. No security plugin is reported as security off. |
| Lifecycle | Index State Management (ISM): failed actions with the reason, and the retry request (POST _plugins/_ism/retry/<index>); retention from the delete state’s min_index_age for the disk forecast. |
| Snapshots | Snapshot Management policies: the latest run, and failures. |
| Top queries | With Query Insights on (2.12+), the slowest searches OpenSearch recorded in its window, listed with their latency and shards. The slowest of each shape is analyzed and rewritten, without running it again. |
| Cluster managers | The cluster_manager role is judged as master-eligible, and named in OpenSearch’s words. |
| Version | 1.x, and a 1.x below 1.3, are flagged. |
| Not on OpenSearch | The health report, the licence, and the frozen and data tiers (OpenSearch uses node attributes for hot and warm). |
What Verbiqo can see
Why it helps: Lists what Verbiqo can and cannot see on this cluster, with how to turn each on.
Ask What should I enable?
Ask what should I enable? for the role, read for profiling, slow logs and snapshots (and on OpenSearch, Query Insights), each as ready or not, with the request that fixes it.
Ready-made reports
A report is one fixed reading of one area: no question, no model, the same output every time. Use one to look at an area yourself, or to share what it shows.
From a terminal, it prints the report:
verbiqo es run logs healthIn verbiqo chat, it loads the report into the conversation so you can ask about it. help lists the reports:
/es logs health
/es logs helpIn the desktop apps, there is no report command: ask in your own words, and Verbiqo reads what the question needs.
Two more commands from a terminal: the whole review, and the analysis of one search:
verbiqo es review logs
verbiqo es analyze logs --file query.json| Report | Shows |
|---|---|
health | Cluster health, nodes and shard counts. |
health-report | The cluster’s own health indicators and diagnoses (8.7+). |
nodes | Roles, heap, memory, CPU, load, disk. |
allocation | Disk use per node against the watermarks. |
indices | Indices by size: health, shards, documents, deleted. |
shards | Shards by size, with state and node. |
unassigned | Why the first unassigned shard is unassigned. |
thread-pools | Active, queued, rejected. |
tasks | Tasks running now, longest first. |
pending-tasks | Cluster tasks waiting for the master. |
recovery | Shard recoveries in progress. |
fielddata | Fielddata held in heap, by field. |
segments | Segment counts and memory per node. |
ilm-errors | Indices whose lifecycle step failed. |
data-streams | Health, backing indices, lifecycle. |
snapshots | Snapshot policies: last success and failure. |
templates | Index templates and the patterns they match. |
hot-threads | The threads using the most CPU on each node. |