Skip to content

Commit

Permalink
[connector/signaltometrics] Add boilerplate for the connector (#36454)
Browse files Browse the repository at this point in the history
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description

Adds boilerplate code for a new signal to metrics connector.

<!-- Issue number (e.g. #1234) or full URL to issue, if applicable. -->
#### Link to tracking issue
Part of
#35930

<!--Describe what testing was performed and which tests were added.-->
#### Testing

Unit tests provided as required.

<!--Describe the documentation added.-->
#### Documentation

Added basic README. Will add more details with future commits.
<!--Please delete paragraphs that you did not use before submitting.-->


CC: @ChrsMark

---------

Co-authored-by: Christos Markou <[email protected]>
  • Loading branch information
lahsivjar and ChrsMark authored Nov 25, 2024
1 parent 5dcd37e commit 37129e9
Show file tree
Hide file tree
Showing 22 changed files with 926 additions and 0 deletions.
27 changes: 27 additions & 0 deletions .chloggen/add-signaltometrics-connector.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Use this changelog template to create an entry for release notes.

# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
change_type: new_component

# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver)
component: signaltometricsconnector

# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
note: New component for generating metrics from raw signals using user defined OTTL expressions.

# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
issues: [35930]

# (Optional) One or more lines of additional information to render under the primary note.
# These lines will be padded with 2 spaces and then inserted directly into the document.
# Use pipe (|) for multiline entries.
subtext:

# If your change doesn't affect end users or the exported elements of any package,
# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
# Optional: The change log or logs in which this entry should be included.
# e.g. '[user]' or '[user, api]'
# Include 'user' if the change is relevant to end users.
# Include 'api' if there is a change to a library API.
# Default: '[user]'
change_logs: [user]
1 change: 1 addition & 0 deletions .github/CODEOWNERS
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@ connector/otlpjsonconnector/ @open-telemetry/collector-cont
connector/roundrobinconnector/ @open-telemetry/collector-contrib-approvers @bogdandrutu
connector/routingconnector/ @open-telemetry/collector-contrib-approvers @jpkrohling @mwear
connector/servicegraphconnector/ @open-telemetry/collector-contrib-approvers @jpkrohling @mapno @JaredTan95
connector/signaltometricsconnector/ @open-telemetry/collector-contrib-approvers @ChrsMark @lahsivjar
connector/spanmetricsconnector/ @open-telemetry/collector-contrib-approvers @portertech @Frapschen
connector/sumconnector/ @open-telemetry/collector-contrib-approvers @greatestusername @shalper2 @crobert-1

Expand Down
1 change: 1 addition & 0 deletions .github/ISSUE_TEMPLATE/bug_report.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,7 @@ body:
- connector/roundrobin
- connector/routing
- connector/servicegraph
- connector/signaltometrics
- connector/spanmetrics
- connector/sum
- examples/demo
Expand Down
1 change: 1 addition & 0 deletions .github/ISSUE_TEMPLATE/feature_request.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,7 @@ body:
- connector/roundrobin
- connector/routing
- connector/servicegraph
- connector/signaltometrics
- connector/spanmetrics
- connector/sum
- examples/demo
Expand Down
1 change: 1 addition & 0 deletions .github/ISSUE_TEMPLATE/other.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,7 @@ body:
- connector/roundrobin
- connector/routing
- connector/servicegraph
- connector/signaltometrics
- connector/spanmetrics
- connector/sum
- examples/demo
Expand Down
1 change: 1 addition & 0 deletions .github/ISSUE_TEMPLATE/unmaintained.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@ body:
- connector/roundrobin
- connector/routing
- connector/servicegraph
- connector/signaltometrics
- connector/spanmetrics
- connector/sum
- examples/demo
Expand Down
1 change: 1 addition & 0 deletions connector/signaltometricsconnector/Makefile
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
include ../../Makefile.Common
227 changes: 227 additions & 0 deletions connector/signaltometricsconnector/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,227 @@
# Signal to metrics connector

Signal to metrics connector produces metrics from all signal types (traces,
logs, or metrics).

<!-- status autogenerated section -->
| Status | |
| ------------- |-----------|
| Distributions | [] |
| Issues | [![Open issues](https://img.shields.io/github/issues-search/open-telemetry/opentelemetry-collector-contrib?query=is%3Aissue%20is%3Aopen%20label%3Aconnector%2Fsignaltometrics%20&label=open&color=orange&logo=opentelemetry)](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues?q=is%3Aopen+is%3Aissue+label%3Aconnector%2Fsignaltometrics) [![Closed issues](https://img.shields.io/github/issues-search/open-telemetry/opentelemetry-collector-contrib?query=is%3Aissue%20is%3Aclosed%20label%3Aconnector%2Fsignaltometrics%20&label=closed&color=blue&logo=opentelemetry)](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues?q=is%3Aclosed+is%3Aissue+label%3Aconnector%2Fsignaltometrics) |
| [Code Owners](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md#becoming-a-code-owner) | [@ChrsMark](https://www.github.com/ChrsMark), [@lahsivjar](https://www.github.com/lahsivjar) |

[development]: https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/component-stability.md#development

## Supported Pipeline Types

| [Exporter Pipeline Type] | [Receiver Pipeline Type] | [Stability Level] |
| ------------------------ | ------------------------ | ----------------- |
| traces | metrics | [development] |
| logs | metrics | [development] |
| metrics | metrics | [development] |

[Exporter Pipeline Type]: https://github.com/open-telemetry/opentelemetry-collector/blob/main/connector/README.md#exporter-pipeline-type
[Receiver Pipeline Type]: https://github.com/open-telemetry/opentelemetry-collector/blob/main/connector/README.md#receiver-pipeline-type
[Stability Level]: https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/component-stability.md#stability-levels
<!-- end autogenerated section -->

## Configuration

The component can produce metrics from spans, datapoints (for metrics), and logs.
At least one of the metrics for one signal type MUST be specified correctly for
the component to work.

All signal types can be configured to produce metrics with the same configuration
structure. For example, the below configuration will produce delta temporality counters
for counting number of events for each of the configured signals:

```yaml
signaltometrics:
spans:
- name: span.count
description: Count of spans
sum:
value: Int(AbsoluteCount()) # Count of total spans represented by each span
datapoints:
- name: datapoint.count
description: Count of datapoints
sum:
value: "1" # increment by 1 for each datapoint
logs:
- name: logrecord.count
description: Count of log records
sum:
value: "1" # increment by 1 for each log record
```
### Metrics types
`signaltometrics` produces a variety of metric types by utilizing [OTTL](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/README.md)
to extract the relevant data for a metric type from the incoming data. The
component can produce the following metric types for each signal types:

- [Sum](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#sums)
- [Histogram](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#histogram)
- [Exponential Histogram](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#exponentialhistogram)

The component does NOT perform any stateful or time based aggregations. The metric
types are aggregated for the payload sent in each `Consume*` call. The final metric
is then sent forward in the pipeline.

#### Sum

Sum metrics have the following configurations:

```yaml
sum:
value: <ottl_value_expression>
```

- [**Required**] `value` represents an OTTL expression to extract a value from the
incoming data. Only OTTL expressions that return a value are accepted. The
returned value determines the value type of the `sum` metric (`int` or `double`).
[OTTL converters](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl/ottlfuncs#readme-converters)
can be used to transform the data.

#### Histogram

Histogram metrics have the following configurations:

```yaml
histogram:
buckets: []float64
count: <ottl_value_expression>
value: <ottl_value_expression>
```

- [**Optional**] `buckets` represents the buckets to be used for the histogram.
If no buckets are configured then it defaults to:

```go
[]float64{2, 4, 6, 8, 10, 50, 100, 200, 400, 800, 1000, 1400, 2000, 5000, 10_000, 15_000}
```

- [**Optional**] `count` represents an OTTL expression to extract the count to be
recorded in the histogram from the incoming data. If no expression is provided
then it defaults to the count of the signal i.e. [adjusted count](https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling-experimental/#adjusted-count)
for spans and count for others. [OTTL converters](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl/ottlfuncs#readme-converters)
can be used to transform the data.
- [**Required**] `value` represents an OTTL expression to extract the value to be
recorded in the histogram from the incoming data. [OTTL converters](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl/ottlfuncs#readme-converters)
can be used to transform the data.

#### Exponential Histogram

Exponential histogram metrics have the following configurations:

```yaml
exponential_histogram:
max_size: <int64>
count: <ottl_value_expression>
value: <ottl_value_expression>
```

- [**Optional**] `max_size` represents the maximum number of buckets per positive
or negative number range. Defaults to `160`.
- [**Optional**] `count` represents an OTTL expression to extract the count to be
recorded in the exponential histogram from the incoming data. If no expression
is provided then it defaults to the count of the signal i.e. [adjusted count](https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling-experimental/#adjusted-count)
for spans and count for others.
[OTTL converters](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl/ottlfuncs#readme-converters) can be used to transform the data.
- [**Required**] `value` represents an OTTL expression to extract the value to be recorded
in the exponential histogram from the incoming data.
[OTTL converters](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/ottl/ottlfuncs#readme-converters) can be used to transform the data.

### Attributes

The component can produce metrics categorized by the attributes (span attributes
for traces, datapoint attributes for datapoints, or log record attributes for logs)
from the incoming data by configuring `attributes` for the configured metrics.

If no `attributes` are configured then the metrics are produced without any attributes.

```yaml
attributes:
- key: datapoint.foo
- key: datapoint.bar
default_value: bar
```

If attributes are specified then a separate metric will be generated for each unique
set of attribute values. Optionally, a `default_value` can be used to always include
the attribute with the value of the attribute defaulting to the value specified in
`default_value` if the incoming data is missing that attribute.

### Conditions

Conditions are an optional list of OTTL conditions that are evaluated on the incoming
data and are ORed together. For example:

```yaml
signaltometrics:
datapoints:
- name: datapoint.bar.sum
description: Count total number of datapoints as per datapoint.bar attribute
conditions:
- resource.attributes["foo"] != nil
- resource.attributes["bar"] != nil
sum:
value: "1"
```

The above configuration will produce sum metrics from datapoints with either `foo`
OR `bar` resource attribute defined.

Conditions can also be ANDed together, for example:

```yaml
signaltometrics:
datapoints:
- name: gauge.to.exphistogram
conditions:
- metric.type == 1 AND resource.attributes["resource.foo"] != nil
exponential_histogram:
count: "1" # 1 count for each datapoint
value: Double(value_int) + value_double # handle both int and double
```

The above configuration produces exponential histogram from gauge metrics with resource
attributes `resource.foo` set.

### Customizing resource attributes

The component allows customizing the resource attributes for the produced metrics
by specifying a list of attributes that should be included in the final metrics.
If no attributes are specified for `include_resource_attributes` then no filtering
is performed i.e. all resource attributes of the incoming data is considered.

```yaml
include_resource_attributes:
- key: resource.foo # Include resource.foo attribute if present
- key: resource.bar # Always include resource.bar attribute, default to bar
default_value: bar
```

With the above configuration the produced metrics would only have the couple of
resource attributes specified in the list:

- `resource.foo` will be present for the produced metrics if the incoming data also
has the attribute defined.
- `resource.bar` will always be present because of the `default_value`. If the incoming
data does not have a resource attribute with name `resource.bar` then the configured
`default_value` of `bar` will be used.

### Single writer

Metrics data streams MUST obey [single-writer](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#single-writer)
principle. However, since `signaltometrics` component produces metrics from all signal
types and also allows customizing the resource attributes, there is a possibility
of violating the single-writer principle. To keep the single-writer principle intact,
the component adds collector instance information as resource attributes. The following
resource attributes are added to each produced metrics:

```yaml
signaltometrics.service.name: <service_name_of_the_otel_collector>
signaltometrics.service.namespace: <service_namespace_of_the_otel_collector>
signaltometrics.service.instance.id: <service_instance_id_of_the_otel_collector>
```
62 changes: 62 additions & 0 deletions connector/signaltometricsconnector/config/config.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
// Copyright The OpenTelemetry Authors
// SPDX-License-Identifier: Apache-2.0

package config // import "github.com/open-telemetry/opentelemetry-collector-contrib/connector/signaltometricsconnector/config"

import "fmt"

// Config for the connector. Each configuration field describes the metrics
// to produce from a specific signal.
type Config struct {
Spans []MetricInfo `mapstructure:"spans"`
Datapoints []MetricInfo `mapstructure:"datapoints"`
Logs []MetricInfo `mapstructure:"logs"`
}

func (c *Config) Validate() error {
if len(c.Spans) == 0 && len(c.Datapoints) == 0 && len(c.Logs) == 0 {
return fmt.Errorf("no configuration provided, at least one should be specified")
}
return nil
}

// MetricInfo defines the structure of the metric produced by the connector.
type MetricInfo struct {
Name string `mapstructure:"name"`
Description string `mapstructure:"description"`
// Unit, if not-empty, will set the unit associated with the metric.
// See: https://github.com/open-telemetry/opentelemetry-collector/blob/b06236cc794982916cc956f20828b3e18eb33264/pdata/pmetric/generated_metric.go#L72-L81
Unit string `mapstructure:"unit"`
// IncludeResourceAttributes is a list of resource attributes that
// needs to be included in the generated metric. If no resource
// attribute is included in the list then all attributes are included.
IncludeResourceAttributes []Attribute `mapstructure:"include_resource_attributes"`
Attributes []Attribute `mapstructure:"attributes"`
// Conditions are a set of OTTL condtions which are ORed. Data is
// processed into metrics only if the sequence evaluates to true.
Conditions []string `mapstructure:"conditions"`
Histogram *Histogram `mapstructure:"histogram"`
ExponentialHistogram *ExponentialHistogram `mapstructure:"exponential_histogram"`
Sum *Sum `mapstructure:"sum"`
}

type Attribute struct {
Key string `mapstructure:"key"`
DefaultValue any `mapstructure:"default_value"`
}

type Histogram struct {
Buckets []float64 `mapstructure:"buckets"`
Count string `mapstructure:"count"`
Value string `mapstructure:"value"`
}

type ExponentialHistogram struct {
MaxSize int32 `mapstructure:"max_size"`
Count string `mapstructure:"count"`
Value string `mapstructure:"value"`
}

type Sum struct {
Value string `mapstructure:"value"`
}
Loading

0 comments on commit 37129e9

Please sign in to comment.