Update logs docs for consistency and formatting #3183
Conversation
mdbirnstiehl
added
backport-8.9
|
A documentation preview will be available soon: |
| === Use an ingest pipeline to extract the `@timestamp` | ||
|
|
||
| To extract the `@timestamp` field from the example log, use an ingest pipeline with a dissect processor. Ingest pipelines in {es} are used to process incoming documents. The {ref}/dissect-processor.html[dissect processor] is one of the available processors that extracts structured fields from your unstructured log message based the pattern you set. In the following example command, the dissect processor extracts the timestamp to the `@timestamp` field. | ||
| Ingest pipelines consist of a series of processors that perform common transformations on incoming documents before they are indexed. To extract the `@timestamp` field from the example log, you can use an ingest pipeline with a dissect processor. The {ref}/dissect-processor.html[dissect processor] extracts structured fields from unstructured log messages based on a pattern you set. |
There was a problem hiding this comment.
I could be wrong about this. @dedemorton will know.
I wouldn't say:
To extract the
@timestampfield from the example log, you can use an ingest pipeline with a dissect processor.
I would say:
To extract the
@timestampfield from the example log, use an ingest pipeline with a dissect processor.
There was a problem hiding this comment.
I think you're right here, and this may have been a blind spot in my writing.
At least for Microsoft:
When you see can in your writing, consider deleting it. Can implies ability but not action. Rewrite to describe the action if possible. When ability is what you need to express, it's OK to use can to describe actions or tasks that the reader or program is able to do.
I'm putting this can in the trash can.
There was a problem hiding this comment.
Microsoft said it much better than I ever could have.
| - `tag` – Identifier for the processor that you can use for debugging and metrics. In the example, that tag is set to `high_severity_logs`. | ||
| - `if` – Conditionally runs the processor. In the example, ` "if" : "$('log.level', '') == 'WARN' || $('log.level', '') == 'ERROR'"` means the processor runs when the `log.level` field is `WARN` or `ERROR`. | ||
| - `tag` – Identifier for the processor that you can use for debugging and metrics. In the example, the tag is set to `high_severity_logs`. | ||
| - `if` – Conditionally runs the processor. In the example, `"ctx.log?.level == 'WARN' || ctx.log?.level == 'ERROR'",` means the processor runs when the `log.level` field is `WARN` or `ERROR`. |
There was a problem hiding this comment.
Is there an issue for updating this eventually? 👀
bmorelli25
left a comment
bmorelli25
left a comment
There was a problem hiding this comment.
Generally looks good. I have a few suggestions. I'd love for @dedemorton to take a look if she has time.
* Update logs docs for consistency and formatting * more updates * review updates (cherry picked from commit 6a5abf3)
* Update logs docs for consistency and formatting * more updates * review updates (cherry picked from commit 6a5abf3)
(cherry picked from commit 6a5abf3) Co-authored-by: Mike Birnstiehl <[email protected]>
(cherry picked from commit 6a5abf3) Co-authored-by: Mike Birnstiehl <[email protected]>
2 participants
I did a run through of the current logs docs and updated to make sure things were consistent and logical.