このページはCalíope 1.7を紹介しています。私がいま作っているバージョンです。1.6は、Mac、iPad、iPhone、Apple Watch、Apple TV、Apple Vision Pro向けにApp Storeで公開中です。それぞれの機能がどのバージョンで入ったかは変更履歴に書いてあります。

すべてのトピックに「Calíopeで開く」ボタンを追加します。アプリがインストールされている場合にのみ機能します。

Elasticsearch and OpenSearch

The Query: Query DSL, SQL, ES|QL and PPL

How to search in Query DSL, SQL, ES|QL or PPL, how paging works, what aggregations and “Explain” show, and why the Query only reads.

場所: ワークスペース › ツール › Query

対象: Elasticsearch OpenSearch

The Query sends what you type to the cluster, over the open session. Run (⌘↩) runs it and Stop (⌘.) stops waiting for the answer: whatever the server already started may still finish.

The language
The language picker in the bar shows only the languages of the session’s product. Both have Query DSL —the JSON body of _search— and SQL.

Elasticsearch

Elasticsearch also has ES|QL, its piped language: FROM demo_productos | WHERE precio > 40 | LIMIT 10.

OpenSearch

OpenSearch also has PPL, its piped language: source=demo_productos | where precio > 40 | head 10.

Query DSL
The whole body goes to _search on the indices written in Indices: empty means all of them, and several are separated by commas. Choose an index lists them. The Page: 50 menu says how many documents each page brings (50 unless you change it), unless the body carries its own size, which wins. The server rejects broken JSON, and the error says where the mistake is: the line and column, or the byte of the body.

Pages and the total
Next page asks for the next one. If the search sorts (sort), it goes by search_after, which continues from the last document received and has no limit. If it doesn’t sort, it goes by from, which the server cuts off at 10,000 documents, and the view says so. The server stops counting at 10,000 and the total shows as “10,000 or more”; Exact total asks it to count them all (track_total_hits), at the cost of time.

What you see
Documents shows each document folded into one line, with its score; open it to see its whole _source. Table puts the fields in columns, with nested objects flattened. If the body carries aggs, the Aggregations appear below, as a tree. Explain, on each document, asks the server why it matches the search (_explain) and shows how it computed its score.

SQL, ES|QL and PPL
In these languages the index goes inside the query (FROM, source=), and the answer is a table. Each column header carries the type the server declares, which doesn’t always match between languages or between products. If the cluster’s license doesn’t include a language, the server says so; Elasticsearch’s basic license includes SQL and ES|QL.

Elasticsearch

Translate to Query DSL, in SQL, asks Elasticsearch for the equivalent Query DSL (_sql/translate) and opens it in Query DSL, with the index from the FROM already filled in.

OpenSearch

OpenSearch doesn’t translate SQL to Query DSL: it only gives its engine’s plan. That’s why, with OpenSearch, the bar has no Translate to Query DSL.

It only reads
The Query doesn’t write: the Query DSL body always goes to _search, SQL, ES|QL and PPL only query, and a DELETE written in SQL isn’t sent. There’s no delete or update by query here (_delete_by_query, _update_by_query).

キーワード: elasticsearch、opensearch、query、search、query dsl、_search、sql、es|ql、esql、ppl、search_after、from、total、aggregations、explain、_explain、translate

Indices: the list, the documents, the slow log, templates and pipelines

What each tab of an index shows, what you can write and how, where the slow log ends up, and why there is no reindexing.

場所: ワークスペース › ツール › Indices

対象: Elasticsearch OpenSearch

The tab has three sections, in the picker on the toolbar: Indices, Templates and Pipelines. Reload reads the one on screen again.

Indices
On the left, the indices of the cluster with their health —a glyph and its name, never just a color—, their documents and their size. System indices (those starting with a dot and those the server hides) are folded in their own group. The document count in the list is Lucene’s, which counts each object of a nested field separately; what a search returns is in Statistics. Pick an index and its detail appears on the right, in tabs that are read when you open them:

- Fields: the mapping as a tree, each field with its type, its parameters and its subfields.
- Settings: the settings written on the index (not the defaults), with the slow log threshold first.
- Shards: each shard, primary or replica, with its state, its node and, if it has no node, the reason.
- Aliases: the aliases that point to the index.
- Documents: a sample of the documents, 25 at a time.
- Statistics: the top-level documents next to Lucene’s, the size and the activity counters, which add up since the index was opened on its node.

The documents
The sample comes in the order the index stores them and gives the exact total. It only goes through the first 10,000 (index.max_result_window): beyond that the screen says so, and to go through a whole index there is the Query, which pages with search_after.

