The ES Restful API, a total of four types of the API: 1. Check the cluster nodes, and other health indices or not, and obtain their respective state. 2. management cluster, node, and metadata of the index 3. CRUB operation performed (i.e.: deletions change check) 4. perform advanced operations, such as: paging, filtering and the like. ES API access interface: TCP: 9200, and ES is based on the HTTP protocol works. Curl -X < Verb > ' < Protocol > : // Host: Port / < Path > ? < Query_String > ' -d ' < Body > ' Note: Verb: That operation of HTTP, GET, PUT, DELETE and so on. Protocol: HTTP, HTTPS path: access path. Query_String: query parameters, such as:'? pretty ': indication easy to read format JSON output. Body: The body of the request. Such as viewing the status of node1: -X GET curl 'http://1.1.1.1:9200/?pretty' ES API interface: _cat API: View ES cluster status: curl -X GET 'http://1.1.1.1:9200/_cat/nodes ? v ' Note: _cat: this is the name ES API interface, generally use ES API interface name begins with an underscore. function of this interface is the output displayed. ? v: question mark v, is a modifier, v: is verbose, show details. ? help: to display help information. ? h = name, ip, port , uptime, heap.current: definable display those columns. curl -XGET 'http://1.1.1.1:9200/_cat/indices' # See all index information ES cluster curl localhost : 9200 / _cat / indices s # default can be omitted S, S:? status curl localhost: 9200 / _cat / # Help indices can view supported query keywords? View ES cluster health status details: : _cluster APIs stats: curl -X GET 'http://1.1.1.1:9200/_cluster/health?pretty' health status index View: Health curl -X GET 'http://1.1.1.1:9200/_cluster/health/ index name 1 , index name 2, ... ' ? curl -X GET' http://1.1.1.1:9200/_cluster/health/ index name 1 level = level ' Note: cluster: is displayed to the cluster level indices: the index level display shards: fragmentation level view cluster status information: state: curl -X GET 'http://1.1.1.1:9200/_cluster/state/version' curl -X GET 'http://1.1.1.1:9200/_cluster ? / State / master_node Pretty ' curl -X GET' http://1.1.1.1:9200/_cluster/state/nodes?pretty ' view statistics for the cluster: curl -X GET 'http://1.1.1.1:9200/_cluster/stats?pretty'
View cluster node status information:
# curl 192.168.10.80:9200/_cat/nodes?v
heap memory% of the total memory% CPU 1 for 5 minutes 15 minutes * role: the master node node name
ip heap.percent ram.percent cpu load_1m load_5m load_15m Master name node.role
10.2.2.81 14 87 0 0.14 0.12 0.11 MDI - node81
10.2.2.80 27 95 0 0.02 0.02 0.00 * MDI node80
# curl 192.168.10.80:9200/_cat/health?v
Epoch timestamp Cluster Node Status node.total Shards PRI ReIO the init Unassign .data pending_tasks max_task_wait_time active_shards_percent
1,564,141,337 11:42:17 myes1 Green 20 is 0 0 2 2 40 0 0 - 100.0%
# Here you can see all the current Index (index) of state statistics, through it, can be obtained if there are red or yellow clusters in the current ES Index, if so,
It is required by the following _cluster / Health? Level = indices & Pretty to view the details of the specific fragment Index. curl 192.168.10.80:9200/_cat/indices?v
# View Index fragmentation status information # curl "localhost: 9200 / _cluster / Health Level = indices? & Pretty " { "CLUSTER_NAME": "myes1", "Status": "Green", # status of the entire ES cluster of green, because of the status of all the following Index is green, if any state in which there is a non-Index of Green, then the status of the entire non-ES will be Green. "TIMED_OUT": to false, "number_of_nodes This is": 2, "number_of_data_nodes": 2, "active_primary_shards": 20 is, "active_shards": 40, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 0, "delayed_unassigned_shards ": 0, " number_of_pending_tasks ": 0, ".kibana_task_manager": { "Status": "Green", .kibana_task_manager this Index # current status is green. # If the Index is usually the fragment appears lost, the status will be red or Yellow: #red: it means that there is a master slice missing! yellow: it means that a copy of the fragment is lost! ! But still readable master slice "number_of_shards": 1, the number 1 is #shard, i.e. sliced into a "number_of_replicas": 1, # 1 fragment copy number, the copy number of fragments determined number shard If it is not the same as the number of the shard, the state must not Index Green: "active_primary_shards":. 1, the number of currently active primary # slice "active_shards": 2, # is the number of fragments that all currently active " relocating_shards ": 0, # is the number of slices according to scheduling assignment [literally, not quite right} " initializing_shards " "unassigned_shards": 0 # Number fragments unassigned }, ...........................
# View shard shards that slice is not allocated, and it is lost on the Node slice the
# curl: "localhost 9200 / _cat / Shards v & Pretty?"
# Shard: it represents the index fragmentation ID
# prirep: This is primary and replica fragmentation fragments, wherein: p: represents a primary slice, r: represents a copy of slice
# state: this state may have these types of: relocating, initializing, Started, unassigned , wherein this represents an unassigned assignment, if this state, we need to pay attention.
# Docs and store: This Index is the number of documents under the docs and occupied disk space.
The reason ElasticSearch clusters appear Red and Yellow states
Reference link: https: //www.jianshu.com/p/74fe89ab4af7
cluster RED and YELLOW is one of the most common Elasticsearch cluster problem.
No matter RED or YELLOW, only one reason: some fragments are not allocated, and even if only a cluster can lead to failure.
red: it said main fragment not assigned!
yellow: it means that there is a copy of the fragment is not assigned! ! But still readable master slice
for problem diagnosis cluster RED YELLOW or recommended Cluster Allocation Explain API, the API is the specific cause of the unallocated fragments can be given.
For example, the following request to return the first unassigned fragment specific reasons:
curl -XGET localhost: 9200 / _cluster / Allocation / EXPLAIN Pretty?
When a cluster RED or YELLOW, generally we first need to look at whether there are nodes offline.
Individual but also results in fragmentation unallocated state to the cluster or RED YELLOW, some common unallocated following reasons:
• problems caused due to configuration necessary to correct the corresponding configuration
• caused since the node is offline, the node need to restart offline
• Since fragmentation rules limit, e.g. total_shards_per_node, or disk space restrictions, the rules need to be adjusted accordingly
• the main time slice allocation, unable to find the latest data fragmentation, fragmentation causes the main unallocated, to observe such is there a node offline,
in extreme cases can manually modify the old copy of the fragment-based slice, but this results in the loss of some of the new data storage.
Curl # "? Localhost: 9200 / _cat / v Shards & Pretty " | grep unassingned # If the above query appeared unassingned, you can pass the following command to view the index fragmentation is what causes unallocated curl -sXGET localhost: ? 9200 / _cluster / Allocation / EXPLAIN Pretty -d '{ "index": "myindex", may be specified index # name "shard": 3, # specify Shard to view (tile) number "Primary": to true }' # If the output is: { "index": "myindex", "Shard": 0, "Primary": to true, "the current_state": "Unassigned", .............. }, "can_allocate" : "no_valid_shard_copy", "allocate_explanation" : "cannot allocate because all found copies of the shard are either stale or corrupt",
# Can not be assigned because all copies of fragments have been found worn or damaged
...........................
# This error may understood as:
elasticsearch find this slice of data on disk, but due to data fragmentation not up to date, can not be assigned based slices. The method of allocating slices
if they know which index fragment which is missing or damaged, repair started manually, by allocating allocate reroute the
curl -XPOST '{ESIP}: 9200 / _cluster / reroute' -H "content-type: application / JSON "-d '{
" Commands ": [{
" the allocate ": {
" index ":" eslog1 ",
" Shard ":. 4,
" Node ":" ES1 ",
" allow_primary ": to true
}
}
]
}'
When a cluster is not the same version es, if the slice is not allocated a high version generated version can not be assigned to the low node, in turn, a low version of slices may be allocated to a higher version,
If you have, as long as the upgrade version of the low node ES version can
(ES upgrade version See the official detailed documentation, I am apt to install ubuntu system, direct apt-get install elasticsearch upgrade, elasticsearch.yml
Do not modify the configuration file has not changed, but the / usr / share / elasticsearch / bin / elasticsearch file has a memory configuration ES_HEAP_SIZE = 6G need to manually add it & reboot es)
[] Taken from the network
with a first slice # reasons not assigned the following types:
1. INDEX_CREATED
because create index api create indexes lead, the index creation process, the whole part of the index sheet dispensing a process is completed,
Before the whole portion of slice allocation is completed, the index will be at or RED YELLOW transient state. So if you find a cluster monitoring system RED, does not necessarily mean there has been a failure.
2. CLUSTER_RECOVERED
the cluster complete restart, all fragments are marked as unassigned, and therefore the starting phase when a complete restart of the cluster, this belongs to the reason type.
INDEX_REOPENED 3.
Open a previous index close, reopen operation will index assignment reallocation.
4. DANGLING_INDEX_IMPORTED
are importing a dangling index, what is dangling index?
The presence of the disk, and the cluster index does not exist in a state called dangling index, for example, a copy of the index to the current cluster data directory from other clusters,
This index will Elasticsearch loaded into the cluster, thus involves processes for the dangling index assigned slices.
5. NEW_INDEX_RESTORED
restore from a snapshot to a new index.
6. EXISTING_INDEX_RESTORED,
restore from a snapshot to index a closed state.
7. REPLICA_ADDED
increased copy fragment.
8. ALLOCATION_FAILED
since allocation failure cause.
9. NODE_LEFT
Since the node is offline.
10. REROUTE_CANCELLED
Since explicit cancel reroute command.
11. REINITIALIZED
Since the transition from the fragmentation started initializing state to state.
12. REALLOCATED_REPLICA
due to migration of the copy fragment.
13. PRIMARY_FAILED
initialization sub-time slice, the master slice failure.
14. FORCED_EMPTY_PRIMARY
forced empty assigned a master slice.
15. MANUAL_ALLOCATION
Manually force distribution fragmentation.