Partitions

To effectively manage your telemetry data, you need to separate, or partition data into meaningful slices that map to your business. Partitions provide a consistent structure for attributing usage and costs to the appropriate owners in your organization so they can isolate and independently control their parts of the business.

Partition hierarchy

Partitions are hierarchical, which lets you model the ownership structure of your organization. A global partition is created by default, and captures all consumption. Individual teams can create distinct partitions, with child partitions for individual services and environments. All created partitions are children of the global partition, and each created partition has a default partition to collect any traffic not explicitly captured by other partitions. Default partitions are created automatically, and ensure that all consumption is accounted for at every level and sums correctly into parent partitions. The following diagram depicts the hierarchy of partitions stemming from the global partition. Two created partitions are children of the global partition: one for the ordering_team and another for the auth-team. Each of those partitions have child partitions for each team’s individual service, with additional child partitions for prod, staging, and dev environments.

Filters

Each partition uses one or more filters to determine which telemetry data the partition captures. A request must match every filter to be assigned to the partition. Each filter uses one of the following operators:

IN: the request must match at least one of the filter’s conditions.
NOT_IN: the request must not match any of the filter’s conditions.

A partition with multiple IN or NOT_IN filters save each condition into a single IN and NOT_IN operator collection. Each condition matches exactly one telemetry type through one of the following fields:

log_filter: matches log data with a log query.
metric_filters: matches metric data by label. A metric must match every label filter in the condition. Label values support glob patterns, such as service:{svc1,svc2} to match alternatives.
trace_span_filters: matches trace data at the span level. A span must satisfy every span filter in the condition.

Trace span filters

A trace span filter matches spans on one or more of the following fields. To match alternatives, use an IN string filter or separate conditions.

service: the service of the span.
operation: the operation of the span.
parent_service: the service of the span’s parent span. Root spans don’t match.
parent_operation: the operation of the span’s parent span. Root spans don’t match.
duration: the duration of the span. An omitted or zero bound is unbounded on that side.
error: the error status of the span.
tags: the tags of the span. A numeric matcher also compares numeric-looking string tag values.
is_root_span: whether the span is the root span of its trace.

View partitions

Select from the following methods to view and filter available partitions.

Web
Chronoctl
API

To view partitions:

In the navigation menu, click Go to Admin and then select Control > Partitions and Budgets. The global partition and any defined child partitions display.
To view the definition for a specific partition, select it from the Child partitions table, or from the side navigation. The child partition’s definition displays in the Details tab.
With a child partition selected, click the Budget tab to view the defined budget thresholds attached to that partition.

To use Chronoctl to return all partitions, use the chronoctl consumption-config read command:

chronoctl consumption-config read

To complete this action with the Chronosphere API, use the ReadConsumptionConfig endpoint.Because the Chronosphere API requires authentication, include an API token with your curl request, as shown in the following example. For more details, see Create an API token.

export CHRONOSPHERE_API_TOKEN="TOKEN"
export CHRONOSPHERE_DOMAIN="INSTANCE.chronosphere.io"

curl -H "API-Token: ${CHRONOSPHERE_API_TOKEN}" \
     -X METHOD "https://${CHRONOSPHERE_DOMAIN}/ENDPOINT_PATH"

Replace the following:

TOKEN: Your API token.
INSTANCE: The subdomain name for your organization’s Observability Platform instance.
METHOD: The HTTP method to use with the request, such as GET or POST.
ENDPOINT_PATH: The specific endpoint you want to access.

Create partitions

Select from the following methods to create partitions. Each partition can have up to five levels of nesting. Partitions are applied in match order as listed in your configuration file. If data matches multiple partitions, Chronosphere Observability Platform applies the first partition that the data matches in the configuration file.

The total number of partitions is limited, including the default partitions that Observability Platform generates automatically for each non-empty partition list. If you reach the limit, consolidate partitions or contact Chronosphere Support.

Web
Chronoctl
Terraform
API

Define the partition definition in Observability Platform, and then use the Code Config tool to apply the definition.

In the navigation menu, click Go to Admin and then select Control > Partitions and Budgets.
Click New partition, and then enter a name for your partition.
In the side navigation, select your new partition to configure it.
If you want to use a different display name or slug for the new partition, enter new values.
After applying the partition configuration, the slug value can’t be changed.
Select the parent partition for the new partition to belong to.
Define filters, which determine the data that belongs to this partition. For each filter, select In or Not in from the Operator menu to include or exclude matching data, and then enter the Conditions. The condition format depends on the telemetry type:
- Logs: a log query.
- Metrics: label/value pairs.
- Traces: span fields, such as service or operation.
For how the In and Not in operators combine, see Filters. For examples of filters, see the Chronoctl example and the Terraform example.
To create child partitions in the new partition, in the Child partitions section, click New partition.
Partitions support a maximum nesting depth of five levels from the global partition.
To save the new partition and apply changes to the configuration, click the Code config tab and use the Code Config tool to apply the definition.

