This documentation and the Cisco Observability Platform functionalities it describes are subject to change. Data saved on the platform may disappear and APIs may change without notice.
Introduction
Cisco cannot predict the myriad of data sources on the web that customers will want to ingest into the Cisco Observability Platform, nor the format of that data. So, while OpenTelemetry™ provides a common ingestion path, numerous data lakes and APIs either do not support the OpenTelemetry Protocol (OTLP) push or are organized around a "you call me" traditional REST service model.
The Cisco Observability Platform offers a complete and generalized approach to data ingestion through its built-in Solution Services. Using Solution Services, solution developers can deploy data collectors that run on the platform in Docker containers. Because the collectors are containerized, they are language-agnostic and API-agnostic and can collect data from any endpoint and use any protocol. In addition to data collectors, containers can also run complete REST or gRPC servers, thereby providing new and fully custom API endpoints, which extend the API surface area of the Cisco Observability Platform. Solution developers can use this support in conjunction with the extensible user interface to provide the REST backend with custom user interfaces that query the platform in specialized ways.
Solution Services seamlessly deploys these Docker containers, scales them up and down according to load, and provides both workload scheduling and API key management.
This section explains how to use Solution Services to integrate your solution with a Docker container. Your integration can expose a REST endpoint for tenants or users to invoke, or it can include a cron to invoke the REST endpoint periodically. You do this integration in the same declarative manner as with other parts of your solution -- by declaring configurations that you bundle with your solution.