Checks and Filters

Checks are the driving force behind Scorecards and the Rubric. 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.

Checks

There are several different Checks you can define, which allow you 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 an essential part of making sure your microservices are following your specific standards and best practices.

Creating Checks

In this example, we will take you through 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 for your services. This Check supports additional options that also allow you to enforce that a value exists, is of a particular 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 corresponding to the level and category you want your Check to live in and click the “+ Add Check” button.

This opens a modal allowing you to select which type of Check you wish to create, along with the level and category to which this Check will belong.

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 continually 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.

Check Properties

This section will review some of the properties available across all Checks.

Check Filter

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 in your account will appear in this dropdown.

Check Owner

Check Ownership allows service 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.

Check Notes

Notes support markdown, and we recommend using them to provide more context to service owners: explain why a Check is essential and list the steps service owners need to take to pass the Check.

Enabling/Disabling Checks

By default, Checks are disabled until you manually enable them. This allows you to stage a Check before the rest of your team or company sees them. 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.

Check Types

OpsLevel provides various Check types to help you evaluate the maturity of your services. In this section, we will review the Check types that are available to you.

Ownership

Verifies that the service has an owner defined.

Property

Verifies that a service property is set or matches a specified format.

Service Configuration

Verifies that the service is maintained through the use of an opslevel.yml service config.

Repository Integrated

Verifies that the service has an integrated repository.

Tool Usage

Verifies that the service uses a tool of a particular category, name and/or environment. The check verifies that the tool in question has a tile dedicated to it in the operations tab on a service.

Tag Defined

Verifies that the service has a tag defined with the correct key or value (more info).

Repo File

Verifies that the service’s repository contains a file with a certain path or contents (more info).

Repo Search

Searches the service’s repository and verifies if any file matches the given contents (more info).

Custom Event Check

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).

Manual Check

Requires a service owner to complete a Check for the service manually. This Check can be used to build manual production checklists. For Checks that require periodic auditing, it provides the ability to auto-expire.

Filters

Filters let you define which of your services each Check should apply to based on service properties.

Creating Filters

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 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 that match the filter.

At the bottom of the page, you can see all the Checks using that filter. You can edit Checks from this page, the Rubric, or Scorecard page.

Composable Filters

OpsLevel allows you to build filters out of existing filters. Composable filters will enable you to combine and duplicate the filters you use most frequently, reducing the toil of memorizing 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 change the predicates that make up the Python Services filter later, you will be given a warning that 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.