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 insights created by the knowledge graph can be identified by environment and region. Therefore, the environment and region are first class concepts in the knowledge graph and are available as filters on all knowledge graph pages.
Environment in the knowledge graph
In the knowledge graph, all input metrics must have an environment identifier. When setting up the knowledge graph, 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, the knowledge graph creates a standard identifier label called asserts_env on all metrics that it observes. This occurs in Grafana Cloud upon metrics ingestion.
Region in the knowledge graph
In production environments, applications may be deployed in different regions. You can configure the knowledge graph to use a metric label to identify the region. Similar to asserts_env, the knowledge graph creates another standard label called asserts_site to identify the region. Unlike the environment identifier, the region is an optional input.
