Skip to main content

Catalog entities

The core of Cortex is an entity catalog. Every entity in your Cortex catalog is described by a YAML file called the Cortex Catalog Descriptor, also referred to as an entity's Cortex YAML (naturally stemming from cortex.yaml, which is filename that powers the GitOps approach!).

Catalog entities are broken into two distinct types:

  1. Services - the default type and the core of your catalog, used for entities such as microservices, libraries, components, etc – essentially any codebase-like module.
  2. Resources - any entity that is not a service, such as infrastructure assets, kafka topics, custom types, etc.

When you log in you'll see this distinction immediately in the top navigation.

top-nav

By default, your account is set up to use GitOps. However, if you want to work without GitOps you can change the setting in Settings | App Preferences | Enable UI Editor.

UI Editing

We recommend starting off using the UI editor (which includes a built-in YAML editor) and switching over to GitOps when ready for a wider rollout.

Catalog Descriptor

Regardless of whether you're using GitOps or UI Editing, your catalog entities are backed by YAML files. Each file is a fully compliant OpenAPI 3 spec file, with our own Cortex-specific extensions that we've added.

You can still use Cortex if you don't use OpenAPI/Swagger!

We use the OpenAPI spec as a base for service metadata, since it's an open spec with official support for extensions. That lets us extend it to be a catalog descriptor spec with optional usage of actual OpenAPI fields.

Service entities

A barebones spec file has the OpenAPI version, along with an info section that contains some basic details.

openapi: 3.0.0
info:
title: My Service
description: This is my cool service.
x-cortex-tag: my-service
x-cortex-type: service

The only required fields under info are the title and the x-cortex-tag.

Resource entities

However, if your entity is not a service, you must also specify x-cortex-type and x-cortex-definition. The x-cortex-definition field is validated against the Resource Definition.

openapi: 3.0.0
info:
title: My Database
description: This is my cool MySQL database.
x-cortex-tag: my-database
x-cortex-type: mysql
x-cortex-definition:
version: 8.0.29
distribution: percona

Domain entities

If your entity is a domain, you must also specify x-cortex-type as domain. You can read more about the Domain Catalog Here.

openapi: 3.0.0
info:
title: Payments
description: This is my cool domain.
x-cortex-tag: payments-domain
x-cortex-type: domain

Entity tag

You'll see us refer to the "entity tag" throughout the docs. The entity tag is a unique identifier that's used through Cortex, for example to declare dependencies on other services or to look up information using the Slackbot. The entity tag must be globally unique across both Service Entities and Resource Entities.

tip

Any time you see a mention of a entity tag, we're referring the value of x-cortex-tag.

Adding more information

Any additional metadata you want to add to your descriptor belongs in the info section. Throughout the docs, you'll see snippets that start with x-cortex-* – make sure to add this to the info section!

Example cortex.yaml for service entity

openapi: 3.0.0
info:
title: Chat Service
description: Chat service is responsible for handling chat feature.
x-cortex-tag: chat-service
x-cortex-type: service
x-cortex-link:
- name: Chat ServiceAPI Spec
type: OPENAPI
url: ./docs/chat-service-openapi-spec.yaml
x-cortex-groups:
- python-services
x-cortex-owners:
- type: group
name: Delta
provider: OKTA
description: Delta Team
- type: slack
channel: delta-team
notificationsEnabled: true
x-cortex-custom-metadata:
core-service: true
x-cortex-dependency:
tag: authentication-service
tag: chat-database
x-cortex-git:
github:
repository: org/chat-service
x-cortex-oncall:
pagerduty:
id: ASDF1234
type: SCHEDULE
x-cortex-apm:
datadog:
monitors:
- 12345
x-cortex-issues:
jira:
projects:
- CS

Example cortex.yaml for resource entity

Note: the YAML definition for a resource entity can use file names other than cortex.yaml or cortex.yml; please refer to the Resource Catalog for more details.

openapi: 3.0.0
info:
title: Chat Database
description: Chat service's database.
x-cortex-tag: chat-database
x-cortex-type: rds
# x-cortex-definition is required for custom x-cortex-type
x-cortex-owners:
- type: group
name: CloudOps
provider: OKTA
description: Cloud Operations Team
- type: slack
channel: cloudops-team
notificationsEnabled: true
x-cortex-oncall:
pagerduty:
id: ASDF2345
type: SCHEDULE
x-cortex-apm:
datadog:
monitors:
- 23456

Example cortex.yaml for domain entity

Note: the YAML definition for a domain entity can take file names other than cortex.yaml or cortex.yml; please refer to the Domain Catalog for more details.

openapi: 3.0.0
info:
title: Chat
description: Chat domain.
x-cortex-tag: chat
x-cortex-type: domain
x-cortex-children:
# children can be of type service, resource, or domain
- tag: chat-service
- tag: chat-database
x-cortex-domain-parents:
# parents can be of type domain only
- tag: payments-domain
- tag: web-domain
x-cortex-owners:
- type: group
name: Support
provider: OKTA
description: Support Team
- type: slack
channel: support-team
notificationsEnabled: true
x-cortex-oncall:
pagerduty:
id: ASDF2345
type: SCHEDULE
x-cortex-apm:
datadog:
monitors:
- 23456