Documentation Grafana Cloud Monitor applications Asserts How Asserts works Environment and region

Environment and region

Typically, application deployments are segregated into environments. For example, these environments can include:

• A dedicated environment for development testing
• An environment for pre-production testing
• The production environment for end users

Additionally, the production environment may have multiple deployments; one for each geographic region. Telemetry originating from these environments captures the environment and region details in some form. For example, in Kubernetes, it is common to include the environment and region name as part of the cluster name, such as prod-us-west-0, prod-us-east-0, and so on. In some cases, there might be explicit labels that include this information. All entities, relationships, and alerts created by Asserts can be identified by environment and region. Therefore, the environment and region are first class concepts in Asserts and are available as filters on all Asserts pages.

Environment in Asserts

In Asserts, all input metrics must have an environment identifier. When setting up Asserts, you must first specify the metric label that identifies the environment. This is a mandatory requirement. It is possible that this label may differ across metrics. For this reason, Asserts creates a standard identifier label called asserts_env on all metrics that it observes. This occurs in Grafana Cloud upon metrics ingestion.

Region in Asserts

In production environments, applications may be deployed in different regions. You can configure Asserts to use a metric label to identify the region. Similar to asserts_env, Asserts creates another standard label called asserts_site to identify the region. Unlike the environment identifier, the region is an optional input.