After applying the changes with the Code Config tool, the new partitions displays in the list of available partitions.

To use Chronoctl to create partitions, use the chronoctl consumption-config create command:

chronoctl consumption-config create

Run the following command to generate a sample partition configuration you can use as a template:
chronoctl consumption-config scaffold
In the template, kind: ConsumptionConfig defines an individual partition.
With a completed definition, submit it with:
chronoctl consumption-config create -f FILE_NAME
Replace FILE_NAME with the name of the YAML definition file you want to use.

See the Chronoctl partition example for a completed partition definition.

When you run terraform plan to generate an execution plan, Chronosphere automatically tests configurations that include notification policies by submitting them as dry runs. For details, see the Terraform provider documentation.

To create a partition with Terraform:

Create or edit a Terraform file and add the definition by using the chronosphere_consumption_config type, followed by a name in a resource declaration.
Run this command to apply the changes:
terraform apply

See the Terraform partition example for a completed partition resource.

To complete this action with the Chronosphere API, use the CreateConsumptionConfig endpoint.Because the Chronosphere API requires authentication, include an API token with your curl request, as shown in the following example. For more details, see Create an API token.

export CHRONOSPHERE_API_TOKEN="TOKEN"
export CHRONOSPHERE_DOMAIN="INSTANCE.chronosphere.io"

curl -H "API-Token: ${CHRONOSPHERE_API_TOKEN}" \
     -X METHOD "https://${CHRONOSPHERE_DOMAIN}/ENDPOINT_PATH"

Replace the following:

TOKEN: Your API token.
INSTANCE: The subdomain name for your organization’s Observability Platform instance.
METHOD: The HTTP method to use with the request, such as GET or POST.
ENDPOINT_PATH: The specific endpoint you want to access.

Next steps

After creating a partition, use the Consumption page to view usage across partitions to understand what’s driving growth and detect unwanted spikes. From the Partitions and Budgets page in Observability Platform, click View in Consumption to open the Consumption page. After analyzing consumption, create budgets and assign them to each of your partitions.

Chronoctl partition example

The following Chronoctl example defines two partitions at the team level, each with a child service partition and environment sub-partitions for production, staging, and development environments. Each partition uses conditions for logs, metrics, and traces so that data from all three telemetry types is attributed to the correct owner. The Ordering Team partition matches services with a regular expression log query, a glob-based metric filter, and an IN trace span filter. The Auth Team partition adds a NOT_IN filter to exclude load-test traffic from its consumption totals.

Chronoctl example

api_version: v1/config
kind: ConsumptionConfig
spec:
  partitions:
    - name: "Ordering Team"
      slug: "ordering-team"
      filters:
        - operator: "IN"
          conditions:
            - log_filter:
                query: "service =~ 'ordering|order-processor'"
            - metric_filters:
                - name: "service"
                  value_glob: "ordering*"
            - trace_span_filters:
                - service:
                    match: "IN"
                    in_values:
                      - "ordering"
                      - "order-processor"
      partitions:
        - name: "Ordering Service"
          slug: "ordering-service"
          filters:
            - operator: "IN"
              conditions:
                - log_filter:
                    query: "service = 'ordering'"
                - metric_filters:
                    - name: "service"
                      value_glob: "ordering"
                - trace_span_filters:
                    - service:
                        match: "EXACT"
                        value: "ordering"
          partitions:
            - name: "Prod"
              slug: "prod"
              filters:
                - operator: "IN"
                  conditions:
                    - log_filter:
                        query: "env = 'prod'"
                    - metric_filters:
                        - name: "env"
                          value_glob: "prod"
            - name: "Staging"
              slug: "staging"
              filters:
                - operator: "IN"
                  conditions:
                    - log_filter:
                        query: "env = 'staging'"
                    - metric_filters:
                        - name: "env"
                          value_glob: "staging"
            - name: "Dev"
              slug: "dev"
              filters:
                - operator: "IN"
                  conditions:
                    - log_filter:
                        query: "env = 'dev'"
                    - metric_filters:
                        - name: "env"
                          value_glob: "dev"

    - name: "Auth Team"
      slug: "auth-team"
      filters:
        - operator: "IN"
          conditions:
            - log_filter:
                query: "service =~ 'auth|auth-proxy'"
            - metric_filters:
                - name: "service"
                  value_glob: "auth*"
            - trace_span_filters:
                - service:
                    match: "IN"
                    in_values:
                      - "auth"
                      - "auth-proxy"
        - operator: "NOT_IN"
          conditions:
            - log_filter:
                query: "env = 'load-test'"
            - metric_filters:
                - name: "env"
                  value_glob: "load-test"
      partitions:
        - name: "Auth Service"
          slug: "auth-service"
          filters:
            - operator: "IN"
              conditions:
                - log_filter:
                    query: "service = 'auth'"
                - metric_filters:
                    - name: "service"
                      value_glob: "auth"
                - trace_span_filters:
                    - service:
                        match: "EXACT"
                        value: "auth"
          partitions:
            - name: "Prod"
              slug: "prod"
              filters:
                - operator: "IN"
                  conditions:
                    - log_filter:
                        query: "env = 'prod'"
                    - metric_filters:
                        - name: "env"
                          value_glob: "prod"
            - name: "Staging"
              slug: "staging"
              filters:
                - operator: "IN"
                  conditions:
                    - log_filter:
                        query: "env = 'staging'"
                    - metric_filters:
                        - name: "env"
                          value_glob: "staging"
            - name: "Dev"
              slug: "dev"
              filters:
                - operator: "IN"
                  conditions:
                    - log_filter:
                        query: "env = 'dev'"
                    - metric_filters:
                        - name: "env"
                          value_glob: "dev"

