IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.
« Ingestion APIs Document enrichment with ML »
Elastic Docs ›

Ingest pipelines

edit

Ingest pipelines

edit

Ingest Pipelines are an Elasticsearch native tool which let you perform common transformations on data before storing it in Elasticsearch.

All ingest pipelines are composed of an ordered list of processors, which define the behavior of the pipeline.

Ingest pipelines in Enterprise Search

edit

In Enterprise Search, these can be particularly helpful by providing a layer of customization and post-processing of documents. For example:

  • providing consistent extraction of text from binary data types
  • ensuring consistent formatting
  • providing consistent sanitization steps (removing PII like phone numbers or SSN’s)

It can be a lot of work to set up and manage production-ready pipelines from scratch. Considerations such as error handling, conditional execution, sequencing, versioning, and modularization must all be taken into account.

To this end, when you create indices for Enterprise Search use cases (including Enterprise Search web crawler, connector, and API indices), each index already has a pipeline set up with several processors that optimize your content for search.

This pipeline is called ent-search-generic-ingestion. While it is a "managed" pipeline (meaning it should not be tampered with), you can view its details via the Kibana UI or the Elasticsearch API. You can also read more about its contents below.

You can control whether you run some of these processors. While all features are enabled by default, they are eligible for opt-out. For Enterprise Search web crawler and connectors, you can opt out (or back in) per index, and your choices are saved. For API indices, you can opt out (or back in) by including specific fields in your documents. See below for details.

At the deployment level, you can change the default settings for all new indices. This will not effect existing indices.

Each index also provides the capability to easily create index-specific ingest pipelines with customizable processing. If you need that extra flexibility, you can create a custom pipeline by going to your pipeline settings and choosing to "copy and customize". This will replace the index’s use of ent-search-generic-ingestion with 3 newly generated pipelines:

  1. <index-name>
  2. <index-name>@custom
  3. <index-name>@ml-inference

Like ent-search-generic-ingestion, the first of these is "managed", but the other two can and should be modified to fit your needs. You can view these pipelines using the platform tools (Kibana UI, Elasticsearch API), and can also read more about their content below.

Be aware that prior to 8.5, the Enterprise Search web crawler used different pipelines. See Upgrading notes.

Pipeline Settings

edit

Aside from the pipeline itself, Enterprise Search provides a few configuration options which control individual features of the pipelines.

  • Extract Binary Content - This controls whether or not binary documents should be processed and any textual content should be extracted.
  • Reduce Whitespace - This controls whether or not consecutive, leading, and trailing whitespaces should be removed. This can help to display more content in some search experiences.
  • Run ML Inference - Only available on index-specific pipelines. This controls whether or not the optional <index-name>@ml-inference pipeline will be run. Enabled by default.

For Enterprise Search web crawler and connectors, you can opt in or out per index. These settings are stored in Elasticsearch in the .elastic-connectors index, in the document that corresponds to the specific index. These settings can be changed there directly, or through the Kibana UI at Enterprise Search → Content → Indices → <your index> → Pipelines → Settings.

You can also change the deployment wide defaults. These settings are stored in the Elasticsearch mapping for .elastic-connectors in the _meta section. These settings can be changed there directly, or from the Kibana UI at Enterprise Search → Content → Settings tab. Changing the deployment wide defaults will not impact any existing indices, but will only impact any newly created indices defaults. Those defaults will still be able to be overriden by the index-specific settings.

Using the API

edit

These settings are not persisted for indices that "Use the API". Instead, changing these settings will, in real time, change the example cURL request displayed. Notice that the example document in the cURL request contains three underscore-prefixed fields:

{
  ...
  "_extract_binary_content": true,
  "_reduce_whitespace": true,
  "_run_ml_inference": true
}

Omitting one of these special fields is the same as specifying it with the value false.

You must also specify the pipeline in your indexing request. This is also shown in the example cURL request.

If the pipeline is not specified, the underscore-prefixed fields will actually be indexed, and will not impact any processing behaviors.

Details

edit

ent-search-generic-ingestion Reference

edit

As soon as Enterprise Search starts, this pipeline is automatically available to use. You can access it with the Elasticsearch Ingest Pipelines API or via Kibana’s Stack Management → Ingest Pipelines UI.

