検索アプリエンジニアの立ち位置視点で、Elasticsearchのモニタリング全般やテーブル構造(テーブルではありませんが...、たとえ話として）、インデックスに抱えているデータをマシンルームのような制限がある場所で（※そのような状況が良いかは別に置いておいて）、コンソール・ターミナルでカタカタ調べる場合に役立つElasticsearchのビルトインのエンドポイント(APIといった方が良いのかな?)をまとめました。
公式Rをある程度なぞった程度にすぎませんし、他のチートシートやテック記事に比べると深さ不足ですが、
- しばしば担当を離れていた検索サイトで「検索の当たり方が悪い」というクレームが発生して、レスキューに入ることになった。 *（それが良いか悪いかはともかく）Elasticsearchにしばらくふれておらず、調査の勘所を思い出すにも、急遽駆けつけてくれと無理筋オーダーで現地に向かうことになった。
- 隔離されたマシンルームは何かと不便（それが良いか悪いか、セキュリティ等のルールだから当然なのか、ルールごっこにすぎず不条理かは問わず事実として。）
- アシスタントはおらず、自身が担当を離れる際には整備されていたドキュメントやなんらかのノウハウも破棄されている。
というシーンをイメージして、ストーリー立ててみています。
よって、サーバが停止しているといった類のトラブルシュートをイメージしたものではないので、インフラ系の確認はあえて（ぼろが出るので）少なめにしているというのがある種ウリ(?)のまとめです。
↓下記図のようなところを手早く把握しましょうという意図でまとめました。*1
- プラグインのインストール状況の確認
- インデックスの一覧
- インデックスまわりの設定全般
- エイリアス
- settings、mappings、aliasesの3点セットでの一括確認
- この項目検索できるよねの確認(capability)
- あるインデックスのフィールド項目の一覧
- インデックスのデータ
- その他のコンフィグ
- アナライザー(Japanese(kuromoji) Analysis Plugin)のインストール&設定状況
- おわりに
確認したElasticsearchのバージョンは6.4です。
ターミナルでカタカタと言いましたが、無駄にパラメータが長くなるので、HTTPメソッドとパスのみ（例えるならkibanaのDev Toolsでのクエリ発行の形式）の表記にしています。
プラグインのインストール状況の確認
インストールされているプラグインによってはデフォルト動作等が変わってしまうところもあるので確認しておきます。
GET /_cat/plugins?v
インデックスの一覧
次のメソッドでインデックスの一覧が確認できます。
ヘッダー的なものが付いていないのでわかりにくいですが、ドキュメント件数やデータ容量的なものも実は確認できます。
GET /_cat/indices?v
特定のインデックス狙い撃ちで確認もできます。↓
GET /_cat/indices/your_index_med
ここでは、「your_index_med」が今注目しているインデックスとしました。
インデックスまわりの設定全般
GET your_index_med?flat_settings
↑で軽く俯瞰しておいて。
↓で詳細（デフォルト等）を確認します。
GET /your_index_med/_settings?flat_settings=true&include_defaults
インデックスのマッピング設定
GET /your_index_med/_mapping?filter_path
インデックスのマッピング設定（フィールド別）
GET /your_index_med/_mapping/field/*_ja?include_defaults=true
「field」の次のところがフィールド名です。ワイルドカードやカンマ区切りで複数指定が可能です。
include_defaults=true を付けるとデフォルト設定も得られます。
エイリアス
GET /_cat/aliases?v
settings、mappings、aliasesの3点セットでの一括確認
GET /your_index_med
最初からこれでいいじゃん(笑)。
というところですが、一括だと、結構な量になるのと、久々だと頭に入ってこないので...。
この項目検索できるよねの確認(capability)
GET /your_index_med/_field_caps?fields=*_ja
あるインデックスのフィールド項目の一覧
Elasticsearchでは歴史的経緯もあって、タイプと呼ぶのかスキーマと呼ぶのか、そもそも最近のバージョンではインデックスのフィールドと呼んだ方が良いのか悩ましいですが、とにかくそれの把握です。
というところなんですが、上の方で出てくるmappingですでに取得はできていますし、普通はそこで確認済みでしょう。
一方、mapping全部は場合によっては少々読みづらいので、jqコマンドにパイプしたりしてということも考えられますが、製品標準だと、filter_pathを指定すると、気持ち応答内容の階層や項目が絞られてフォーカスしやすくなります。RDBMSでのDESCコマンドに近くなりますね。
例としては、
フィールドの一覧とそのデータタイプ GET your_index_med/_mapping?filter_path=**.*.*.type フィールドの一覧と適用されるアナライザー GET your_index_med/_mapping?filter_path=**.*.*.analyzer
「*」はワイルドカードですが、実のところfilter_pathの指定の方法は私はよく分かっていません。雰囲気で使っています(笑)。
ちゃんと確認したい方は、
↓ [参考] filter_pathの設定方法についてはこちらです。
Common options | Elasticsearch Reference [6.5] | Elastic
POST /your_index_med/_search
{
"size":1,
"query": {"match_all": {}},
"sort": [
{
"_id": {
"order": "desc"
}
}
],
"_source": ["_id"]
}
GET /your_index_med/_doc/取得したID?_source
インデックスのデータ
件数
GET /_cat/count/your_index_med?v または GET /your_index_med/_count
統計情報
GET /your_index_med/_stats
実は、件数などここまで見た情報はひととおり確認できそうです。
加えて、検索回数やキャッシュ情報なども見れそうです。
確認できる情報ブロックの最上位プロパティの一覧を引用しておきます。
- docs
- store
- indexing
- get
- search
- merges
- refresh
- flush
- warmer
- query_cache
- fielddata
- completion
- segments
- translog
- request_cache
- recovery
データ量
GET /_cat/fielddata?v
fielddata設定がされているfieldとその使用量(?)がわかります。
本来は、インフラ・パフォーマンスチューニングの視点で確認するかもしれませんが、ここではfielddata設定されている項目の一覧を俯瞰で確認できるというアプリ寄りの視点で確認することにしました。
その他のコンフィグ
エイリアス: 再掲
GET /_cat/aliases?v
テンプレート
GET /_cat/templates?v
インデックステンプレートの一覧です。
インデックステンプレートは、インデックス名とのパターンマッチによってあるデータが登録される際にどのインデックステンプレートが適用されるかが決まります。
地味ながら、この問い合わせでは、実際に設定されているインデックステンプレートの一覧とともに、そのパターンマッチの正規表現の一覧が確認できるので、想定外のテンプレートがマッチしてしまったのではという切り分けの最初のステップとしては悪くないビュー確認になると思います。
ちなみに、index_patternsというプロパティ名で表されます。
個々の設定は、
GET /_template/mytemplate_1
のように、templateエンドポイントに、インデックステンプレートの名前を引き渡してやると確認できます。
パイプラインの一覧
パイプラインはそこまで関係ないですが、存在は確認しておきましょう。
GET /_ingest/pipeline
アナライザー(Japanese(kuromoji) Analysis Plugin)のインストール&設定状況
このあたりで、ついに（やっと)、アナライザーを確認してみようとうことにしますが、ひとまずkuromoji-pluginに観点を絞ります。
GET your_index_med?flat_settings
返って来た値のひとまず次を確認しておきましょう。 （他にも重要なポイントがあるでしょうし、私見ではkuromojiについては全部の設定をONにした方が良いのではと考える派ですが、下記の点は「当たらない」系トラブルに特にきいてくるようなものをあげたつもりです。
- kuromoji_tokenizer の周辺にある、modeプロパティの値が、normal, search, extendedのどれか。(個人的にはsearchが嬉しい）
- 対象の検索サイトが動詞や形容詞、副詞でもそれなりに検索させるサイトの場合、あるいは今回のトラブルシュートとしてあげられている例がこれらの品詞を含む検索ワードの例の場合、"kuromoji_baseform"が、filter プロパティの配列に入っているか。また、"kuromoji_stemmer"がfilterプロパティに設定されているか。
- "romaji_readingform","katakana_readingform"が、filter プロパティの配列に入っているか。前項に比べると単純に確認の意味。
おわりに
冒頭に書いた、「検索のヒット」のトラブルシューティングのくせに、検索を試してみるところまで行っていませんが、長くなったので一旦これまで。
補足
メイン稿の中では触れませんでしたが、catエンドポイントについては、おまじないのように「?v」というクエリパラメータをつけています。
これは verboseのvで、これを付けるとヘッダー行が表示されます。
また、
クエリパラメータとして、
help
を付けると、ヘッダー行に示されている各項の説明が確認できます。