Terraform partition example

The following Terraform example defines the same structure as the Chronoctl example, which includes two team partitions with nested service and environment partitions. Each filter block includes separate conditions for log_filter, metric_filter, and trace_span_filters so that logs, metrics, and traces are all routed to the matching partition. The Auth Team partition demonstrates combining an IN filter with a NOT_IN filter to include auth services while excluding load-test environment data.

Terraform example

resource "chronosphere_consumption_config" "example" {
  partition {
    name = "Ordering Team"
    slug = "ordering-team"
    filter {
      operator = "IN"
      condition {
        log_filter {
          query = "service =~ 'ordering|order-processor'"
        }
      }
      condition {
        metric_filter {
          name       = "service"
          value_glob = "ordering*"
        }
      }
      condition {
        trace_span_filters {
          service {
            match     = "IN"
            in_values = ["ordering", "order-processor"]
          }
        }
      }
    }

    partition {
      name = "Ordering Service"
      slug = "ordering-service"
      filter {
        operator = "IN"
        condition {
          log_filter {
            query = "service = 'ordering'"
          }
        }
        condition {
          metric_filter {
            name       = "service"
            value_glob = "ordering"
          }
        }
        condition {
          trace_span_filters {
            service {
              match = "EXACT"
              value = "ordering"
            }
          }
        }
      }

      partition {
        name = "Prod"
        slug = "prod"
        filter {
          operator = "IN"
          condition {
            log_filter {
              query = "env = 'prod'"
            }
          }
          condition {
            metric_filter {
              name       = "env"
              value_glob = "prod"
            }
          }
        }
      }

      partition {
        name = "Staging"
        slug = "staging"
        filter {
          operator = "IN"
          condition {
            log_filter {
              query = "env = 'staging'"
            }
          }
          condition {
            metric_filter {
              name       = "env"
              value_glob = "staging"
            }
          }
        }
      }

      partition {
        name = "Dev"
        slug = "dev"
        filter {
          operator = "IN"
          condition {
            log_filter {
              query = "env = 'dev'"
            }
          }
          condition {
            metric_filter {
              name       = "env"
              value_glob = "dev"
            }
          }
        }
      }
    }
  }

  partition {
    name = "Auth Team"
    slug = "auth-team"
    filter {
      operator = "IN"
      condition {
        log_filter {
          query = "service =~ 'auth|auth-proxy'"
        }
      }
      condition {
        metric_filter {
          name       = "service"
          value_glob = "auth*"
        }
      }
      condition {
        trace_span_filters {
          service {
            match     = "IN"
            in_values = ["auth", "auth-proxy"]
          }
        }
      }
    }
    filter {
      operator = "NOT_IN"
      condition {
        log_filter {
          query = "env = 'load-test'"
        }
      }
      condition {
        metric_filter {
          name       = "env"
          value_glob = "load-test"
        }
      }
    }

    partition {
      name = "Auth Service"
      slug = "auth-service"
      filter {
        operator = "IN"
        condition {
          log_filter {
            query = "service = 'auth'"
          }
        }
        condition {
          metric_filter {
            name       = "service"
            value_glob = "auth"
          }
        }
        condition {
          trace_span_filters {
            service {
              match = "EXACT"
              value = "auth"
            }
          }
        }
      }

      partition {
        name = "Prod"
        slug = "prod"
        filter {
          operator = "IN"
          condition {
            log_filter {
              query = "env = 'prod'"
            }
          }
          condition {
            metric_filter {
              name       = "env"
              value_glob = "prod"
            }
          }
        }
      }

      partition {
        name = "Staging"
        slug = "staging"
        filter {
          operator = "IN"
          condition {
            log_filter {
              query = "env = 'staging'"
            }
          }
          condition {
            metric_filter {
              name       = "env"
              value_glob = "staging"
            }
          }
        }
      }

      partition {
        name = "Dev"
        slug = "dev"
        filter {
          operator = "IN"
          condition {
            log_filter {
              query = "env = 'dev'"
            }
          }
          condition {
            metric_filter {
              name       = "env"
              value_glob = "dev"
            }
          }
        }
      }
    }
  }
}

