Count the fields in an Elasticsearch index

Inspect mappings and count nested fields, multi-fields, aliases, and runtime fields without confusing top-level properties with the mapping limit.

Best practices
Data organization and search illustration

Retrieve the index mapping first. Counting the keys directly under mappings.properties tells you how many top-level entries it has, not how much of the total-field limit it uses.

Inspect the mapping

In Dev Tools:

GET your_index/_mapping

For a local, unsecured test cluster, count only top-level properties with:

curl -fsS 'http://localhost:9200/your_index/_mapping' \
  | jq '.[].mappings.properties | length'

Use your deployment's HTTPS and authentication settings for a real cluster. Objects, their children, and multi-fields such as message.keyword make a recursive count larger than this top-level result.

Count common mapping entries recursively

import requests

response = requests.get(
    'http://localhost:9200/your_index/_mapping', timeout=10
)
response.raise_for_status()

def count_fields(properties):
    total = 0
    for definition in properties.values():
        total += 1
        total += count_fields(definition.get('properties', {}))
        total += count_fields(definition.get('fields', {}))
    return total

for index, details in response.json().items():
    mapping = details.get('mappings', {})
    ordinary = count_fields(mapping.get('properties', {}))
    runtime = len(mapping.get('runtime', {}))
    print(index, 'mapped entries:', ordinary,
          'top-level runtime fields:', runtime,
          'reference total:', ordinary + runtime)

This includes object and nested containers, their children, multi-fields, and aliases represented in properties. It separately counts top-level mapped runtime fields. Treat the result as an estimate for common mappings: advanced structures such as composite runtime fields need version-specific accounting. It is not an authoritative replacement for Elasticsearch's own limit enforcement.

Investigate mapping growth

The documented default for index.mapping.total_fields.limit is 1,000. Dynamic keys, such as a different field name for each user ID, can exhaust that limit. By default, indexing a document that would add too many mapped fields fails. index.mapping.total_fields.ignore_dynamic_beyond_limit changes how excess dynamic fields are handled.

Use stable field names with variable values. Depending on query needs, consider flattened, dynamic: false, dynamic: strict, or an object with enabled: false. Mapping every new key as keyword still allows unbounded key growth. Raising the limit also increases resource exposure.

Existing ordinary field mappings cannot simply be removed. Correct the producer or mapping policy, then use a new index and reindex where necessary.

Compare mappings with field capabilities

_mapping describes definitions. _field_caps?fields=* summarizes searchable and aggregatable field capabilities and helps identify type conflicts across indices. Neither the number of names returned across many indices nor a data view's field list is the field-limit usage of one index.

See Elastic's mapping limit settings.

Related: Count Prometheus requests over a time period and Fix a 413 request-body error (Chinese).

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting