Cisco Cloud Observability offers several APIs that let you extend and customize various aspects of the application such as cloud connections, data ingestion, authentication, and so on.
You must use Service Principals to enable your developed code to securely connect to Cisco Cloud Observability public APIs on your Cloud Tenant. Service Principals are identities, represented as code, used by applications, services, and automation tools to access specific resources. These API calls use Open Authentication 2.0 (OAuth2) token-based authentication.
It is best to create one Service Principal for each integration project. Service Principals have read-only privileges by default. You must assign the Service Principal to a Cloud Tenant role to escalate privileges on that Observability Platform Tenant. See Assign Tenant Roles.
You first need a Client ID and Secret to generate an access token. You then use the access token for API access calls into your Cloud Tenant.
The Cisco Cloud Observability Application Principal Management API is currently beta and is subject to change. If you adopt a beta API, it may not be fully compatible with future versions.
Cisco Cloud Observability collects data from cloud platforms and correlates that data with the underlying cloud infrastructure. To create cloud connections, you must connect Cisco Cloud Observability to one more cloud provider accounts. Cisco Cloud Observability provides HTTP REST APIs to automate the process of creating and managing cloud connections at scale. See the Cisco Cloud Observability Connections API.
Common Ingestion Service
Traditionally, the Cisco Cloud Observability platform ingests the data that the applications and services generate in multiple ways, which is not an efficient way to store and correlate data. Therefore, Cisco Cloud Observability introduces the Common Ingestion Service API to ingest the data in one, efficient way. Cisco Cloud Observability uses OpenTelemetry as the data ingestion standard. OpenTelemetry is a set of APIs, SDKs, tooling, and integrations designed to create and manage telemetry data such as traces, metrics, and logs. Using the Common Ingestion Service API, Cisco Cloud Observability and third-party agents can publish OpenTelemetry metric data to the common ingestion pipeline. See the Cisco Cloud ObservabilityCommon Ingestion Service API.
Health rules let you specify the parameters representing what you consider normal or expected operations for your environment. You can create health rules to monitor one entity or a group of entities. The Health Rules API enables you to programmatically create, update, and manage one or more health rules for the monitored entities. See the Cisco Cloud Observability Health Rules API.
Cisco Cloud Observability Health Rules API is currently beta and is subject to change. If you adopt a beta API, it may not be fully compatible with future versions.
Cisco Cloud Observability Anomaly Detection determines whether every service in your application performs within the acceptable performance limits. This feature helps to reduce the Mean Time To Detection (MTTD) for application performance problems. The Anomaly Detection Configuration API helps you to create Anomaly Detection configurations for specific entities and entity types. You can also set a sensitivity level such as high, medium, or low, and test for the Anomaly Detection configurations as per your business needs. See the Cisco Cloud ObservabilityAnomaly Detection Configuration API.
Cisco Cloud Observability Anomaly Detection Configuration API is currently beta and is subject to change. If you adopt a beta API, it may not be fully compatible with future versions.
The Actions API enables you to create, configure, and manage various actions. An action is a predefined, reusable, automated response to an event such as a health violation or an anomaly. See
Cisco Cloud Observability Actions API is currently beta and is subject to change. If you adopt a beta API, it may not be fully compatible with future versions.