WIP

Author: aurbiztondo-splunk

_includes/gdi/collector-common-options.rst

@@ -1,4 +1,5 @@
 The Splunk Distribution of the OpenTelemetry Collector has the following configuration options than can be used by several :ref:`otel-components`.
 
 * :ref:`collector-common-config-auth`
-* :ref:`collector-common-config-grcp`
+* :ref:`collector-common-config-grcp`
+* :ref:`collector-common-config-net`

gdi/opentelemetry/collector-common-config.rst

@@ -14,5 +14,8 @@ Common configuration options
 
     Authentication <common-config/collector-common-config-auth.rst>
     gRCP settings <common-config/collector-common-config-grcp.rst>
+    Network settings <common-config/collector-common-config-net.rst>
+
+.. note:: The following list might not contain all the latest additions and updates. For a complete list of Collector common settings see the ``opentelemetry`` repository in GitHub.  
 
 .. include:: /_includes/gdi/collector-common-options.rst

gdi/opentelemetry/common-config/collector-common-config-auth.rst

@@ -6,18 +6,18 @@ Configure authentication
 
 You can configure two types of authentication within the Collector:
 
-* Server type authentication takes place in incoming HTTP/gRPC requests and is typically used in :ref:`receivers <otel-components-receivers>`. Server type authenticators include:
+* Server type authentication takes place in incoming HTTP/gRPC requests and is typically used by :ref:`receivers <otel-components-receivers>`. Server type authenticators include:
 
-  * Basic Auth Extension
+  * :ref:`Basic Auth Extension <basic-auth-extension>`
   * Bearer Token Extension
   * OIDC Extension
 
-* Client type authentication takes place in outgoing HTTP/gRPC requests and is typically used in :ref:`exporters <otel-components-exporters>`.  
+* Client type authentication takes place in outgoing HTTP/gRPC requests and is typically used by :ref:`exporters <otel-components-exporters>`. Client type authenticators include:  
 
   * ASAP Client Authentication Extension
-  * Basic Auth Extension
+  * :ref:`Basic Auth Extension <basic-auth-extension>`
   * Bearer Token Extension
-  * OAuth2 Client Extension
+  * :ref:`oauth2client-extension`
   * Sigv4 Extension
 
 .. note:: You can add new authenticators by creating a new extension with the appropriate interface, ``configauth.ServerAuthenticator`` or ``configauth.ClientAuthenticator``.

gdi/opentelemetry/common-config/collector-common-config-grcp.rst

@@ -4,7 +4,102 @@
 Configure gRCP settings
 *********************************************************************************
 
+gRPC exposes a variety of settings you can adjust within individual receivers or exporters of the Collector. For more information, refer to :ref:`Golang's gRCP documentation <https://pkg.go.dev/google.golang.org/grpc>`.
 
+Client configuration
+=============================================================================================
 
+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: Default before v0.103.0 is pick_first, default for v0.103.0 is round_robin. See issue. To restore the previous behavior, set balancer_name to pick_first.
+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
+auth
+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
+    auth:
+      authenticator: some-authenticator-extension
+    tls:
+      ca_file: ca.pem
+      cert_file: cert.pem
+      key_file: key.pem
+    headers:
+      test1: "value1"
+      "test 2": "value 2"
+
+Compression Comparison
+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.
+
+Request	Compressor	Raw Bytes	Compressed bytes	Compression ratio	Ns / op	Mb compressed / second	Mb saved / second
+lg_log_request	gzip	5150	262	19.66	49231	104.61	99.29
+lg_metric_request	gzip	6800	201	33.83	51816	131.23	127.35
+lg_trace_request	gzip	9200	270	34.07	65174	141.16	137.02
+md_log_request	gzip	363	268	1.35	37609	9.65	2.53
+md_metric_request	gzip	320	145	2.21	30141	10.62	5.81
+md_trace_request	gzip	451	288	1.57	38270	11.78	4.26
+sm_log_request	gzip	166	168	0.99	30511	5.44	-0.07
+sm_metric_request	gzip	185	142	1.30	29055	6.37	1.48
+sm_trace_request	gzip	233	205	1.14	33466	6.96	0.84
+lg_log_request	snappy	5150	475	10.84	1915	2,689.30	2,441.25
+lg_metric_request	snappy	6800	466	14.59	2266	3,000.88	2,795.23
+lg_trace_request	snappy	9200	644	14.29	3281	2,804.02	2,607.74
+md_log_request	snappy	363	300	1.21	770.0	471.43	81.82
+md_metric_request	snappy	320	162	1.98	588.6	543.66	268.43
+md_trace_request	snappy	451	330	1.37	907.7	496.86	133.30
+sm_log_request	snappy	166	184	0.90	551.8	300.83	-32.62
+sm_metric_request	snappy	185	154	1.20	526.3	351.51	58.90
+sm_trace_request	snappy	233	251	0.93	682.1	341.59	-26.39
+lg_log_request	zstd	5150	223	23.09	17998	286.14	273.75
+lg_metric_request	zstd	6800	144	47.22	14289	475.89	465.81
+lg_trace_request	zstd	9200	208	44.23	17160	536.13	524.01
+md_log_request	zstd	363	261	1.39	11216	32.36	9.09
+md_metric_request	zstd	320	145	2.21	9318	34.34	18.78
+md_trace_request	zstd	451	301	1.50	12583	35.84	11.92
+sm_log_request	zstd	166	165	1.01	12482	13.30	0.08
+sm_metric_request	zstd	185	139	1.33	8824	20.97	5.21
+sm_trace_request	zstd	233	203	1.15	10134	22.99	2.96
+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.
+
+Server configuration
+=============================================================================================
+
+:ref:`Collector receivers <otel-components-receivers>` leverage server configuration using this settings:
+
+* 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
+* auth
+
+.. note:: To configure transport, see :ref:`collector-common-config-net`.
 

gdi/opentelemetry/common-config/collector-common-config-net.rst

@@ -0,0 +1,38 @@
+.. _collector-common-config-net:
+
+*********************************************************************************
+Configure network settings
+*********************************************************************************
+
+:ref:`Collector receivers <otel-components-receivers>` leverage network configuration to set connection and transport information.
+
+You can configure the following network settings:
+
+* ``endpoint``. Configures the address for this network connection. 
+
+  * For TCP and UDP networks, the address has the form ``"host:port"``. The host must be a literal IP address, or a host name that can be resolved to IP addresses. The port must be a literal port number or a service name. 
+
+  * If the host is a literal IPv6 address it must be enclosed in square brackets, as in ``"[2001:db8::1]:80"`` or ``"[fe80::1%zone]:80"``. The zone specifies the scope of the literal IPv6 address as defined in RFC 4007.
+
+* ``transport``. You can use the following protocols:
+
+  * "tcp"
+  * "tcp4" (IPv4-only)
+  * "tcp6" (IPv6-only)
+  * "udp"
+  * "udp4" (IPv4-only)
+  * "udp6" (IPv6-only)
+  * "ip"
+  * "ip4" (IPv4-only)
+  * "ip6" (IPv6-only)
+  * "unix"
+  * "unixgram"
+  * "unixpacket"
+
+* ``dialer_timeout``. No timeout by default. The maximum amount of time a dial waits for a connect to complete. 
+
+
+.. note:: TCP receivers only require the ``endpoint`` configuration setting.
+
+
+