Checks are the driving force behind rubrics. With checks you can codify your best-practices around building and operating microservices and then view how these practices are being followed across your entire organization. Our Getting Started guide has more info about the power of checks. This page focuses on how to create checks and filters.
There are a number of different checks you can define which provide you with the ability to get full check coverage across your microservice architecture. From a simple ownership check that makes sure none of your services are orphaned, to very powerful and custom integration checks that allow you to evaluate parameters against almost any tool you use, checks are a very important part of making sure your microservices are following your standards and best practices.
In this example, we will take you through the process of creating a Tag Defined check (other checks are created similarly). A tag defined check allows you to ensure that a tag with a specific key is set on your services. This check supports additional options that also allow you to enforce that a value exists, is of a specific format, or that it matches a specific value.
To create a check, navigate to the Rubrics sub menu under the Service Maturity menu in OpsLevel. Here you are presented with your Rubric which contains the levels and categories you’ve set on your account (refer to our Getting Started with Rubrics guide for more info about Rubrics).
Hover over the cell that corresponds to the level and category you want your check to live in and click the “+ Add Check” button.
This opens a modal that allows you to select which type of check you wish to create, along with the level and category this check will belong to.
From the Type dropdown select Tag Defined.
You will now see more options that you can define. Note: All properties other than the check type are editable after creating a check, so you can always refine a check as needed.
From this modal you can define a name, any check specific properties; key and Tag Value in this case, a filter, notes, a check owner, and whether the check is enabled or not.
In this section we will run through some of the check properties available across all checks.
Filters let you apply checks to a subset of your services. Refer to the filters section for more details.
To apply a filter to your check, select it from the dropdown as shown below. All saved filters you have in your account will show up in this dropdown.
Check Ownership allows services owners to know which team to contact regarding a failing check or to get more information about a check.
To define a check owner, select a team from the dropdown as shown below.
Notes support markdown and we recommend using them to provide more context to service owners: explain why a check is important and list the steps service owners need to take in order to pass the check.
By default checks are in a disabled state until you manually enable them. This allows you to stage them before the rest of your team or company sees it. You can still see how a disabled check is doing across all of your services on the Check Reports page but it will not affect the levels of your services.
OpsLevel provides a variety of different checks types for you to evaluate the maturity of your services. In this section we will be going over the check types available to you.
Verifies that the service has an owner defined.
Verifies that a service property is set or matches a specified format.
Verifies that the service is maintained through the use of an opslevel.yml service config.
Verifies that the service has a repository integrated.
Verifies that the service is using a tool of a particular category, name and/or environment.
Verifies that the service has a tag defined with the correct key or value (more info).
Verifies that the service’s repository contains a file with a certain path or contents (more info).
Searches the service’s repository and verifies if any file matches the given contents (more info).
Create a highly customized check. Send arbitrary JSON payloads to OpsLevel, use jq to determine if the check passes or fails, and use Liquid to return a customized check result message (more info).
Requires a service owner to manually complete a check for the service. This check can be used to build manual production checklists. For checks that require periodic auditing, it provides the ability to auto-expire.
Filters let you define which of your services each check should apply to based on service properties.
To create a filter, navigate to the Filters sub menu under the Service Maturity menu in OpsLevel.
Here you are presented with a list of all the filters defined on your account.
To create a filter press the + New Filter button.
You will be shown a modal that lets you name your filter.
After clicking ‘Create’, you will be taken to a the filter page where you can define the properties you wish to filter on in the Service Filters card. Press the + Add Conditions button if you don’t have any properties defined yet, or press the Edit button to edit filter properties.
Filters use predicates to determine which services will be scoped to that filter. For example, if you wish to create a filter that only has Tier 1 services in scope, select “Tier”, “equals”, “Tier 1”.
Filters are very customizable and a powerful way to scope checks down to a subset of your services.
To help you see what the impact of a filter will be, you can look at the Matching Services card which provides a preview of all the services matching the filter.
At the bottom of the page, you can see all the Checks using that filter. You can edit checks from this page or the Rubric page.
OpsLevel allows you to build filters out of existing filters. Composable filters allow you to combine and duplicate the filters you use most frequently, reducing the toil of having to memorize the predicates that make up these filters every time you want to reference them.
To create a composable filter, follow the same steps above except select
filter when creating your predicate.
In the example above, we'd like to take the existing
Python Services filter and add a predicate of "Tier", "equals", "1" so we can target all Tier-1 Python Services. To do this, we simply select the existing
Python Services filter and add our new "Tier", "equals", "1" predicate.
If you decide to later change the predicates that make up the
Python Services filter, you will be given a warning which shows how many filters are already referencing it. Saving these changes will automatically apply them to all impacted filters.
Note: We do not support multi-level composable filters. For example, you could not create a new filter from the
Tier-1 Python Services filter from the above example. We only support nesting one level deep for filters at this time.
Updated 7 months ago