Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save rbcmgs/a48417e675f73b41391370eb1df88eea to your computer and use it in GitHub Desktop.

Select an option

Save rbcmgs/a48417e675f73b41391370eb1df88eea to your computer and use it in GitHub Desktop.
This document provides a concise cheat sheet for basic index management commands tailored for use within the Kibana Dev Tools console, facilitating common tasks in Elasticsearch clusters such as cluster health checks, index creation, modification, deletion, and more. These commands cover essential maintenance and operational tasks, making them i…

1. Check Cluster Health

This command retrieves the health status of your Elasticsearch cluster, indicating its operational state with a color code (green, yellow, or red).

GET /_cluster/health

2. List All Indices

To view a list of all indices currently present in your Elasticsearch cluster, including their health, status, and primary and replica shard counts.

GET /_cat/indices?v

3. Create an Index

This operation creates a new index named myindex, specifying the desired number of primary shards (number_of_shards) and replica shards (number_of_replicas) for redundancy and performance.

PUT /myindex
{
  "settings": {
    "index": {
      "number_of_shards": 3,
      "number_of_replicas": 2
    }
  }
}

Remember to replace myindex with the specific name you wish to give to the new index.

4. Delete an Index

Deletes the specified index (myindex) from the cluster, removing all data and configurations associated with it. Use with caution, as this operation cannot be undone.

DELETE /myindex

5. Update Index Settings

You can update configurations of an existing index, like changing the number of replica shards. This command adjusts the number_of_replicas for the index myindex.

PUT /myindex/_settings
{
  "index": {
    "number_of_replicas": 1
  }
}

Note: Not all index settings can be updated on a live index.

6. Index Status

Retrieves detailed statistics and information about a specific index, including document counts, storage size, and more.

GET /myindex/_stats

7. Close and Open Index

Closing an index disables write and read operations for maintenance or configuration changes, while opening it makes it accessible again.

To close an index:

POST /myindex/_close

To open the index after maintenance or configuration changes:

POST /myindex/_open

8. Refresh an Index

Forces a refresh on the specified index, making all operations performed on the index up to that point available for search.

POST /myindex/_refresh

9. Force Merge an Index

Triggers a force merge operation on an index to reduce the number of segments by merging them. Specify max_num_segments to control the merge target. Use with care, as this operation is resource-intensive.

POST /myindex/_forcemerge?max_num_segments=1

10. Rollover an Index

The rollover API rolls an alias over to a new index when the existing index meets the specified conditions, such as age (max_age) or size (max_docs). It's useful for managing index size and performance in a time-based data lifecycle.

POST /myalias/_rollover
{
  "conditions": {
    "max_age": "7d",
    "max_docs": 1000
  }
}

In this case, replace myalias with the appropriate alias name.

11. Snapshot and Restore

Snapshotting is pivotal for data backup. This sequence covers creating a snapshot repository, taking a snapshot, and restoring it.

  • Create a Snapshot Repository: Specifies a file system location (/path/to/backup) for storing snapshots. Replace my_backup with your repository name and adjust the location.
PUT /_snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/path/to/backup"
  }
}
  • Take a Snapshot: Creates a snapshot of your cluster, designated as snapshot_1 in this example, within the specified repository. The wait_for_completion=true query parameter makes the request await the snapshot's completion.
PUT /_snapshot/my_backup/snapshot_1?wait_for_completion=true
  • Restore from a Snapshot: This command initiates the restoration process from a specified snapshot (snapshot_1 in this case) in the my_backup repository.
POST /_snapshot/my_backup/snapshot_1/_restore
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment