Enable IBM DataPower and IBM API Gateway to export logs via OpenTelemetry (OTLP), alongside existing tracing, so customers can stream gateway logs natively to any OTel-compatible backend

Why this matters:
Enterprises are standardizing on OpenTelemetry for vendor-neutral observability. DataPower already supports OpenTelemetry traces; not supporting logs forces customers to maintain parallel pipelines (syslog/NFS/File/SOAP) and custom shims to reach their OTel collectors. This increases cost, latency, and operational risk. Native OTLP log export closes the gap and makes DataPower a first-class citizen in modern observability stacks.

Who benefits:

• Platform/SRE/DevOps teams consolidating logs, metrics, and traces (the “three pillars”) into one pipeline (e.g., OTEL Collector → Splunk, Grafana/Loki, Instana, etc.).
• API owners and security teams needing structured, correlated logs with trace/span IDs for faster incident response and auditability.
• IBM: strengthens DataPower’s cloud-native story, removes a common blocker in PoCs, and reduces churn from customers standardizing on OTel.

How it could work:

Option A — New Log Target type: “OpenTelemetry (OTLP)”
Add an additional Log Target type that emits logs in OTLP (gRPC and HTTP). Configuration should include:

1. Endpoint & protocol: grpc (4317) or http (4318).
2. Security: TLS/mTLS via existing crypto profiles, trusted CAs, SNI, client certs; auth headers.
3. Reliability: batching, queueing, retries with exponential backoff, timeouts, gzip compression.
4. Routing & selection: per-domain enablement; include/exclude categories (apigw/mpgw/audit/crypto/runtime); severity thresholds.
5. Resource/attributes: set service.name, service.namespace, service.instance.id, firmware version, domain, gateway name/region; allow custom attributes.
6. Correlation: attach trace_id/span_id when present to link logs ↔ traces.
7. Format: OTLP Logs per spec (timestamp, severity, body, attributes).

Option B — Extend existing OpenTelemetry configuration object (introduced in 10.6.x) to include Logs
Keep traces and logs under one OTel exporter for consistent resource attributes and a single connection lifecycle. Add a Logs section with:

1. Enable/disable flag, categories & severity filters.
2. Attribute mapping from DataPower fields (request method/URL, client IP, rule/policy name, status, latency, TLS info, ...) to OTel log attributes.
3. Operational controls (batch size, flush timeout, max queue).
4. Health metrics (export success/failure counters) surfaced to the OTel metrics endpoint or DataPower monitoring.

IBM DataPower just needs to speak OTLP natively.

Acceptance criteria:

• DataPower can send logs to an OTEL Collector over OTLP gRPC and HTTP with TLS.
• Operators can scope which categories and severities are exported per domain.
• Logs include resource attributes (service.name/datapower, domain, ...) and common request attributes (method, path, status, latency, rule, ..).
• Backpressure & retry behavior is configurable and observable; export errors are visible.

(Well, and maybe metrics could also be added, but that might be an extra idea ^^)