Note This documentation is still in progress. For any questions, please reach out in the OpenTelemetry Gitter or refer to the issues page.
A receiver is how data gets into OpenTelemetry Service. Generally, a receiver accepts data in a specified format and can support traces and/or metrics. The format of the traces and metrics supported are receiver specific.
Supported receivers (sorted alphabetically):
Receivers are configured via YAML under the top-level receivers
tag. There
must be at least one enabled receiver for this configuration to be considered
valid.
The following is a sample configuration for the examplereceiver
.
receivers:
# Receiver 1.
# <receiver type>:
examplereceiver:
# <setting one>: <value one>
endpoint: 1.2.3.4:8080
# ...
# Receiver 2.
# <receiver type>/<name>:
examplereceiver/settings:
# <setting one>: <value one>
disabled: false
# <setting two>: <value two>
endpoint: 127.0.0.1:9211
A receiver instance is referenced by its full name in other parts of the config, such as in pipelines. A full name consists of the receiver type, '/' and the name appended to the receiver type in the configuration. All receiver full names must be unique. For the example above:
- Receiver 1 has full name
examplereceiver
. - Receiver 2 has full name
examplereceiver/settings
.
All receivers expose a setting to disable it, by default receivers are enabled. At least one receiver must be enabled per pipeline to be a valid configuration.
Traces and metrics are supported.
This receiver receives trace and metrics from OpenCensus instrumented applications. It translates them into the internal format sent to processors and exporters in the pipeline.
To get started, all that is required to enable the OpenCensus receiver is to include it in the receiver definitions. This will enable the default values as specified here. The following is an example:
receivers:
opencensus:
The full list of settings exposed for this receiver are documented here with detailed sample configurations here.
This receiver supports communication using Transport Layer Security (TLS). TLS can be configured by specifying a tls-crendentials
object in the receiver configuration for receivers that support it.
receivers:
opencensus:
tls-credentials:
key-file: /key.pem # path to private key
cert-file: /cert.pem # path to certificate
The OpenCensus receiver for the agent can receive trace export calls via HTTP/JSON in addition to gRPC. The HTTP/JSON address is the same as gRPC as the protocol is recognized and processed accordingly.
To write traces with HTTP/JSON, POST
to [address]/v1/trace
. The JSON message
format parallels the gRPC protobuf format, see this
OpenApi spec for it.
The HTTP/JSON endpoint can also optionally
CORS, which is enabled by
specifying a list of allowed CORS origins in the cors-allowed-origins
field:
receivers:
opencensus:
endpoint: "localhost:55678"
cors-allowed-origins:
- http://test.com
# Origins can have wildcards with *, use * by itself to match any origin.
- https://*.example.com
Only traces are supported.
This receiver receives traces in the Jaeger format. It translates them into the internal format and sends it to processors and exporters.
It supports multiple protocols:
- Thrift HTTP
- Thrift TChannel
- gRPC
By default, the Jaeger receiver supports all three protocols on the default ports specified in factory.go. The following demonstrates how to specify the default Jaeger receiver.
receivers:
jaeger:
It is possible to configure the protocols on different ports, refer to config.yaml for detailed config examples.
// TODO Issue open-telemetry#158 // The Jaeger receiver enables all protocols even when one is specified or a // subset is enabled. The documentation should be updated when that fix occurs.
This receiver supports communication using Transport Layer Security (TLS), but only using the gRPC protocol. It can be configured by specifying a tls-crendentials
object in the gRPC receiver configuration.
receivers:
jaeger:
protocols:
grpc:
tls-credentials:
key-file: /key.pem # path to private key
cert-file: /cert.pem # path to certificate
endpoint: "127.0.0.1:9876"
Only metrics are supported.
This receiver is a drop-in replacement for getting Prometheus to scrape your services. Just like you would write in a YAML configuration file before starting Prometheus, such as with:
prometheus --config.file=prom.yaml
you can copy and paste that same configuration under section
receivers:
prometheus:
config:
such as:
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'opencensus_service'
scrape_interval: 5s
static_configs:
- targets: ['localhost:8889']
- job_name: 'jdbc_apps'
scrape_interval: 3s
static_configs:
- targets: ['localhost:9777']
Include Filter provides ability to filter scraping metrics per target. If a filter is specified for
a target then only those metrics which exactly matches one of the metrics specified in the Include Filter
list will be scraped.
Rest of the metrics from the targets will be dropped.
- Endpoint should be double quoted.
- Metrics should be specified in form of a list.
receivers:
prometheus:
include_filter: {
"localhost:9777" : [http/server/server_latency, custom_metric1],
"localhost:9778" : [http/client/roundtrip_latency],
}
config:
scrape_configs:
...
Only metrics are supported.
<Add more information - I'm lonely.>
Only traces are supported.
This receiver receives spans from Zipkin (V1 and V2) HTTP uploads and translates them into the internal span types that are then sent to the collector/exporters.
Its address can be configured in the YAML configuration file under section "receivers", subsection "zipkin" and field "address". The syntax of the field "address" is [address|host]:<port-number>
.
For example:
receivers:
zipkin:
address: "127.0.0.1:9411"