クラスタの健全性の探索とデータの作成

REST API編集
ノード(およびクラスタ)を起動して実行しました.次に、通信方法について説明します.幸いなことに、Elasticsearchはクラスタと対話できる非常に包括的で強力なREST APIを提供しています.APIを使用すると、次のようなことができます.

クラスタ、ノード、およびインデックスの動作状況、ステータスおよび統計を確認する

クラスタ、ノード、インデックスデータ、メタデータを管理する

インデックスに対してCRUD(作成、読み取り、更新、削除)および検索操作

を実行する.

ページ分割、ソート、フィルタリング、スクリプト作成、集約などの高度な検索操作を実行します.
 
 
 
クラスタの実行状況の編集
基本的な稼働状況チェックから始め、クラスタの稼働状況を表示できます.curlを使用してこの操作を行いますが、HTTP/REST呼び出しを許可するツールを使用することができます.Elasticsearchを起動した同じノードで別のコマンドshellウィンドウを開いたとします.
クラスタの稼働状況を確認するには、_cat APIを使用します.「コンソールの表示」をクリックするか、次の「COPY AS CURL」リンクをクリックして端末に貼り付け、Kibanaコンソールで次のコマンドcurlを実行します.GET/_cat/health?v応答:
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 1475247709 17:01:49 elasticsearch green 1 1 0 0 0 0 0 0 - 100.0%
 
「elasticsearch」という名前のクラスタが緑の状態にあることがわかります.
クラスタの健康を要求するたびに、緑、黄色、または赤を取得します.

緑-すべてが良い(クラスタ機能がそろっている)

イエロー-すべてのデータは使用可能ですが、コピーは割り当てられていません(クラスタ機能がそろっています)

赤-何らかの理由で使用できないデータ(クラスタ部分機能)

注:クラスタが赤色の場合、使用可能なスライスからの検索要求は引き続き提供されますが、未割当てのスライスがあるため、できるだけ早く修復する必要があります.
同様に、上記の応答から、合計1つのノードが表示され、まだデータがないため、0個のスライスがあります.注意してください.デフォルトクラスタ名(elasticsearch)を使用しているため、Elasticsearchはデフォルトでユニキャストネットワーク検出を使用して同じコンピュータ上の他のノードを検索するため、コンピュータ上の複数のノードを意外に起動し、すべての人が1つのクラスタに追加する可能性があります.この場合、上記の応答で複数のノードが表示される可能性があります.
 
クラスタ内のノードのリストも取得できます.GET/cat/nodes?v応答:

ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1           10           5   5    4.46                        mdi      *      PB2SGZY

ここでは、「PB 2 SGZY」というノードを見ることができます.これは、クラスタ内の現在の単一のノードです.
 
すべてのインデックス編集をリスト
指数を見てみましょう

GET / _cat / indices？v

 
応答:

      uuid pri rep docs.count docs.deleted store.size pri.store.size

これは、クラスタにインデックスがないことを意味します.
 
索引編集の作成
次に、customerというインデックスを作成し、すべてのインデックスを再度リストします.

PUT /customer?pretty
GET /_cat/indices?v

 
最初のコマンドは、PUT動詞を使用して「customer」というインデックスを作成します.呼び出しの末尾にprettyを追加し、JSON応答を印刷するように伝えます(あれば).
応答:

health status index    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   customer 95SQ4TSUT7mWBT7VNHH67A   5   1          0            0       260b           260b

2番目のコマンドの結果は、5つのプライマリスライスと1つのコピー(デフォルト)を持つcustomerというインデックスがあり、0つのドキュメントが含まれていることを示しています.
また、顧客インデックスに黄色の実行状況がマークされていることにも気づいたかもしれません.私たちの前の議論を思い出してみましょう黄色は、一部のコピーがまだ割り当てられていない(割り当てられていない)ことを示します.このインデックスが発生したのは、デフォルトでElasticsearchがこのインデックスのコピーを作成したためです.現在、1つのノードしか実行していないため、別のノードがクラスタに追加される遅い時点までコピーを割り当てることができません.(高可用性用).コピーを2番目のノードに割り当てると、インデックスの実行状況が緑に変わります.
 
 
索引と照会ドキュメントの編集
次に、お客様のインデックスにいくつかのコンテンツを追加します.以下に示すように、簡単な顧客ドキュメントを顧客インデックスにインデックスします.IDは1です.

PUT /customer/doc/1?pretty
{
  "name": "John Doe"
}

 
応答:

{
  "_index" : "customer",
  "_type" : "doc",
  "_id" : "1",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

上記のように、顧客インデックスに新しい顧客ドキュメントが正常に作成されました.このドキュメントの内部IDは1で、インデックス時に指定します.
Elasticsearchでは、ドキュメントをインデックスに組み込む前にインデックスを明示的に作成する必要はありません.前の例では、事前に顧客インデックスが存在しない場合、Elasticsearchは自動的に顧客インデックスを作成します.
インデックスに組み込まれたドキュメントを取得します.

GET /customer/doc/1?pretty

 
応答:

{
  "_index" : "customer",
  "_type" : "doc",
  "_id" : "1",
  "_version" : 1,
  "found" : true,
  "_source" : { "name": "John Doe" }
}

フィールドに加えて、ここには例外はありません.foundは、要求ID 1と別のフィールドを持つ_sourceドキュメントを見つけたことを宣言します.このドキュメントは、前のインデックスから完全なJSONドキュメントを返します.
 
索引編集の削除
作成したばかりのインデックスを削除し、すべてのインデックスを再度リストします.

DELETE /customer?pretty
GET /_cat/indices?v

 
応答:

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size

これは、インデックスが正常に削除されたことを意味し、クラスタに何もない場所に戻ります.
続行する前に、これまで学んだAPIコマンドをよく見てみましょう.

PUT /customer
PUT /customer/doc/1
{
  "name": "John Doe"
}
GET /customer/doc/1
DELETE /customer

 
上記のコマンドをよく検討すると、実際にElasticsearchでデータにアクセスする方法を見ることができます.このパターンは、次のようにまとめられます.

 ///

このRESTアクセスモードはすべてのAPIコマンドにおいて非常に一般的であり、それを覚えておくことができれば、Elasticsearchを把握する上で良いスタートを切ることができます.