Problem:
Agent and agent 2 can only deliver data to Zabbix server/proxy via the Zabbix
protocol. In mixed observability stacks (Dynatrace, OTel Collector, Elastic, Grafana/Mimir,
etc.) this forces a second agent (Elastic Agent, OTel Collector, Telegraf) on
the same host, duplicating collection, configuration and resource usage.

Proposal:
Add an optional OTLP exporter to agent and agent 2, working alongside (not
instead of) the Zabbix protocol, similar to how Elastic Agent ships data to
OTel-compatible backends.

Requirements(approximately):

1. Transport: OTLP/gRPC and OTLP/HTTP (protobuf), TLS/mTLS, custom headers
   for auth tokens.
2. Signals: numeric items -> OTLP metrics; log/logrt/eventlog items -> OTLP logs.
3. Mapping per OTel semantic conventions: host -> resource attributes
   (host.name etc.), item key -> metric name, units preserved, item tags ->
   attributes.
4. Routing: per item or per host choose destination - Zabbix, OTLP, or both.
5. Data source: active check items from server/proxy; optionally a local
   static item list for standalone operation.
6. Reliability: reuse existing buffering (incl. agent 2 persistent buffer)
   with retry/backoff.
7. Config parameters, e.g. OTLPEndpoint, OTLPProtocol=grpc|http,
   OTLPHeaders, OTLPTLS*.

Benefits:

• One agent per host instead of two
• Zabbix templates and agent 2 plugins become reusable in OTel pipelines.
• Easier coexistence with and migration between observability platforms.
• Vendor-neutral data delivery.

Note:
Agent 2 could be implemented first, as the official OpenTelemetry Go SDK
is available.