What you can write
New Index…, on the toolbar, opens the JSON of a new index, with one shard, no replicas and an empty mapping. Delete Index…, in the detail, asks naming the index and how many documents it has; it does not appear on a system index. In Documents, New Document… creates a document with the _id you type —if it already exists, the server rejects it and does not replace it— or with one from the server if you leave it empty. Edit Document… replaces the whole document: a field you remove in the sheet disappears. And only if nobody changed it since you read it; otherwise the server rejects it and does not overwrite the other change. Delete Document… asks naming its _id. Everything goes through the connection’s protection, and with the read-only tag none of this appears.

The slow log
Edit Slow Log Threshold…, in Settings, sets from how long a slow search is written to the log: the query phase and the fetch phase, each at warning and info. Type a time with its unit (500ms, 2s); -1 turns it off, and empty goes back to the default, which logs nothing.

OpenSearch

On OpenSearch the sheet also has the log level (index.search.slowlog.level).

Calíope does not keep the log: the server writes it. In a package install it goes to its logs directory (path.logs), to a file <cluster>_index_search_slowlog; in a container, to the container’s output (docker logs).

Templates and Pipelines
They belong to the cluster, not to an index, and are read only. Each row sums up the template (its patterns, its priority and which templates it is composed of) or the pipeline (its description and how many processors it has); open it to see its whole JSON. Legacy templates (_template) also appear, marked as such. Those the server declares its own and those starting with a dot are folded in their group. Calíope does not edit them: they are changed through the API.

What it does not do
There is no reindexing (_reindex) and no changing the type of an existing field: the server does not change the type of a field that already has data, and copying one index into another is a long server job started through the API.

キーワード: elasticsearch、opensearch、indices、index、mapping、settings、shards、aliases、documents、statistics、slow log、slowlog、templates、_index_template、pipelines、ingest、max_result_window

Cluster: health, nodes and unassigned shards

What green, yellow and red mean, how nodes are counted, what the roles are and how to read why a shard has no node.

場所: ワークスペース › ツール › Cluster

対象: Elasticsearch OpenSearch

The tab reads the cluster when it opens and with 更新; it does not refresh by itself, because the cluster does not announce its changes.

Health
At the top is the health with its glyph and its name, never just a color:

- green: every shard, primaries and replicas, has a node.
- yellow: every primary has a node, but some replica does not. Data is read and written in full; what is missing is the copy the replica would give if a node went down.
- red: some primary has no node, and the documents of that shard can be neither read nor written.

Below, how many nodes answer out of those the cluster expects. The count comes from the nodes the session has seen and from the cluster’s voting configuration, so a node that went down before connecting is counted too: it is named by its id, because nobody gives its name. Then the master (_cat/master) and the shards: active, relocating, initializing and unassigned. When a node goes down, its replicas wait one minute for it to return (index.unassigned.node_left.delayed_timeout) before being copied elsewhere, and the count says so in parentheses.

Nodes
One row per node with its roles, heap, RAM, CPU, load, disk, shards and version. Roles holds the letters of node.role: m master, d data, i ingest, r remote cluster client; the rest are data tiers. With the pointer over them they read in full.

Shards with problems
The shards that are not active: unassigned first, primaries before replicas and the user’s indices before system ones. The first unassigned one is explained with POST /_cluster/allocation/explain: Reason (for example NODE_LEFT, the node left), Can it be allocated? and what each node decides. Server explanation is the server’s text as is, in English. A common case: with two nodes, an index with two replicas has no room for the second, because a node does not keep two copies of the same shard (same_shard), and the cluster stays yellow until the third returns.

Queued cluster tasks and Recoveries in progress
The cluster tasks waiting their turn (_cat/pending_tasks) and the shard copies under way (_cat/recovery).

If a part could not be read, it carries its notice and the others are shown anyway. The tab only reads: it does not reallocate shards or change cluster settings.

キーワード: elasticsearch、opensearch、cluster、health、green、yellow、red、nodes、master、shards、unassigned、allocation explain、replicas、roles、node.role、pending tasks、recoveries

Node: the heap, the rates and the thread pools

What each card measures, why the heap warning starts at 75 %, why rates are differences between two reads and what a rejection in a thread pool means.

場所: ワークスペース › ツール › Node

対象: Elasticsearch OpenSearch

The tab reads the node when it opens and, while it is in front, every 5 s; switching tabs stops the reads. While it reads by itself, アクティビティ shows it as “Search node, every 5 s”. 更新 reads it right away.

Node
By default it is the node that answers the session. If the cluster has more than one, the picker lets you choose another.

The cards
- JVM heap: what is used over the maximum. From 75 % it carries a warning with a glyph and text: it is the threshold at which Elastic advises looking into memory pressure, because above it the JVM spends more time collecting and the circuit breakers, which cut a request before the node runs out of memory, are closer to tripping.
- Garbage collections: the young-generation and old-generation ones, with the time they took; old ones growing fast are the sign of a heap that cannot keep up.
- CPU: the machine’s and, below, the node process’s.
- Disk: used is the total minus what is available. From 85 % it carries a warning: it is the cluster’s low disk watermark (cluster.routing.allocation.disk.watermark.low), and above it the cluster stops allocating replicas to that node.
- Queries per second and Documents indexed per second: the first one with the average latency of the queries in the interval.

