gRPC exposes a variety of settings. Several of these settings are available for configuration within individual receivers or exporters. In general, none of these settings should need to be adjusted.

Exporters leverage client configuration.

Note that client configuration supports TLS configuration, the configuration parameters are also defined under tls like server configuration. For more information, see configtls README.

• balancer_name
• compression Compression type to use among gzip, snappy, zstd, and none.
• endpoint: Valid value syntax available here
• tls
• headers: name/value pairs added to the request
• keepalive
  • permit_without_stream
  • time
  • timeout
• read_buffer_size
• write_buffer_size

Please note that per_rpc_auth which allows the credentials to send for every RPC is now moved to become an extension. Note that this feature isn't about sending the headers only during the initial connection as an authorization header under the headers would do: this is sent for every RPC performed during an established connection.

Example:

exporters:
  otlp:
    endpoint: otelcol2:55690
    tls:
      ca_file: ca.pem
      cert_file: cert.pem
      key_file: key.pem
    headers:
      test1: "value1"
      "test 2": "value 2"

configgrpc_benchmark_test.go contains benchmarks comparing the supported compression algorithms. It performs compression using gzip, zstd, and snappy compression on small, medium, and large sized log, trace, and metric payloads. Each test case outputs the uncompressed payload size, the compressed payload size, and the average nanoseconds spent on compression.

The following table summarizes the results, including some additional columns computed from the raw data. The benchmarks were performed on an AWS m5.large EC2 instance with an Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz.

Compression ratios will vary in practice as they are highly dependent on the data's information entropy. Compression rates are dependent on the speed of the CPU, and the size of payloads being compressed: smaller payloads compress at slower rates relative to larger payloads, which are able to amortize fixed computation costs over more bytes.

gzip is the only required compression algorithm required for OTLP servers, and is a natural first choice. It is not as fast as snappy, but achieves better compression ratios and has reasonable performance. If your collector is CPU bound and your OTLP server supports it, you may benefit from using snappy compression. If your collector is CPU bound and has a very fast network link, you may benefit from disabling compression, which is the default.

Receivers leverage server configuration.

Note that transport configuration can also be configured. For more information, see confignet README.

• keepalive
  • enforcement_policy
    • min_time
    • permit_without_stream
  • server_parameters
    • max_connection_age
    • max_connection_age_grace
    • max_connection_idle
    • time
    • timeout
• max_concurrent_streams
• max_recv_msg_size_mib
• read_buffer_size
• tls
• write_buffer_size