The analysis workbench: run the server’s tokenizers, normalizers, token filters and analyzers over sample text and see the exact token stream — the same components the indexing path uses, so what you debug here is exactly what collections run. The analysis chain decides what is searchable: query and document must reduce to the same tokens.
Every analyzer is assembled from three stages, run in this order:
...The server ships 83 analyzers, 50 tokenizers, 15 normalizers and 327 token filters, registered at startup. The authoritative, always-current list on YOUR node is:
GET /_analysis/components
Components are referenced by name — in a field’s schema
("analyzer": "english"), in a
custom analyzer
definition, or in an ad-hoc
_analysis/analyze pipeline.
The catalog is assembled in two layers. The engine core registers the
minimal set that is always present: the standard and whitespace
tokenizers, the lowercase normalizer, the lowercase/uppercase/
stopwords token filters, and the two named analyzers composed from
them (standard, whitespace). Every other name below comes from the
~40 analysis plugin crates under contrib/analysis-*, registered at
startup in one pass — foundation plugins first (core, stemmers,
icu), then the CJK and per-language plugins, which intentionally
override the basic analyzers from core with richer pipelines
(language stop words, normalization, stemming).