[DOCS] Add field extraction use cases to scripting docs

[lockewritesdocs]

This PR adds a new page for common scripting use cases as part of a larger effort in #71576. This PR adds field extraction use cases for writing scripts that:

• Extract an IP address from a log message
• Parse a string to extract part of a field
• Split the values in a field by a specific separator

Preview link: https://elasticsearch_71596.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/common-script-uses.html

Relates to #71576

[elasticmachine]

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

[lockewritesdocs]

run elasticsearch-ci/docs

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[lockewritesdocs]

@nik9000, all of this explanatory information is fine here for now, but I plan on pulling the dissect docs out of ingest processor and into the scripting docs in #72580, and then putting this more detailed information there.

[nik9000]

I tend to avoid the word "use case". I think folks don't think of themselves as having a use case. They've got a thing they want to do, but they don't call it a "use case".

[lockewritesdocs]

True -- I think we can just say, "The goal of field extraction is simple..."

[nik9000]

It is a regular expression, just a kind of unexpected dialect. May be more correct to say "is a regular expression dialect that supports aliased expression reuse." - no need to explain that it sits "on top", I guess, if you say it that way.

[lockewritesdocs]

I'm +1 on that revision, but I still think it's valuable to call out the 1-to-1 mapping of regex in grok. Something like:

Grok is a regular expression dialect that supports aliased expressions that you can reuse. Because Grok sits on top of regular expressions, any regular expressions are valid in grok as well.

[nik9000]

"extracts structured fields out of text using a pattern that defines delimiters"?

[lockewritesdocs]

How about:

Dissect extracts structured fields out of text, using delimiters to define the matching pattern. Unlike grok, dissect doesn't use regular expressions.

[nik9000]

s/doesn't crash/doesn't emit anything/?

[lockewritesdocs]

++ I'l make that change.

[nik9000]

You only need to declare something "NOCONSOLE" if the paranoid "is this json?" detector fails the build if you don't add the tag. Try removing this - if the build succeeds then you don't need it. I don't think you need it here.

[lockewritesdocs]

You're right! I removed both mentions of //NOTCONSOLE and local checks all passed.

[nik9000]

This is a good thing for debugging but not super useful in production. In production you'll want to just emit(gc.usize) or something, right? Worth pointing out.

[lockewritesdocs]

Why is this not useful in production? Is it too slow or just not something that people would typically want to do?

[nik9000]

Yeah, its somewhat more slow than returning just the number you need, but I think the bigger thing is that folks will typically want to have range queries for the numbers or do math with them or group them with aggs or something - basically if you get numbers I think typically you want to extract them as long or double. But what you've got it useful to look at, especially because we don't yet have a way to emit all of the extracted values at once. When we have that I think it'd be easier to have folks do that and fetch them all in the fields, even when they are just looking at things.

[nik9000]

This is [source,painless]. I don't know that it makes a difference, but it is painless code.

[lockewritesdocs]

Good eye -- I'll change that to [source,painless].

[nik9000]

LGTM