Rates are differences
The server only gives counters accumulated since the node started. A rate is the difference between two reads divided by the time between them by the node’s clock, so the first read says “Needs a second reading” and the figure comes with the next one. Below goes the total since start.

Thread pools
Each pool with its threads, the active ones, the queue, the rejected and the completed. When a pool’s queue is full, the node rejects the next request with a 429 instead of waiting. Pools with rejections stand out with a glyph, and idle ones are folded. Rejected and completed are counted since start: a high figure may be old, and what matters is whether it grows between reads.

Node details
The version, the roles, the address, the operating system, the processors, the JVM, the maximum heap, the paths and the plugins.

Hot threads
With Read hot threads the node samples for half a second and returns the three threads that used the most CPU. It is the server’s text as is, in English; with the node idle it only brings the header.

The tab only reads: it does not change node settings.

キーワード: elasticsearch、opensearch、node、jvm、heap、gc、garbage collection、cpu、disk、watermark、queries per second、indexing、thread pool、rejections、rejected、429、hot threads、plugins

Tasks: what runs in the cluster and how to cancel it

What the task tree shows, how often it is reread, which tasks can be cancelled and what the server answers when you cancel.

場所: ワークスペース › ツール › Tasks

対象: Elasticsearch OpenSearch

The tab reads the cluster’s tasks (GET /_tasks?detailed=true&group_by=parents) when it opens and, while it is in front, every 3 s; switching tabs stops the reading. While it reads on its own, アクティビティ shows it as “Search tasks, every 3 s”. 更新 reads them right away.

The tree
Each parent task carries its children underneath, ordered by how long they have been running. Each row gives the action, the description, the node by its name (or its id if the name is unknown) and how long it has been running. In a delete by query, an update by query or a reindex it also says how many documents it has done out of how many.

The filter
It matches the action or the description, ignoring case, and a parent stays if any of its children matches.

What is not offered for cancelling
- Asking for the list is itself a server task: it is marked “this list”.
- Persistent tasks (“persistent, the cluster’s own”) are marked cancellable by the server, but they belong to the cluster itself and are not offered.
- Tasks the server does not mark cancellable, tasks already asked to cancel and, on a read-only connection, all of them.

Cancel task
It asks first: the alert names the action, the description and the node, and Let it run lets it carry on. Cancelling asks the server to stop it as soon as it can; what it already did is not undone. The server always answers with success and the screen says what happened: that it marked the task cancelled, that the task had already finished or that its node is no longer in the cluster.

キーワード: elasticsearch、opensearch、tasks、_tasks、cancel、delete_by_query、update_by_query、reindex、persistent、node、progress

Snapshots: repositories, creating one and why restoring is not done here

What the tab shows of a repository and its snapshots, how to create one, how it is followed until it ends and how to restore by hand.

場所: ワークスペース › ツール › Snapshots

対象: Elasticsearch OpenSearch

The tab reads the server’s snapshot repositories (GET /_snapshot) and, for the chosen one, its snapshots (GET /_snapshot/<repository>/_all).

Repository
If the server has more than one, you choose it in the bar. Below it come its type and its settings; a setting that names a credential is masked (••••). With no repository at all, the screen says so: a repository is registered on the server (PUT /_snapshot/<name>), and an fs one needs its folder in path.repo on every node, in the server’s configuration. Calíope does not register repositories.

The snapshots
They go from newest to oldest. Each one gives its state with a glyph and in words (“Complete”, “In progress”, “Partial: some shard failed”, “Failed”), when it started, how long it took, its shards and its indices, and the failure of each shard that failed.

Take snapshot
It opens a sheet with the name and the indices. The proposed name carries the date and time (snapshot-YYYY.MM.DD-HHMMSS); it must be lowercase and without spaces, or the server rejects it and the sheet shows its reason. Indices are separated by commas and accept wildcards; empty means all of the cluster’s. An index that does not exist is skipped, and the global state (templates and cluster settings) is not included. Creating goes through the connection’s write guard: on a read-only one the button does not appear.

The sheet closes as soon as the server accepts the request, and アクティビティ follows the snapshot as “Search snapshot”, with the shards done as progress. It has no “停止”: stopping would leave it half done. The end is confirmed by the snapshot list, because OpenSearch takes a moment to report it finished. If it is still running after ten minutes, the screen says so and 更新 shows later how it ended.

Restoring is not offered
Restoring overwrites open indices and is decided outside a query tool. The foot of the list says so and writes the request to do it by hand: POST /_snapshot/<repository>/<name>/_restore.

キーワード: elasticsearch、opensearch、snapshots、_snapshot、repository、path.repo、create、restore、shards、backup