This pipeline is a "managed" pipeline. That means that it is not intended to be edited. Editing/updating this pipeline manually could result in unintended behaviors, or difficulty in upgrading in the future. If you want to make customizations, we recommend you utilize index-specific pipelines (see below), specifically the <index-name>@custom pipeline.

Processors

edit
  1. attachment - this uses the Attachment processor to convert any binary data stored in a document’s _attachment field to a nested object of plain text and metadata.
  2. set_body - this uses the Set processor to copy any plain text extracted from the previous step and persist it on the document in the body field.
  3. remove_replacement_chars - this uses the Gsub processor to remove characters like "�" from the body field.
  4. remove_extra_whitespace - this uses the Gsub processor to replace consecutive whitespace characters with single spaces in the body field. While not perfect for every use case (see below for how to disable), this can ensure that search experiences display more content and highlighting and less empty space for your search results.
  5. trim - this uses the Trim processor to remove any remaining leading or trailing whitespace from the body field.
  6. remove_meta_fields - this final step of the pipeline uses the Remove processor to remove special fields that may have been used elsewhere in the pipeline, whether as temporary storage or as control flow parameters.

Control flow parameters

edit

The ent-search-generic-ingestion pipeline does not always run all processors. It utilizes a feature of ingest pipelines to conditionally run processors based on the contents of each individual document.

  • _extract_binary_content - if this field is present and has a value of true on a source document, the pipeline will attempt to run the attachment, set_body, and remove_replacement_chars processors. Note that the document will also need an _attachment field populated with base64-encoded binary data in order for the attachment processor to have any output. If the _extract_binary_content field is missing or false on a source document, these processors will be skipped.
  • _reduce_whitespace - if this field is present and has a value of true on a source document, the pipeline will attempt to run the remove_extra_whitespace and trim processors. These processors only apply to the body field. If the _reduce_whitespace field is missing or false on a source document, these processors will be skipped.

Crawler, Native Connectors, and Connector Clients will automatically add these control flow parameters based on the settings in the index’s Pipeline tab. To control what settings any new indices will have upon creation, see the deployment wide content settings. See Pipeline Settings

Index-specific ingest pipelines

edit

In the Kibana UI for your index, by clicking on the Pipelines tab, then Settings -> Copy and customize, you can quickly generate 3 pipelines which are specific to your index. These 3 pipelines replace ent-search-generic-ingestion for the index. There is nothing lost in this action, as the <index-name> pipeline is a superset of functionality over the ent-search-generic-ingestion pipeline.

The "copy and customize" button is not available at all Elastic subscription levels. Refer to the Elastic subscriptions pages for Elastic Cloud and self-managed deployments.

<index-name> Reference

edit

This pipeline looks and behaves a lot like the ent-search-generic-ingestion pipeline, but with two additional processors.

You should not rename this pipeline.

This pipeline is a "managed" pipeline. That means that it is not intended to be edited. Editing/updating this pipeline manually could result in unintended behaviors, or difficulty in upgrading in the future. If you want to make customizations, we recommend you utilize the <index-name>@custom pipeline.

Processors
edit

In addition to the processors inherited from the ent-search-generic-ingestion pipeline, the index-specific pipeline also defines:

  • index_ml_inference_pipeline - this uses the Pipeline processor to run the <index-name>@ml-inference pipeline. This processor will only be run if the source document includes a _run_ml_inference field with the value true.
  • index_custom_pipeline - this uses the Pipeline processor to run the <index-name>@custom pipeline.
Control flow parameters
edit

Like the ent-search-generic-ingestion pipeline, the <index-name> pipeline does not always run all processors. In addition to the _extract_binary_content and _reduce_whitespace control flow parameters, the <index-name> pipeline also supports:

  • _run_ml_inference - if this field is present and has a value of true on a source document, the pipeline will attempt to run the index_ml_inference_pipeline processor. If the _run_ml_inference field is missing or false on a source document, this processor will be skipped.

Crawler, Native Connectors, and Connector Clients will automatically add these control flow parameters based on the settings in the index’s Pipeline tab. To control what settings any new indices will have upon creation, see the deployment wide content settings. See Pipeline Settings.

