Objective
Investigate and document an OpenTelemetry (OTel) southbound connector for AnyLog, allowing telemetry collected through the OpenTelemetry ecosystem to be ingested into AnyLog.
This topic should appear before KubeArmor in the documentation order, as OTel provides a general-purpose observability and telemetry integration that can also serve as a foundation for application and Kubernetes-related monitoring integrations.
Motivation
OpenTelemetry provides a vendor-neutral and widely adopted framework for collecting, processing, and exporting observability data such as metrics, logs, and traces. Supporting OTel allows AnyLog to integrate with existing observability architectures without requiring applications to implement an AnyLog-specific telemetry interface.
The integration therefore provides a path from existing OTel instrumentation and collectors into AnyLog, allowing AnyLog to serve as a downstream storage and analytics platform while keeping the application and monitoring layers independent of AnyLog.
Note: Many customers may already have application-monitoring pipelines that use OpenTelemetry to collect, process, and forward telemetry. In these environments, the underlying transport used by the OTel pipeline may already be supported natively by AnyLog, such as MQTT, Kafka, REST, or gRPC.
Therefore, the primary purpose of an OTel integration is not necessarily to provide a new transport mechanism. Rather, it provides a generic integration with an existing telemetry pipeline, similar to the role of a Telegraf integration.
The goal is to allow customers who already use OpenTelemetry to add AnyLog as a telemetry destination without replacing their existing application instrumentation, collection, processing, or data-forwarding architecture.
Integration
The expected data flow is:
Application / Service → OpenTelemetry SDK / Agent → OpenTelemetry Collector → AnyLog → AnyLog storage / analytics
The investigation should determine the most appropriate integration point between OpenTelemetry and AnyLog.
Potential approaches include:
- Native OTLP ingestion — AnyLog receives OpenTelemetry Protocol (OTLP) data directly.
- OTel Collector export through gRPC — the Collector forwards telemetry through an AnyLog-supported gRPC interface.
- MQTT / Kafka — the OTel pipeline forwards telemetry through a supported messaging transport.
- REST — the OTel pipeline forwards telemetry through an AnyLog REST interface.
The task should determine which approach provides the most generic and maintainable integration while minimizing changes to an existing customer OTel deployment.
The documentation should cover:
- Supported OTel telemetry types: metrics, logs, and traces
- Supported transport/protocol
- OTel-to-AnyLog data mapping
- Required OTel Collector configuration
- AnyLog connector configuration
- Authentication and security considerations
- Deployment architecture
- Handling of batching, buffering, retries, and backpressure where applicable
- An example end-to-end configuration
Expected Outcome
The resulting documentation should provide a practical guide for configuring an existing OpenTelemetry pipeline to send telemetry to AnyLog.
The integration should demonstrate that a customer can retain their existing OTel instrumentation and collection architecture while adding AnyLog as a destination, without requiring applications to implement a separate AnyLog-specific telemetry interface.
The documentation should also clearly distinguish the capabilities provided by OTel from AnyLog's existing native integrations, particularly where OTel provides access to application-level observability, distributed tracing, Kubernetes telemetry, and other telemetry sources that are not otherwise directly integrated with AnyLog.
Links
Objective
Investigate and document an OpenTelemetry (OTel) southbound connector for AnyLog, allowing telemetry collected through the OpenTelemetry ecosystem to be ingested into AnyLog.
This topic should appear before KubeArmor in the documentation order, as OTel provides a general-purpose observability and telemetry integration that can also serve as a foundation for application and Kubernetes-related monitoring integrations.
Motivation
OpenTelemetry provides a vendor-neutral and widely adopted framework for collecting, processing, and exporting observability data such as metrics, logs, and traces. Supporting OTel allows AnyLog to integrate with existing observability architectures without requiring applications to implement an AnyLog-specific telemetry interface.
The integration therefore provides a path from existing OTel instrumentation and collectors into AnyLog, allowing AnyLog to serve as a downstream storage and analytics platform while keeping the application and monitoring layers independent of AnyLog.
Note: Many customers may already have application-monitoring pipelines that use OpenTelemetry to collect, process, and forward telemetry. In these environments, the underlying transport used by the OTel pipeline may already be supported natively by AnyLog, such as MQTT, Kafka, REST, or gRPC.
Therefore, the primary purpose of an OTel integration is not necessarily to provide a new transport mechanism. Rather, it provides a generic integration with an existing telemetry pipeline, similar to the role of a Telegraf integration.
The goal is to allow customers who already use OpenTelemetry to add AnyLog as a telemetry destination without replacing their existing application instrumentation, collection, processing, or data-forwarding architecture.
Integration
The expected data flow is:
Application / Service → OpenTelemetry SDK / Agent → OpenTelemetry Collector → AnyLog → AnyLog storage / analytics
The investigation should determine the most appropriate integration point between OpenTelemetry and AnyLog.
Potential approaches include:
The task should determine which approach provides the most generic and maintainable integration while minimizing changes to an existing customer OTel deployment.
The documentation should cover:
Expected Outcome
The resulting documentation should provide a practical guide for configuring an existing OpenTelemetry pipeline to send telemetry to AnyLog.
The integration should demonstrate that a customer can retain their existing OTel instrumentation and collection architecture while adding AnyLog as a destination, without requiring applications to implement a separate AnyLog-specific telemetry interface.
The documentation should also clearly distinguish the capabilities provided by OTel from AnyLog's existing native integrations, particularly where OTel provides access to application-level observability, distributed tracing, Kubernetes telemetry, and other telemetry sources that are not otherwise directly integrated with AnyLog.
Links