docs(observability): add OpenTelemetry export guide and group log export destinations

calico-enterprise/getting-started/install-on-clusters/kubernetes/options-install.mdx

@@ -29,7 +29,7 @@ Each API in the operator.tigera.io API group configures the installation of a di
 | **Installation**                | The foundation of every deployment is the **Installation** resource. It deploys core networking and network policy enforcement features to the cluster, and is required for all other resources to function. |
 | **APIServer**                   | Installs the Tigera API server, which enables access to the full set of [$[prodname] APIs](../../../reference/installation/api.mdx).                                                                        |
 | **LogStorage**                  | Configures installation of storage for $[prodname] flow and DNS logs.                                                                                                                                       |
-| **LogCollector**                | Configures collection of those logs from the cluster, including optional configuration to backup logs in additional stores.                                                                                  |
+| **LogCollector**                | Configures collection of those logs from the cluster, including optional configuration to backup logs in additional stores or export them over OpenTelemetry.                                                                               |
 | **IntrusionDetection**          | Configures the $[prodname] intrusion detection feature.                                                                                                                                                     |
 | **Manager**                     | Installs the $[prodname] web console.                                                                                                                                                                    |
 | **ManagementClusterConnection** | Configures a connection to the management cluster for managed clusters.                                                                                                                                      |

calico-enterprise/getting-started/install-on-clusters/windows-calico/flowlogs.mdx

@@ -43,5 +43,5 @@ $[prodnameWindows] flow logs are enabled and configured the same way as [Flow lo
 - [Configure RBAC for Elasticsearch logs](../../../observability/elastic/rbac-elasticsearch.mdx)
 - [Configure flow log aggregation](../../../observability/elastic/flow/aggregation.mdx)
 - [Log storage recommendations](../../../operations/logstorage/log-storage-recommendations.mdx)
-- [Archive logs](../../../observability/elastic/archive-storage.mdx)
+- [Archive logs](../../../observability/archive-storage.mdx)
 - [Log collection options](../../../reference/installation/api.mdx#logcollectorspec)

calico-enterprise/observability/elastic/archive-storage.mdx → calico-enterprise/observability/archive-storage.mdx

@@ -1,5 +1,5 @@
 ---
-description: Forward Calico Enterprise flow, DNS, audit, and L7 logs to Syslog, Splunk, or Amazon S3 to retain compliance data beyond in-cluster Elasticsearch retention.
+description: Forward Calico Enterprise flow, DNS, audit, and L7 logs to Syslog, Splunk, Amazon S3, or an OpenTelemetry (OTLP) backend to retain compliance data beyond in-cluster Elasticsearch retention.
 ---
 
 # Archive logs
@@ -9,11 +9,11 @@
 
 ## Big picture
 
-Archive $[prodname] logs to SIEMs like Syslog, Splunk, or Amazon S3 to meet compliance storage requirements.
+Archive $[prodname] logs to SIEMs like Syslog, Splunk, Amazon S3, or any backend that accepts OpenTelemetry (OTLP) to meet compliance storage requirements.
 
 ## Value
 
-Archiving your $[prodname] Elasticsearch logs to storage services like Amazon S3, Syslog, or Splunk are reliable
+Archiving your $[prodname] Elasticsearch logs to storage services like Amazon S3, Syslog, Splunk, or an OpenTelemetry backend are reliable
 options for maintaining and consolidating your compliance data long term.
 
 ## Before you begin
@@ -23,11 +23,12 @@
 - Syslog - flow, dns, idsevents, audit
 - Splunk - flow, audit, dns
 - Amazon S3 - l7, flow, dns, audit
+- OpenTelemetry (OTLP) - flow, dns, audit, and component metrics
 
 :::note
 If you're archiving logs for a system that includes Kubernetes clusters and non-cluster hosts or VMs, the default configuration archives all logs (both cluster and non-cluster) together. For information on how to configure this behaviour, see [Control which hosts have their logs archived](#control-which-hosts-have-their-logs-archived).
 
-Non-cluster hosts only generate a subset of the log types generated by Kubernetes cluster hosts. For more information, see the [non-cluster hosts documentation](../../getting-started/bare-metal/about).
+Non-cluster hosts only generate a subset of the log types generated by Kubernetes cluster hosts. For more information, see the [non-cluster hosts documentation](../getting-started/bare-metal/about).
 :::
 
 ## How to
@@ -53,8 +54,8 @@
     -n tigera-operator
    ```
 
-3. Update the [LogCollector](../../reference/installation/api.mdx#logcollector)
-   resource named, `tigera-secure` to include an [S3 section](../../reference/installation/api.mdx#s3storespec)
+3. Update the [LogCollector](../reference/installation/api.mdx#logcollector)
+   resource named, `tigera-secure` to include an [S3 section](../reference/installation/api.mdx#s3storespec)
    with your information noted from above.
    Example:
 
@@ -104,8 +105,8 @@
 </TabItem>
 <TabItem label="Syslog" value="Syslog-1">
 
-1. Update the [LogCollector](../../reference/installation/api.mdx#logcollector)
-   resource named `tigera-secure` to include a [Syslog section](../../reference/installation/api.mdx#syslogstorespec)
+1. Update the [LogCollector](../reference/installation/api.mdx#logcollector)
+   resource named `tigera-secure` to include a [Syslog section](../reference/installation/api.mdx#syslogstorespec)
    with your syslog information.
    Example:
    ```yaml
@@ -132,7 +133,7 @@
    kubectl edit logcollector tigera-secure
    ```
 2. You can control which types of $[prodname] log data you would like to send to syslog.
-   The [Syslog section](../../reference/installation/api.mdx#syslogstorespec)
+   The [Syslog section](../reference/installation/api.mdx#syslogstorespec)
    contains a field called `logTypes` which allows you to list which log types you would like to include.
    The allowable log types are:
 
@@ -141,19 +142,19 @@
    - Flows
    - IDSEvents
 
-   Refer to the [Syslog section](../../reference/installation/api.mdx#syslogstorespec) for more details on what data each log type represents.
+   Refer to the [Syslog section](../reference/installation/api.mdx#syslogstorespec) for more details on what data each log type represents.
 
    :::note
 
-   The log type `IDSEvents` is only supported for a cluster that has [LogStorage](../../reference/installation/api.mdx#logstorage) configured. It is because intrusion detection event data is pulled from the corresponding LogStorage datastore directly.
+   The log type `IDSEvents` is only supported for a cluster that has [LogStorage](../reference/installation/api.mdx#logstorage) configured. It is because intrusion detection event data is pulled from the corresponding LogStorage datastore directly.
 
    :::
 
    The `logTypes` field is a required, which means you must specify at least one type of log to export to syslog.
 
 **TLS configuration**
 
-3. You can enable TLS option for syslog forwarding by including the "encryption" option in the [Syslog section](../../reference/installation/api.mdx#syslogstorespec).
+3. You can enable TLS option for syslog forwarding by including the "encryption" option in the [Syslog section](../reference/installation/api.mdx#syslogstorespec).
 
    ```yaml
    apiVersion: operator.tigera.io/v1
@@ -192,9 +193,7 @@
 </TabItem>
 <TabItem label="Splunk" value="Splunk-2">
 
-**Support** In this release, only [Splunk Enterprise](https://www.splunk.com/en_us/products/splunk-enterprise.html) is supported.
-
-$[prodname] uses Splunk's **HTTP Event Collector** to send data to Splunk server. To copy the flow, audit, and dns logs to Splunk, follow these steps:
+$[prodname] uses Splunk's **HTTP Event Collector** (HEC) to send data to Splunk, so you can use any Splunk deployment that provides an HEC endpoint, such as Splunk Enterprise or Splunk Cloud Platform. To copy the flow, audit, and dns logs to Splunk, follow these steps:
 
 1. Create a HTTP Event Collector token by following the steps listed in Splunk's documentation for your specific Splunk version. Here is the link to do this for [Splunk version 8.0.0](https://docs.splunk.com/Documentation/Splunk/8.0.0/Data/UsetheHTTPEventCollector).
 
@@ -208,9 +207,9 @@
    ```
 
 3. Update the
-   [LogCollector](../../reference/installation/api.mdx#logcollector)
+   [LogCollector](../reference/installation/api.mdx#logcollector)
    resource named `tigera-secure` to include
-   a [Splunk section](../../reference/installation/api.mdx#splunkstorespec)
+   a [Splunk section](../reference/installation/api.mdx#splunkstorespec)
    with your Splunk information.
    Example:
 
@@ -245,12 +244,70 @@
    kubectl create configmap splunk-ca --from-file=tls.crt -n tigera-operator
    ```
 
+</TabItem>
+<TabItem label="OpenTelemetry" value="OpenTelemetry-3">
+
+$[prodname] sends logs over the OpenTelemetry Protocol (OTLP) through an OpenTelemetry Collector that the operator deploys and manages for you.
+Your backend must accept OTLP over `https`, using gRPC or HTTP.
+
+1. If your backend needs an API key or token, create a Secret for it in the `tigera-operator` namespace.
+
+   ```bash
+   kubectl create secret generic otel-backend-credentials \
+     --from-literal=api-key=<your-api-key> \
+     -n tigera-operator
+   ```
+
+2. Update the [LogCollector](../reference/installation/api.mdx#logcollector)
+   resource named `tigera-secure` to include an [openTelemetry section](../reference/installation/api.mdx#opentelemetryspec).
+   Unlike the other destinations, it goes directly under `spec`, not under `additionalStores`.
+   Example:
+
+   ```yaml
+   apiVersion: operator.tigera.io/v1
+   kind: LogCollector
+   metadata:
+     name: tigera-secure
+   spec:
+     openTelemetry:
+       logs:
+         types:
+           - Flows
+           - DNS
+           - Audit
+       exporters:
+         - name: my-backend
+           endpoint: https://otlp.example.com:4317
+           auth:
+             headers:
+               - name: api-key
+                 valueFrom:
+                   secretKeyRef:
+                     name: otel-backend-credentials
+                     key: api-key
+   ```
+
+   This can be done during installation by editing the custom-resources.yaml
+   by applying it, or after installation by editing the resource with the command:
+
+   ```bash
+   kubectl edit logcollector tigera-secure
+   ```
+
+For metrics export, a private CA or mutual TLS, sending to more than one backend, and sizing the Collector, see [Export logs and metrics with OpenTelemetry](opentelemetry.mdx).
+
+:::note
+
+`hostScope` does not apply to OpenTelemetry export. Flow and DNS logs from both cluster hosts and non-cluster hosts are exported.
+
+:::
+
 </TabItem>
 
 </Tabs>
 
 ### Control which hosts have their logs archived
-By default, logs are archived from both Kubernetes cluster hosts and [non-cluster hosts](../../getting-started/bare-metal/about). To archive logs for only non-cluster hosts or VMs, use the [`hostScope`](../../reference/installation/api.mdx#additionallogstorespec) field when you set your additional storage spec on the `LogCollector` resource.
+By default, logs are archived from both Kubernetes cluster hosts and [non-cluster hosts](../getting-started/bare-metal/about). To archive logs for only non-cluster hosts or VMs, use the [`hostScope`](../reference/installation/api.mdx#additionallogstorespec) field when you set your additional storage spec on the `LogCollector` resource.
 
 ```yaml title="Example spec for Splunk"
 apiVersion: operator.tigera.io/v1

calico-enterprise/observability/elastic/flow/aggregation.mdx

@@ -120,6 +120,6 @@ The underlying reason for this overlap is a dependency on Linux conntrack, which
 
 ## Additional resources
 
-- [Archive logs to storage](../archive-storage.mdx)
+- [Archive logs to storage](../../archive-storage.mdx)
 - [Configure RBAC for Elasticsearch logs](../rbac-elasticsearch.mdx)
 - [Configure data retention](../retention.mdx)

calico-enterprise/observability/elastic/flow/filtering.mdx

@@ -111,5 +111,5 @@ The operator inserts the filters inline into the log collector configuration and
 ## Additional resources
 
 - [Flow log aggregation](aggregation.mdx)
-- [Archive logs to storage](../archive-storage.mdx)
+- [Archive logs to storage](../../archive-storage.mdx)
 - [Configure RBAC for Elasticsearch logs](../rbac-elasticsearch.mdx)

calico-enterprise/observability/elastic/overview.mdx

@@ -19,7 +19,7 @@ Workloads and policies are highly dynamic. To troubleshoot Kubernetes clusters,
 - Collect/archive logs or subset of logs
 - Log aggregation for high-volume logs
 - Configure data retention settings to manage cluster disk space
-- Integration with third-party tools like Amazon S3, Syslog, Splunk
+- Integration with third-party tools like Amazon S3, Syslog, Splunk, and any backend that accepts OpenTelemetry (OTLP)
 
 ## Concepts
 
@@ -45,7 +45,7 @@ Because of their high-volume, flow and DNS logs support aggregation.
 
 ### Default log configuration and security
 
-$[prodname] automatically installs Fluent Bit on all nodes and collects flow, audit, and DNS logs. You can configure additional destinations like Amazon S3, Syslog, Splunk.
+$[prodname] automatically installs Fluent Bit on all nodes and collects flow, audit, and DNS logs. You can configure additional destinations like Amazon S3, Syslog, Splunk, or an [OpenTelemetry backend](../opentelemetry.mdx).
 
 Fluent Bit buffers logs on each node's filesystem, under `/var/log/calico/calico-fluent-bit/storage`, so chunks that have not been delivered yet survive a log collector restart. Each destination gets its own buffer with its own cap: 500 MB for flow logs and for each additional destination, and 100 MB for each of the other log types. Account for that disk usage when you size your nodes. Fluent Bit retries a chunk until it is delivered, so a destination that stays unreachable long enough to fill its buffer starts losing data for that destination only; the others keep shipping.
 
@@ -60,7 +60,7 @@ kubectl patch logcollector tigera-secure --type=merge \
   --patch='{"spec":{"ingestionCompression":"Zstd"}}'
 ```
 
-The setting applies only to batches in transit. It does not change the compression of the rotated log files on disk, the [additional destinations](archive-storage.mdx), or the OpenTelemetry exporters.
+The setting applies only to batches in transit. It does not change the compression of the rotated log files on disk, the [additional destinations](../archive-storage.mdx), or the OpenTelemetry exporters.
 
 ### RBAC and log access
 
@@ -98,5 +98,5 @@ verbs: ['get']
 - [Audit logs](audit-overview.mdx)
 - [BGP logs](bgp.mdx)
 - [DNS logs](dns/dns-logs.mdx)
-- [Archive logs](archive-storage.mdx)
+- [Archive logs](../archive-storage.mdx)
 - [Log collection options](../../reference/installation/api.mdx#logcollectorspec)

calico-enterprise/observability/index.mdx

@@ -25,13 +25,19 @@ See what's going on in your cluster with network observability tools and detaile
 <DocCardLinkLayout>
   <DocCardLink docId='observability/elastic/overview' />
   <DocCardLink docId='observability/elastic/retention' />
-  <DocCardLink docId='observability/elastic/archive-storage' />
   <DocCardLink docId='observability/elastic/overview' />
   <DocCardLink docId='observability/elastic/rbac-elasticsearch' />
   <DocCardLink docId='observability/elastic/bgp' />
   <DocCardLink docId='observability/elastic/audit-overview' />
 </DocCardLinkLayout>
 
+## Export logs and metrics
+
+<DocCardLinkLayout>
+  <DocCardLink docId='observability/archive-storage' />
+  <DocCardLink docId='observability/opentelemetry' />
+</DocCardLinkLayout>
+
 ## Flow logs
 
 <DocCardLinkLayout>