feat(component/otelcol/connector): add count connector #4610
Conversation
Signed-off-by: Yann Soubeyrand <8511577+yann-soubeyrand@users.noreply.github.com>
yann-soubeyrand
requested review from
a team and
clayton-cornell
as code owners
| canonical: https://grafana.com/docs/alloy/latest/reference/components/otelcol/otelcol.connector.count/ | ||
| aliases: | ||
| - ../otelcol.connector.count/ # /docs/alloy/latest/reference/components/otelcol.connector.count/ |
There was a problem hiding this comment.
| canonical: https://grafana.com/docs/alloy/latest/reference/components/otelcol/otelcol.connector.count/ | |
| aliases: | |
| - ../otelcol.connector.count/ # /docs/alloy/latest/reference/components/otelcol.connector.count/ | |
| canonical: https://grafana.com/docs/alloy/latest/reference/components/otelcol/otelcol.connector.count/ |
We've been dropping the alias on new topics. We can add it in if we ever move/rename the topic after it's published.
| - oss | ||
| title: otelcol.connector.count |
There was a problem hiding this comment.
| - oss | |
| title: otelcol.connector.count | |
| - oss | |
| tags: | |
| - text: Community | |
| tooltip: This component is developed, maintained, and supported by the Alloy user community. | |
| title: otelcol.connector.count |
This looks like it's a community contributed component, so we should add this to the metadata.
|
|
||
| # `otelcol.connector.count` | ||
|
|
||
| `otelcol.connector.count` counts spans, span events, metrics, data points, log records and profiles from other `otelcol` components and outputs metrics from these counts. |
There was a problem hiding this comment.
| `otelcol.connector.count` counts spans, span events, metrics, data points, log records and profiles from other `otelcol` components and outputs metrics from these counts. | |
| # `otelcol.connector.count` | |
| {{< docs/shared lookup="stability/community.md" source="alloy" version="<ALLOY_VERSION>" >}} | |
| `otelcol.connector.count` counts spans, span events, metrics, data points, log records, and profiles from other `otelcol` components and outputs metrics from these counts. |
| ### `spans` | ||
|
|
||
| #### Blocks | ||
|
|
||
| | Block | Description | Required | | ||
| |------------------|---------------------------------------------------------|----------| | ||
| | [`count`][count] | Configures a custom count (can be used multiple times). | yes | | ||
|
|
||
| [count]: #count |
There was a problem hiding this comment.
Am I reading this right that count is a child of spans? If yes, then we need to rework this section of the docs. Take a look at the source for the docs in other components - for example otelcol.exporter.datadog - to see how we document blocks that are nested inside other blocks.
The Block table will need to be updated as well.
I won't comment/suggest for all these changes. It's probably easier to just compare/contrast against another similar topic and make the changes yourself in your fork. Then once it's updated to align with the overall style/format of documenting Blocks, I'll pass over this again for an editorial review.
| ### `count` | ||
|
|
||
| #### Arguments | ||
|
|
||
| | Name | Type | Description | Default | Required | | ||
| |---------------|---------------------------------|-----------------------------------------------------------------------------|---------|----------| | ||
| | `name` | `string` | Name of the metric emitted for this count. | | yes | | ||
| | `description` | `string` | Description of the metric emitted for this count. | `"The number of spans observed."` or <br> `"The number of span events observed."` or <br> `"The number of metrics observed."` or <br> `"The number of data points observed."` or <br> `"The number of log records observed."` or <br> `"The number of profiles observed."` <br> depending on the counted data. | no | | ||
| | `conditions` | `list(string)` | Data that matches any one of the conditions will be counted. | `[]` | no | | ||
| | `attributes` | [`map(attributes)`][attributes] | A separate count will be generated for each unique set of attribute values. | `{}` | no | |
There was a problem hiding this comment.
Similar comment here. The style for documenting arguments in a block is a bit different than used here. Take a look at the source for any other component and you will see that we don't use an #### Arguments heading.
Also, don't use <br> tags in table cells. For something like row 127 with multiple defaults, I'd put Depends on the counted data and then below the table I'd explain the various possible values. Refer to other components to see how we do this.
| | Block | Description | Required | | ||
| |----------------------------------|----------------------------------------------------------------------------|----------| | ||
| | [`spans`][spans] | Configures counts for spans. | no | | ||
| | [`span_events`][span_events] | Configures counts for span events. | no | | ||
| | [`metrics`][metrics] | Configures counts for metrics. | no | | ||
| | [`data_points`][data_points] | Configures counts for data points. | no | | ||
| | [`logs`][logs] | Configures counts for log records. | no | | ||
| | [`profiles`][profiles] | Configures counts for profiles. | no | | ||
| | [`output`][output] | Configures where to send telemetry data. | yes | | ||
| | [`debug_metrics`][debug_metrics] | Configures the metrics that this component generates to monitor its state. | no | |
There was a problem hiding this comment.
For this table, in addition to the restructuring for child blocks, we also have a sort order we try to use, required first, then alpha sort the optional. So that would mean the ouput is the first row, and then all other blocks are presented in alphabetical order. We also try to sort the block description sections in the same order as they are presented in the table.
|
|
||
| ## Example | ||
|
|
||
| ### Default counts |
There was a problem hiding this comment.
| ### Default counts | |
| ## Example | |
| The following examples show you how to use `otelcol.connector.count` toi create default counts and custom counts. | |
| ### Default counts |
We should always have at least one sentence between headings.
| The example below accepts metrics, logs and traces, and writes them respectively to Mimir, Loki and Tempo. | ||
| In addition it creates the default counts on them (everything is counted and the default metrics name and description are used) and writes the metrics to Mimir. |
There was a problem hiding this comment.
| The example below accepts metrics, logs and traces, and writes them respectively to Mimir, Loki and Tempo. | |
| In addition it creates the default counts on them (everything is counted and the default metrics name and description are used) and writes the metrics to Mimir. | |
| This example show how you can receive metrics, logs and traces, and write them respectively to Mimir, Loki and Tempo. | |
| The example also shows you how to create the default counts on your telemetry and write the metrics to Mimir. Everything is counted and the default metrics name and description are used. |
| The example below accepts logs and writes them to Loki. | ||
| In addition it creates custom counts on them and writes the metrics to Mimir. |
There was a problem hiding this comment.
| The example below accepts logs and writes them to Loki. | |
| In addition it creates custom counts on them and writes the metrics to Mimir. | |
| The following example shows you how you can receive logs and write them to Loki. | |
| The example also shows you how to create custom counts on your logs and write the metrics to Mimir. |
clayton-cornell
added
the
type/docs
2 participants
PR Description
This pull request adds the OpenTelemetry Collector count connector. This connector can be used to count spans, span events, metrics, data points, and log records.
Notes to the Reviewer
This PR depends on #4550.
PR Checklist