Your first experience with Cortex will be importing services and resource into the respective Catalogs — for most of our users, this is the first time they’ve ever cataloged every one of their components (outside of a spreadsheet!). This phase is crucial: a catalog provides a structured metadata store for all of your components, replacing loose confluence pages with a centralized system with standardized data models. After you’ve built out your Catalog, you’ll begin working with Scorecards to survey essential information about your services.
After building a Scorecard or two, you’ll roll them out to your engineers and gather feedback. At this stage, you’ll realize that some services may have specific requirements, and simple rules don’t quite capture that. For example, your most critical services probably require a higher level of code coverage than less critical services do. As you productionalize your Scorecards, you’ll begin to discover these edge cases. This is where CQL shines.
CQL gives you access to all of the metadata about a service, including metadata you’ve defined yourself, as well as all the data from your third party tools – from “does the service have SLOs defined” to “verify in DataDog that those SLOs are passing and have an acceptable error budget.” Within Scorecards and the Query Builder, you can access every single data point about every single service in your Catalog. Because CQL is a power-user feature, you don’t have to dive into it every time and can stick to our out of the box queries and rules. Instead, you can choose to dive into CQL only when you need to accurately capture a complex situation.
The structured information stored in the Service Catalog, and exposed via CQL allows you to access valuable insights about your services that would be impossible to collect otherwise. For example, when the Log4j vulnerability was detected, many Cortex users found that their Catalogs already contained all of the information about deployments, ownership, and repositories that they needed. Because CQL can query and combine all of this disparate information, customers of Cortex could quickly generate a list of all services that were affected by the Log4j vulnerability, along with all of the owners for the relevant services, and jump right into mitigation – instead of spending weeks searching for services and planning for the effort
“Cortex was a critical piece of our Log4j mitigation effort. The ability to easily identify owners and correlate Snyk reporting really allowed us to focus on getting patched instead of managing spreadsheets and lists.”
— Shawn Burke, Distinguished Engineer at SoFi