Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[chore][processor/groupbyattrsprocess] Fix typos in README #31168

Merged
merged 2 commits into from
Feb 12, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions processor/groupbyattrsprocessor/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ Typical use cases:
* extract resources from "flat" data formats, such as Fluentbit logs or Prometheus metrics
* associate Prometheus metrics to a *Resource* that describes the relevant host, based on label present on all metrics
* optimize data packaging by extracting common attributes
* [compacting](#compaction) multiple records that share the same Resource and InstrumentationLibrary attributes but are under multiple ResourceSpans/ResourceMetrics/ResourceLogs, into a single ResourceSpans/ResourceMetrics/ResourceLogs (when empty list of keys is being provided). This might happen e.g. when [groupbytrace](../groupbytraceprocessor) processor is being used or data comes in multiple requests. By compacting data, it takes less memory, is more efficiently processed, serialized and the number of export requests is reduced (e.g. in case of [jaeger](../../exporter/jaegerexporter) exporter).
* [compacting](#compaction) multiple records that share the same Resource and InstrumentationLibrary attributes but are under multiple ResourceSpans/ResourceMetrics/ResourceLogs, into a single ResourceSpans/ResourceMetrics/ResourceLogs (when empty list of keys is being provided). This might happen e.g. when [groupbytrace](../groupbytraceprocessor) processor is being used or data comes in multiple requests. By compacting data, it takes less memory, is more efficiently processed, serialized and the number of export requests is reduced.

It is recommended to use the `groupbyattrs` processor together with [batch](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/batchprocessor) processor, as a consecutive step, as this will reduce the fragmentation of data (by grouping records together under matching Resource/Instrumentation Library)

Expand Down Expand Up @@ -108,25 +108,25 @@ For example, consider the following input:

```go
Resource {host.name="localhost"}
InstumentationLibrary {name="MyLibrary"}
InstrumentationLibrary {name="MyLibrary"}
Spans
Span {span_id=1, ...}
InstumentationLibrary {name="OtherLibrary"}
InstrumentationLibrary {name="OtherLibrary"}
Spans
Span {span_id=2, ...}

Resource {host.name="localhost"}
InstumentationLibrary {name="MyLibrary"}
InstrumentationLibrary {name="MyLibrary"}
Spans
Span {span_id=3, ...}

Resource {host.name="localhost"}
InstumentationLibrary {name="MyLibrary"}
InstrumentationLibrary {name="MyLibrary"}
Spans
Span {span_id=4, ...}

Resource {host.name="otherhost"}
InstumentationLibrary {name="MyLibrary"}
InstrumentationLibrary {name="MyLibrary"}
Spans
Span {span_id=5, ...}
```
Expand All @@ -148,17 +148,17 @@ The output of the processor will therefore be:

```go
Resource {host.name="localhost"}
InstumentationLibrary {name="MyLibrary"}
InstrumentationLibrary {name="MyLibrary"}
Spans
Span {span_id=1, ...}
Span {span_id=3, ...}
Span {span_id=4, ...}
InstumentationLibrary {name="OtherLibrary"}
InstrumentationLibrary {name="OtherLibrary"}
Spans
Span {span_id=2, ...}

Resource {host.name="otherhost"}
InstumentationLibrary {name="MyLibrary"}
InstrumentationLibrary {name="MyLibrary"}
Spans
Span {span_id=5, ...}
```
Expand Down
Loading