Update partitions

Select from the following methods to update partitions.

Web
Chronoctl
Terraform
API

To update partitions:

In the navigation menu, click Go to Admin and then select Control > Partitions and Budgets.
In the sidebar navigation, select the partition you want to update. Alternatively, in the Child partitions table, click the name of the partition, or click the three vertical dots icon in the row of the partition you want to update and then click Edit.
Make changes to the partition in the definition pane.
Click the Code config tab and use the Code Config tool to apply your changes.

To update partitions with Chronoctl, use the consumption-config update command:

chronoctl consumption-config update

Update the partition definition file.
Run the following command to submit the changes:
chronoctl consumption-config update -f FILE_NAME.yaml
Replace FILE_NAME with the name of the YAML definition file you want to use.

To edit partitions using Terraform:

Create or edit a Terraform file that updates the resource’s existing properties.
Run this command to apply the changes:
terraform apply

To complete this action with the Chronosphere API, use the UpdateConsumptionConfig endpoint.Because the Chronosphere API requires authentication, include an API token with your curl request, as shown in the following example. For more details, see Create an API token.

export CHRONOSPHERE_API_TOKEN="TOKEN"
export CHRONOSPHERE_DOMAIN="INSTANCE.chronosphere.io"

curl -H "API-Token: ${CHRONOSPHERE_API_TOKEN}" \
     -X METHOD "https://${CHRONOSPHERE_DOMAIN}/ENDPOINT_PATH"

Replace the following:

TOKEN: Your API token.
INSTANCE: The subdomain name for your organization’s Observability Platform instance.
METHOD: The HTTP method to use with the request, such as GET or POST.
ENDPOINT_PATH: The specific endpoint you want to access.

Delete partitions

Select from the following methods to delete partitions. To delete partitions with attached budgets, you must first delete attached budgets, and then delete the partition.

Users can modify Terraform-managed resources only by using Terraform. Learn more.

Web
Chronoctl
Terraform
API

To delete partitions:

In the navigation menu, click Go to Admin and then select Control > Partitions and Budgets.
In the sidebar navigation, select the partition you want to delete. Alternatively, in the Child partitions table, click the three vertical dots icon in the row of the partition you want to delete and then click Delete.
Click the Code config tab and use the Code Config tool to apply your changes.

To delete a partition with Chronoctl, use the chronoctl consumption-config delete command:

chronoctl consumption-config delete

To delete a resource that’s managed by Terraform:

Edit your Terraform configuration file to remove the pre-existing resource definition.
Run this command to remove the resource from Observability Platform:
terraform apply

To complete this action with the Chronosphere API, use the DeleteConsumptionConfig endpoint.Because the Chronosphere API requires authentication, include an API token with your curl request, as shown in the following example. For more details, see Create an API token.

export CHRONOSPHERE_API_TOKEN="TOKEN"
export CHRONOSPHERE_DOMAIN="INSTANCE.chronosphere.io"

curl -H "API-Token: ${CHRONOSPHERE_API_TOKEN}" \
     -X METHOD "https://${CHRONOSPHERE_DOMAIN}/ENDPOINT_PATH"

Replace the following:

TOKEN: Your API token.
INSTANCE: The subdomain name for your organization’s Observability Platform instance.
METHOD: The HTTP method to use with the request, such as GET or POST.
ENDPOINT_PATH: The specific endpoint you want to access.

Observability Platform

Telemetry Pipeline

More information

Partition hierarchy

Filters

Trace span filters

View partitions

Create partitions

Next steps

Chronoctl partition example

Terraform partition example

Update partitions

Delete partitions

​Partition hierarchy

​Filters

​Trace span filters

​View partitions

​Create partitions

​Next steps

​Chronoctl partition example

​Terraform partition example

​Update partitions

​Delete partitions

Partition hierarchy

Filters

Trace span filters

View partitions

Create partitions

Next steps

Chronoctl partition example

Terraform partition example

Update partitions

Delete partitions