@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.

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".

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

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.

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.

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

How about:

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

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

++ I'l make that change.

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.

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

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.

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

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.

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

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