Now you can actually codify your best-practices around building and operating microservices and then view how these practices are being followed across your entire architecture.
A checklist is, obviously, a list of checks. But a checklist also comes with “conditions”: these let you define which of your services this checklist should apply to based on those services’ properties.
To create a checklist: navigate to the Checklists tab and click New Checklist.
Now define your checklist’s conditions. Maybe you want to create a checklist that only runs against those services that are written in Ruby? Or a checklist that only applies to Tier 1 and Tier 2 services? You can do that!
Checks are the meat of your checklist. Checks define what you want to be true with how your services are built and operated.
There are a number of different checks you can define and most have a lot of options. You can define a simple ownership check (to make sure none of your services are orphaned), or you can set up tool checks - that make sure your services are using certain operational tools. You can set up checks that dive into your codebase with our Git Repository integration, or create Manual or Custom Checks. Go ahead and create some!
Now that you have checklists defined with various checks, you can see - on your services’ detail pages - whether these checks are passing or failing for each of the particular services they apply.
But you can also get a view of your operational health across all your services with our reports feature. Moving to Kubernetes? Below is an example report showing all the services passing and failing a Kubernetes tool check.
If you have any questions or are interested in trying out OpsLevel, hit us up at firstname.lastname@example.org.