- Cisco Observability Platform
- Guides
- Access Management
- Knowledge Store
- Introduction
- Define a Knowledge Type
- Define a Knowledge Object
- Use References in Knowledge Types and Objects
- Manage Secrets in the Knowledge Store
- Create a Knowledge Object
- List all Knowledge Objects of a Given Type
- Fetch a Knowledge Object by ID
- Update a Knowledge Object
- Delete a Knowledge Object
- Create a Patch
- Solutions
- Introduction
- Create a Solution
- Add a Knowledge Type to a Solution
- Add a Knowledge Object to a Solution
- Tag a Solution
- Validate a Solution
- Fork a Solution
- Deploy a Solution to Your Tenant
- Subscribe to a Solution
- Check the Solution Upload and Subscription Status
- Update the Manifest File of a Solution
- Deploy a Solution to the Cisco Observability Platform Exchange
- Bump the Solution Version
- List the Available Solutions
- List All Files in a Solution
- Delete the Knowledge Types and Objects of a Solution
- Delete a Solution
- Check the Solution Deletion Status
- Troubleshoot Solutions
- Data Modeling
- Solution Services
- Data Ingestion
- Data Queries
- Codex
- Health Rules
- Actions
- UI Enhancements
- Example Solutions
- Reference
- Cisco Observability Platform CLI
- Cisco Observability Platform REST APIs
- Alphabetical Reference
- Introduction
- actions:httpactiontemplate
- codex:workflow
- dashui:entityPage
- dashui:entityPagePropSet
- dashui:entityPresentation
- dashui:form
- dashui:navPresentation
- dashui:settingsConfig
- dashui:template
- dashui:templatePropsExtension
- fmm:adConfigOobTemplate
- fmm:associationDeclaration
- fmm:associationDerivation
- fmm:attributePromotion
- fmm:enrichment
- fmm:entity
- fmm:entityGrouping
- fmm:entityPriority
- fmm:extension
- fmm:event
- fmm:extensionDerivation
- fmm:metric
- fmm:metricAggregation
- fmm:metricAttributeMapping
- fmm:metricDerivation
- fmm:metricMapping
- fmm:namespace
- fmm:resourceMapping
- fmm:sourceMapping
- fmm:tagPropagation
- healthrule:healthRuleScopeOverrides
- healthrule:healthRuleTemplate
- iam:Permission
- iam:Role
- iam:RoleToPermissionMapping
- iam:SolutionPermissions
- logs:dataMaskingExpression
- logs:dataMaskingRule
- logs:dataMaskingRuleV1
- logs:logParsingRule
- solutionsecret:solutionSecret
- zodiac:egressHosts
- zodiac:function
- zodiac:secret
- zodiac:solutionCron
- zodiac:subscriptionCronConfig
- Community and Support
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
The Knowledge Store is used to create, manage, and store solutions and customer artifacts. For an introduction to solutions, see Solutions. This page introduces basic Knowledge Store concepts.
Knowledge Object
A JSON or YAML object that contains data in the form of key/value pairs. It can be created by a developer, end user, or solution. Examples of knowledge objects include solution configurations and user objects like UI templates defined by the dashui solution.
Knowledge Type
A JSON or YAML file within your solution. It defines the structure of a knowledge object using a JSON or YAML schema and defines properties 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. An example of a knowledge type is a UI template that users or solutions can use to create knowledge objects for their UI components.
Knowledge Store
A storage system that manages the lifecycle of knowledge objects, knowledge types, and solutions.
The Knowledge Store stores knowledge objects and types in a database that can be accessed by end users and services. The Knowledge Store also provides an interface in the form of a REST API. As a result, the caller is abstracted from the physical database that is backing the Knowledge Store.
The Knowledge Store also manages knowledge objects that are owned by individual users. These knowledge objects are not packaged into solutions but are created directly by the actions of end users—for example, end users who create new UI templates.
The ownership of objects is transparently managed by the Knowledge Store. Whether the object is a user UI template or a Tenant pipeline configuration, the Knowledge Store automatically recognizes the identity principal of the user and uses that information to target the objects owned by that principal. This enables user-owned data by allowing user-aware platform configurations to be retrieved by user interfaces used by an end user.
Layers
A layer represents a level of information where knowledge objects can be created, stored, and accessed. The Cisco Observability Platform currently supports three layers: Solution, Tenant, and Local-user.
Requests made to the Solution layer are currently restricted to GET and cannot be issued by a user.
Who Can Create and Access Objects at Different Layers
| Layer | Who can create knowledge objects at this layer? | Who can access knowledge objects at this layer? |
|---|---|---|
| Solution | Solution | • Tenants subscribed to the solution • All users within the Tenant |
| Tenant | User | Users within the Tenant based on their access rights |
| Local-user | User | The user that created the object |
Knowledge objects that exist at the Solution layer are created by including the type definition for the object in the solution.
Based on the use case, users can create objects at the Tenant or Local-user layer. Objects can be stored at the Tenant or Local-user layer based on the user’s roles and permissions.
Layering Use Cases
Layers enable simple solution management by facilitating efficient Solution- and Tenant-wide changes. With layers, a solution owner can make a change in one layer and synchronize that change to all Tenants and users if desired. For example, instead of adjusting defaults in every individual Tenant, solution owners can use the Solution layer to make one adjustment and rely on the Knowledge Store to ensure that every Tenant receives the new value.
Layers also support different use cases for per-user content, which are described in the following section.
Layering Methods
There are two methods of layering: layering with fragments and layering with complete objects.
Layering with Fragments
Fragments are partial knowledge objects that represent different levels of ownership. Fragments allow for mutable defaults that can support knowledge objects, such as user preferences, at different layers.
In this method, a patch is used to define a fragment on a lower layer with a target object in any of the upper layers. The target object is the fragment or complete object that the fragment is trying to patch. At read-time, the knowledge object is assembled as a hierarchy of fragments. When the fragments are assembled in layers, they create a complete knowledge object. Knowledge objects in one layer can override values of knowledge objects in upper layers based on the knowledge type definition.
An example of layering with fragments is a solution that provides default UI preferences at the Solution layer. At the Tenant layer, each Tenant can save a fragment that overrides a field, such as a time zone setting. At the Local-user layer, each end user can choose between dark mode or light mode. When users query the Knowledge Store for their UI settings, they receive a settings knowledge object that is dynamically assembled from all of the required layers.
Layering with Complete Objects
In this method, a complete knowledge object exists at one layer independently of the same knowledge object(s) at different layers. This method can be used in situations where mutable defaults are not preferred.
An example of layering with complete objects is a scenario where a solution provides default health rules to users. The Solution-layer health rules can be used by the Tenants subscribed to the solution, but can also be modified by the solution developer at any time. A user can clone the health rules as complete objects at the Tenant layer to prevent the Solution-layer changes from being automatically applied to their health rules. A user could also modify those complete objects to create custom health rules at the Tenant layer.
How to Start Using Layers
To use layers, modify the allowedLayers property in the knowledge type definition. The knowledge type must define the allowed layers for the knowledge object. See Define a Knowledge Type.
The following diagram shows an example of layering with fragments. The diagram displays a user interface configuration knowledge type and describes how the knowledge type's objects are structured.
Note: The Account and Global-user layers are not currently supported.