<index-name>@ml-inference Reference

edit

This pipeline is empty to start (no processors), but can be added to via the Kibana UI either through the Pipelines tab of your index, or from the Stack Management → Ingest Pipelines page. Unlike the ent-search-generic-ingestion pipeline and the <index-name> pipeline, this pipeline is NOT "managed".

It’s possible to add one or more ML inference pipelines to an index in Enterprise Search. This pipeline will serve as a container for all of the ML inference pipelines configured for the index. Each ML inference pipeline added to the index is referenced within <index-name>@ml-inference using a pipeline processor.

You should not rename this pipeline.

The monitor_ml Elasticsearch cluster permission is required in order to manage ML models and ML inference pipelines which use those models.

<index-name>@custom Reference

edit

This pipeline is empty to start (no processors), but can be added to via the Kibana UI either through the Pipelines tab of your index, or from the Stack Management → Ingest Pipelines page. Unlike the ent-search-generic-ingestion pipeline and the <index-name> pipeline, this pipeline is NOT "managed".

You are encouraged to make additions and edits to this pipeline, provided its name remains the same. This provides users a convenient hook from which to add their own custom processing and transformations for their Enterprise Search data. Be sure to read the docs for ingest pipelines so that you know what all is available to you here.

You should not rename this pipeline.

Upgrading notes

edit
  • app_search_crawler - Since 8.3, App Search web crawler has utilized this pipeline to power its binary content extraction. You can read more about this pipeline and its usage in the App Search Guide. When upgrading from 8.3 to 8.5+, be sure to note any changes that you made to the app_search_crawler pipeline. These changes should be re-applied to each index’s <index-name>@custom pipeline in order to ensure a consistent data processing experience. In 8.5+, the index setting to enable binary content is required in addition to the configurations mentioned in the App Search Guide.
  • ent_search_crawler - Since 8.4, the Enterprise Search web crawler has utilized this pipeline to power its binary content extraction. You can read more about this pipeline and its usage in the Enterprise Search web crawler Guide. When upgrading from 8.4 to 8.5+, be sure to note any changes that you made to the ent_search_crawler pipeline. These changes should be re-applied to each index’s <index-name>@custom pipeline in order to ensure a consistent data processing experience. In 8.5+, the index setting to enable binary content is required in addition to the configurations mentioned in the Enterprise Search web crawler Guide.
  • ent-search-generic-ingestion - Since 8.5, Native Connectors, Connector Clients, and new (>8.4) Enterprise Search web crawler indices will all make use of this pipeline by default. A natural evolution from app_search_crawler and ent_search_crawler, this pipeline is designed to meet more generic needs across Enterprise Search. You can read more about this pipeline above. As this pipeline is "managed", any modifications that were made to app_search_crawler and/or ent_search_crawler should NOT be made to ent-search-generic-ingestion. Instead, if such customizations are desired, you should utilize Index-specific ingest pipelines, placing all modifications in the <index-name>@custom pipeline(s).

FAQ

edit

Q: The Elasticsearch docs note that there are three types of ingest pipelines. "Request Pipelines", "Default Pipelines", and "Final Pipelines". Which does Enterprise Search use?
A: Enterprise Search utilizes Request Pipelines. This way, whether you are using Enterprise Search web crawler, a Connector, or an Elasticsearch API, it is explicit when a pipeline is part of the indexing request. It also leaves the door open for you to specify your own Final Pipeline without worrying about overriding anything coming from Elasticsearch.

Q: What if a processor fails in the ingest pipeline?
A: The ent-search-generic-ingestion and index-specific pipelines make use of "on failure" actions. In the event that a processor has a failure, the failing document will get a new field, _ingestion_errors, which contains information about what failed.

Q: What should I put in my <index-name>@custom pipeline?
A: The world is your oyster.

  • Some users might add additional Set processors to add metadata fields to their documents which were extracted by the Attachment processor.
  • Some users may add an Enrich processor to join their documents with data from other indices.
  • If you want your data to shout at you, throw in an Uppercase processor.
  • If no other processors seem to fit your need, you can do pretty much anything with a Script processor.

Find us in the discuss forums, and let us know what you get up to!

« Ingestion APIs Document enrichment with ML »