Glossary
The definitions for the terms in this glossary may differ from the defined terms in your applicable EULA and product descriptions and, therefore, do not apply to such agreements.
Access Management
Access Management controls the access to APIs and resources for users through role-based access control (RBAC).
Application
An application is a standalone solution on the Cisco Observability Platform. It can have different levels of complexity, can have one or more modules, and has a set of core functionalities (e.g., search). Cisco Cloud Observability is an example of an application.
Cisco Observability Platform provides observability across the full software stack (software-defined compute, storage, network, services, and applications). It's particularly appealing to CloudOps and SREs who use automation (e.g., CI/CD) and are looking for one pane of glass to assess and troubleshoot the whole IT estate. One key element of Cisco Observability Platform is the ability to drive the context between all these parts (i.e., how a given container supports a given set of services used by given applications). Our definition of Cisco Observability Platform extends to security, SD-WAN, external networks, as well as user and business situational awareness.
The Cisco Observability Platform Exchange is an online listing platform where users of the Cisco Observability Platform can discover and subscribe to applications and modules. The exchange will enable developers to host, license, and market their solutions to Cisco Observability Platform customers.
The Cisco Observability Platform data model is a metadata model that is represented by data stored in the Cisco Observability Platform Plaform in a way that can be occasionally added to or otherwise modified. The Cisco Observability Platform data model is vastly different than a fixed metadata model, which is a model that is expected to exist in code logic and therefore difficult to adapt to changing monitoring requirements. See also Flexible Metadata Model (FMM).
Codex
Codex enables solution developers to add custom logic into the data ingestion and transformation pipeline. Codex delivers a standards-compliant workflow language (Serverless Workflows) and a runtime engine capable of executing workflow definitions retrieved from solution bundle (Orion). Codex helps solution developer who want to provide their own logic of either transforming incoming MELT data or converting one form of MELT data to another.
Common Ingestion Service
The Common Ingestion Service is the entry point to the Cisco Observability Platform for telemetry data typically coming from OpenTelemetry data sources.
DashUI
DashUI is a configuration-driven user interface (UI) platform that enables solution developers to create and extend UIs without writing JavaScript or Typescript. DashUI is built on Next.js, an open-source web development framework for React, and uses React components as atomic building blocks. (Also called, NextUI)
Data Store
A data store is a repository for persistently storing and managing collections of data which includes not just repositories such as databases, but also simpler store types such as simple files, emails, and so on.
The Cisco Observability Platform has multiple data stores: Knowledge Store for Cisco Observability Platform Solutions, Druid for Metrics or Traces, Neo4J for Topology, and Dashbase for Logs.
Derived Entities
Entities are often related and the relationships (for example, parent/child) are useful to understand and configure a model framework. You can derive an entity from another entity; this implies a hierarchical relationship between the derived entity and the base entity.
Domain
A domain is the targeted subject area of an Cisco Observability Platform solution or set of problems that a solution aims to solve.
Entity
An entity is an object of interest for Cisco Observability Platform customers. An entity is of a known type, has an associated health, lifecycle, and can be monitored.
Entity Centric Page (ECP)
An ECP is a page that combines everything of relevance (e.g., metrics, metadata, health) for a given entity or multiple entities of the same type in Cisco Cloud Observability.
Entity Type
Each entity is of a certain type. Type here refers to a specific category of entity. For example, a disk attached to a machine is a different type compared to a container or a service. In this case, disk, machine, container, and services are types, while /dev/sda1, host.company.com, containerLoginService, and LoginService are entity instances of those types respectively. Characteristics of the entity are governed by its type.
Event
An event is unstructured data representing an action or occurrence. Events are valuable because they can be used to validate the occurrence of a particular action at a particular time.
Extensibility
The Cisco Observability Platform is extensible because it enables developers to reuse, leverage, and build upon the platform system solutions and models to create software (apps or modules) with additional functionality and capabilities without modifying the base system.
Note: e11y is an abbreviation for Extensibility, just as K8s is an abbreviation for Kubernetes.
Flexible Metadata Model (FMM)
FMM is a metadata model that is represented by data stored in a way that can be occasionally added to or otherwise modified. FMM is different than a fixed metadata model, which is a model that is expected to exist in code logic, and therefore, difficult to adapt to changing monitoring requirements.
FSOC
The Full-Stack Observability (Cisco Observability Platform) control tool (fsoc) is a command-line utility that serves as an entry point for developers for the Cisco Observability Platform. It allows developers to interact with the product environments—developer, test, and production—in a uniform way to perform various tasks.
Interaction
Interaction represents how any two entities interact with each other, such that the interactions are measurable. Interactions have a definitive lifecycle and may also have associated health.
Knowledge Object
The Knowledge Store is a layered document-oriented storage system that manages the knowledge type lifecycle and provides persistent storage to the knowledge objects, such as solution configurations and user objects, dashboards, and UI preferences of a particular knowledge type.
Knowledge Type
A knowledge type is a JSON file within your solution package. It defines the structure of a knowledge object using a JSON schema and defines attributes such as how the object ID will be generated, how the display name will be generated, whether any of the object properties contain secrets, and more.
Layering
Cisco Observability Platform functionality that allows for mutable defaults at different levels—solution, account, Tenant, and user. Objects in one layer can override values of objects in upper layers based on the Knowledge Store type definition.
Layering exists because an object returned to the caller is assembled at read-time by composing a hierarchy of fragments. Fragments are partial objects that represent different levels of ownership. When the fragments are assembled in layers, a complete object results.
Log
A log is a timestamped text record, either structured (recommended) or unstructured with metadata.
MELT
MELT is an acronym for metrics, events, logs, and traces. MELT represents the essential data types that can help organizations resolve application issues quicker and to build better systems.
Metric
A metric is a numerical measurement over a time interval, typically with a fixed frequency. Because of this, metrics are represented through time-series visualization. Examples include "calls per minute" and "average response time." For Cisco Cloud Observability, metrics are numerical measurements of an entity or interactions measured or sampled over a period of time.
Module
A module is a type of solution that enhances an existing solution (standalone application or module). The module could be as simple as a UI modification or use the entire Cisco Observability Platform to be complex and rich. Modules, however, are not standalone applications: They, by definition, only exist as extensions to existing solutions.
See Modules.
Mutual Transport Layer Security (mTLS)
mTLS is a method for mutual authentication. mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification.
Appdynamics uses mTLS to authenticate microservices and for software running in customer environments to authenticate communication between distributed applications running on multiple hosts. Agent teams provide the option for the customer to enable mTLS between tracers/collectors and the OpenTelemetry collector.
See Configure mTLS in our Cisco Cloud Observability documentation.
OpenTelemetry
OpenTelemetry is a standardization for API and SDKs across languages and a collection of developer tools. You instrument these tools to generate, collect, and export telemetry data such as metrics, logs, and traces. The exported telemetry data helps you analyze your software's performance and behavior.
OpenTelemetry Line Protocol (OTLP)
The OpenTelemetry Protocol (OTLP) is a general-purpose telemetry data delivery protocol designed in the scope of OpenTelemetry project. See the OTLP specification.
Relationship
A relationship represents how entities of different types relate to each other. Relationships have a lifecycle, but cannot be monitored.
Role Based Access Control (RBAC)
Role-based access control defines priveleges to resources based on roles and policies. See Role-based access control.
Service Principal
Service Principals are identities, represented as code, used by created applications, services, and automation tools to access specific resources. They allow developers to write code that can securely connect to Cisco public APIs for your Cloud Tenant. These API calls use Open Authentication 2.0 (OAuth2) token-based authentication.
Solution
A solution is an installable software package on the Cisco Observability Platform and is the smallest deployable unit of extension and can depend on other solutions. Solutions provide artifacts that enrich, customize, or alter the behavior of data ingestion, processing, and visualizations. They consist of containers and configurations that are deployed by the platform.
Solution Service
Solution Services allows solutions to include containerized services. The platform loads these containers on behalf of solutions and automatically scales them up and down in response to load. Containers can receive HTTP traffic--effectively adding solution REST APIs--as well as scheduled workloads using the platform Cron services. Containerized services can access every platform API and are subject to all platform access control rules.
Examples of uses for containerized services include:
- collecting, transforming, and ingesting data from APIs on the web
- performing periodic queries to the UQL
- placing custom facade APIs in front of any existing combination of platform APIs
- hosting "microsite" user interfaces
Source
A source is observed for a specific data point, for example, infra-agent, aws-cloudwatch.
When multiple sources report data for the same entity, it is important to determine the source of data to:
- clearly identify a source of this data especially when multiple sources report data
- mute a specific source, where 'mute' may mean:
- stop a specific source from collecting data
- instruct the ingestion pipeline to drop the data from a specific data source
Each reported data point must have an associated source.
A source is identified in following order of precedence:
- From telemetry.sdk.name attribute in the OpenTelemetry payload
- to enable collectors/proxies to propagate the information about the actual source of the data
- From the agent type in application principal's metadata:
- agent type is extracted from a specific claim in JSON Web Token and propagated via the
appd-agent-type header
- Set to sys:unknown
Once derived, the source is added to each data point propagated through the platform and is preserved in the data store.
Space Fleet
Space Fleet is a reference solution for the Cisco Observability Platform. Space Fleet allows developers to understand how to build new domains leveraging our FMM and other platform elements. Space Fleet is a "solution" built on top of Cisco Cloud Observability to "enrich" it. It adds a new domain that shows up on the Observe page. Space Fleet has a whimsical theme reminiscent of Star Trek without violating any copyrights ("Fair Use Clause"). Its premise is that the starships of the Galactic Federation are equipped with Kubernetes clusters (interestingly Kubernetes is the Greek word for Captain or Pilot).
System Solution
System solutions are automatically enabled in every tenant. An example of a system solution would be a settings app or key components such as codex, zodiac, or fmm.
Telemetry
Coming soon.
Timestamp
Observability is always calculated with respect to time. This is because, everything that we observe is denoted as events. Timestamp is a digital record of the time of occurrence of a particular event.
Trace
A trace tracks the progression of a transaction as it is handled by services constituting an application. A trace is composed of multiple spans, starting with the root span.
Unified Query Language (UQL)
The Unified Query Language (UQL) is the query language for retrieving observability data from the Cisco Observability Platform.