Signaltometrics Connector
contrib
Maintainers: @ChrsMark, @lahsivjar
Source: opentelemetry-collector-contrib
Overview
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:Error Handling
Theerror_mode configuration option determines how the connector handles errors that occur while processing OTTL expressions:
error_mode(optional): Determines how errors returned from OTTL expressions are handled. Valid values arepropagate,ignore, andsilent.propagate(default): Errors cause the entire batch to fail and be returned up the pipeline. This will result in the payload being dropped from the collector.ignore: Errors are logged and the specific record that caused the error is skipped, but processing continues for the rest of the batch.silent: Errors are not logged and the specific record that caused the error is skipped, but processing continues for the rest of the batch.
Metrics types
signal_to_metrics produces a variety of metric types by utilizing OTTL
to extract the relevant data for a metric type from the incoming data. The
component can produce the following metric types for each signal type:
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:- [Required]
valuerepresents 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 thesummetric (intordouble). OTTL converters can be used to transform the data. - [Optional]
monotonicwhether the generated metric is monotonic. It defaults tofalse.
Gauge
Gauge metrics aggregate the last value of a signal and have the following configuration:- [Required]
valuerepresents an OTTL expression to extract a numeric value from the signal. Only OTTL expressions that return a value are accepted. The returned value determines the value type of thegaugemetric (intordouble).- For logs: Use e.g.
ExtractGrokPatternswith a single key selector (see below). - For other signals: Use a field such as
value_int,value_double, or a valid OTTL expression.
- For logs: Use e.g.
Histogram
Histogram metrics have the following configurations:-
[Optional]
bucketsrepresents the buckets to be used for the histogram. If no buckets are configured then it defaults to: -
[Optional]
countrepresents 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. OTTL converters can be used to transform the data. For spans, a special converter adjusted count, is provided to help calculate the span’s adjusted count. -
[Required]
valuerepresents an OTTL expression to extract the value to be recorded in the histogram from the incoming data. OTTL converters can be used to transform the data.
Exponential Histogram
Exponential histogram metrics have the following configurations:- [Optional]
max_sizerepresents the maximum number of buckets per positive or negative number range. Defaults to160. - [Optional]
countrepresents 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. OTTL converters can be used to transform the data. For spans, a special converter adjusted count, is provided to help calculate the span’s adjusted count. - [Required]
valuerepresents an OTTL expression to extract the value to be recorded in the exponential histogram from the incoming data. OTTL 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 configuringattributes for the configured metrics.
If no attributes are configured then the metrics are produced without any attributes.
key or keys_expression set.
If attributes are specified then a separate metric will be generated for each unique
set of attribute values. There are four behaviors that can be configured for an
attribute:
- Without any extra parameters:
datapoint.fooin the above yaml is an example of such configuration. In this configuration, only the signals which have the said attribute are processed with the attribute’s value as one of the attributes for the output metric. If the attribute is missing then the signal is not processed. - With
default_value:datapoint.barin the above yaml is an example of such configuration. In this configuration all the signals are processed irrespective of the attribute being present or not in the input signal. The output metric is categorized as per the incoming value of the attribute and an extra bucket exists with the attribute set to the configured default value for all the signals that were missing the configured attribute. - With
optionalset totrue:datapoint.bazin the above yaml is an example of such configuration. If the attribute is configured withoptionaland present in the incoming signal then it will be added directly to the output metric. If it is absent then a new metric with missing attributes will be created. In addition, theoptionalattribute will not impact the decision i.e. even if theoptionalattributes are not present in the incoming signal, the signal will be processed and will produce a metric given all other non-optional attributes are present or have a default value defined. - With
keys_expression: The OTTL value expression is evaluated at runtime and must return a list of attribute keys (pcommon.Sliceor[]string). Each resolved key is looked up in the signal’s attributes and included in the output metric. If the expression returnsnil(e.g. missing client metadata), it is treated as an empty list. Expression evaluation errors are governed by theerror_modeconfiguration. Theoptionalanddefault_valueoptions can be combined withkeys_expressionand apply to each resolved key.
attributes as conditional filters for
choosing which attributes should be included in the output metric whereas
include_resource_attributes is an include list for customizing resource attributes
of the output metric.
Conditions
Conditions are an optional list of OTTL conditions that are evaluated on the incoming data and are ORed together. For example:foo
OR bar resource attribute defined.
Conditions can also be ANDed together, for example:
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 forinclude_resource_attributes then no filtering
is performed i.e. all resource attributes of the incoming data is considered.
key or keys_expression set.
With the above configuration the produced metrics would have the following
resource attributes:
resource.foowill be present for the produced metrics if the incoming data also has the attribute defined. If the attribute is missing in the incoming data the output metric will be produced without the said attribute.resource.barwill always be present because of thedefault_value. If the incoming data does not have a resource attribute with nameresource.barthen the configureddefault_valueofbarwill be used.resource.bazwill behave exactly same asresource.foo. Since resource attributes are basically an include list, theoptionaloption is a no-op i.e. the resource attributes withoptionalset totruebehaves identical to an attribute configured withoutdefault_valueoroptional.- The
keys_expressionentry evaluates the OTTL value expression at runtime to resolve a list of attribute keys. The expression must return a list of strings (pcommon.Sliceor[]string). Each resolved key is looked up in the resource attributes and included in the output metric. If the expression returnsnil(e.g. missing client metadata), it is treated as an empty list. Expression evaluation errors are governed by theerror_modeconfiguration. Theoptionalanddefault_valueoptions can be combined withkeys_expressionand apply to each resolved key. OTTL expressions forinclude_resource_attributesshould only reference resource-level paths (e.g.resource.attributes) or context-level paths (e.g.otelcol.client.metadata), not signal-specific paths (e.g.attributes,span.*,log.*).
Single writer
Metrics data streams MUST obey single-writer principle. However, sincesignal_to_metrics 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 attribute is added to each produced metric:
Custom OTTL functions
The component implements the following custom OTTL functions:AdjustedCount: a converter capable of calculating adjusted count for a span.
Configuration
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
config.yaml (testdata)
Last generated: 2026-04-13