Update Elasticsearch exporter documentation

[inge4pres]

Clarified configuration options for sending queue and batcher settings in the Elasticsearch exporter documentation.

Closes #10584

What does this PR do?

Why is it important?

We are not specifying correctly how batching should be configured in each stack release of EDOT.

Checklist

• I have read and understood the pull request guidelines of this project.
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool
• I have added an integration test or an E2E test

Disruptive User Impact

How to test this PR locally

Related issues

• Closes Docs: elasticsearchexporter batcher config vs sending_queue.batch #10584

Questions to ask yourself

• How are we going to support this in production?
• How are we going to measure its adoption?
• How are we going to debug this?
• What are the metrics I should take care of?
• ...

[mergify]

This pull request does not have a backport label. Could you fix it @inge4pres? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[elasticmachine]

Pinging @elastic/ingest-docs (Team:Docs)

[carsonip]

This is not technically correct. In previous versions, sending_queue and batcher are both supported, but they are separate configs configuring the queue and batch correspondingly.

[inge4pres]

Ok makes sense thanks - I thought sending_queue was a replacement for batcher, but no it's another setting on top.

How would you rephrase it?

[carsonip]

this paragraph (and the header) should focus on batcher and state that to keep the interaction async after enabling batcher, one should enable sending queue.

[inge4pres]

thanks I only have one doubt: sending_queue does not seem to be aviable before v0.132.0.
if that's correct, we should not include a sending_queue section for 9.0 and 9.1.

I was thinking to structure the document with separate sections about sending queue and batching, but only if sending queue is available in 9.0 and 9.1

[inge4pres]

nvm I just re-read the docs in the upstream repo, sending_queue was supported in older versions too.
I'll update with dedicated sections

[carsonip]

this paragraph (and the header) should focus on batcher and state that to keep the interaction async after enabling batcher, one should enable sending queue.

[carsonip]

The first sentence kind of implies that sending queue was not supported in the past, which is not true. The key change in 9.2 (i'm not sure off the top of my head) is that we also support sending_queue::batch

[inge4pres]

Thanks, makes more sens after reading the previous comments too.
Let me rephrase it.
I wonder: if this distinction is not so clear from the upstream repo docs, should we also amend there?

[github-actions]

🔍 Preview links for changed docs

• docs/reference/edot-collector/components/elasticsearchexporter.md

[inge4pres]

With last commit i separated the sending_queue and batching sections completely, after learning what sending_queue is via the OTel docs.

@carsonip @lahsivjar please let me know if a corresponding change should be in the upstream docs 🙏🏼

[inge4pres]

@theletterf please kick in with the tabs magic if you think the applies_to are too clumsy

[carsonip]

I'm refraining from nitpicking too much. With this PR it should be a net improvement over the existing docs.

[carsonip]

@theletterf is it the best practice to backport doc changes? I thought docsv3 are only published from main.

[theletterf]

@carsonip That's right, but we recently had some issues with the release notes process if docs weren't synced. +CC @colleenmcginnis do you know if we need to continue backporting docs changes for the time being?

[lahsivjar]

SGTM (other than the comment by Carson on sending_queue::batch::enabled! For future/next release, we have enabled sending queue by default in ES exporter from v0.138.0.

[inge4pres]

For future/next release, we have enabled sending queue by default in ES exporter from v0.138.0.

Oh so when we get an upgrade in Elastic Agent for the component, we have to update the docs again?!?
Is there a better way of handling this?
Ideally, the doc should be in a single place (upstream) and then we only add vendor-specific details for EDOT.

[lahsivjar]

Oh so when we get an upgrade in Elastic Agent for the component, we have to update the docs again?!?

Yes 😢

Ideally, the doc should be in a single place (upstream) and then we only add vendor-specific details for EDOT.

I agree 💯 . We could still do this and open PRs to upstream docs if they are not sufficient.