> ## Documentation Index > Fetch the complete documentation index at: https://docs.chronosphere.io/llms.txt > Use this file to discover all available pages before exploring further. # Partitions > Use partitions in Chronosphere Observability Platform to create slices of your data with meaningful dimensions and distinct owners. 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. ```mermaid actions={false} theme={null} --- title: Partition tree --- flowchart TD accTitle: Partitions stemming from the global partition accDescr: The diagram shows a global partition, with three child partitions. One each for the ordering team, auth team, and a default partition. The ordering team and auth team partitions have child partitions for their individual services, which have their own partitions for different environments. global[global] global --> ordering_team[ordering-team] ordering_team --> ordering_service[ordering-service] ordering_service --> ordering_prod[prod] ordering_service --> ordering_staging[staging] ordering_service --> ordering_dev[dev] ordering_service --> ordering_default[default] ordering_team --> ordering_team_default[default] global --> auth_team[auth-team] auth_team --> auth_service[auth-service] auth_service --> auth_prod[prod] auth_service --> auth_staging[staging] auth_service --> auth_dev[dev] auth_service --> auth_default[default] auth_team --> auth_team_default[default] global --> global_default[default] classDef green fill:#28a561,stroke-width:2px,stroke:#28a561,color:#FFFFFF,font-weight:bold,underline; classDef purple fill:#705DA0,stroke-width:2px,stroke:#705DA0,color:#FFFFFF,font-weight:bold,underline; classDef orange fill:#ff9d1c,stroke-width:2px,stroke:#ff9d1c,color:#FFFFFF,font-weight:bold,underline; class ordering_team,ordering_service,ordering_dev,ordering_staging,ordering_prod green class auth_team,auth_service,auth_prod,auth_staging,auth_dev purple class global_default,ordering_team_default,ordering_default,auth_team_default,auth_default orange ``` ## 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. To view partitions: 1. In the navigation menu, click ** Go to Admin** and then select ** Control > Partitions and Budgets**. The global partition and any defined child partitions display. 2. 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. 3. With a child partition selected, click the **Budget** tab to view the defined [budget thresholds](/control/consumption/budgeting) attached to that partition. To use [Chronoctl](/tooling/chronoctl) to return all partitions, use the `chronoctl consumption-config read` command: ```shell theme={null} chronoctl consumption-config read ``` To complete this action with the Chronosphere API, use the [`ReadConsumptionConfig`](/tooling/api-info/definition/operations/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](/tooling/api-info#create-an-api-token). ```shell /"TOKEN"/ /INSTANCE/ /METHOD/ /ENDPOINT_PATH/ theme={null} 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](/support). Define the partition definition in Observability Platform, and then [use the Code Config tool](/tooling/gitops#use-the-code-config-tool) to apply the definition. 1. In the navigation menu, click ** Go to Admin** and then select ** Control > Partitions and Budgets**. 2. Click **New partition**, and then enter a name for your partition. 3. In the side navigation, select your new partition to configure it. 4. 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. 5. Select the parent partition for the new partition to belong to. 6. 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](#filters). For examples of filters, see the [Chronoctl example](#chronoctl-partition-example) and the [Terraform example](#terraform-partition-example). 7. 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. 8. To save the new partition and apply changes to the configuration, click the **Code config** tab and [use the Code Config tool](/tooling/gitops#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](/tooling/chronoctl) to create partitions, use the `chronoctl consumption-config create` command: ```shell theme={null} chronoctl consumption-config create ``` 1. Run the following command to generate a sample partition configuration you can use as a template: ```shell theme={null} chronoctl consumption-config scaffold ``` In the template, `kind: ConsumptionConfig` defines an individual partition. 2. With a completed definition, submit it with: ```shell /FILE_NAME/ theme={null} 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](#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](/tooling/infrastructure/terraform#validate-plans-with-dry-runs) documentation. To create a partition with [Terraform](/tooling/infrastructure/terraform): 1. 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. 2. Run this command to apply the changes: ```shell theme={null} terraform apply ``` See the [Terraform partition example](#terraform-partition-example) for a completed partition resource. To complete this action with the Chronosphere API, use the [`CreateConsumptionConfig`](/tooling/api-info/definition/operations/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](/tooling/api-info#create-an-api-token). ```shell /"TOKEN"/ /INSTANCE/ /METHOD/ /ENDPOINT_PATH/ theme={null} 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](/control/consumption/analyze) 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](/control/consumption/budgeting) 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. ```yaml expandable Chronoctl example icon="square-terminal" theme={null} 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](#chronoctl-partition-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 expandable Terraform example icon="square-terminal" theme={null} 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. To update partitions: 1. In the navigation menu, click ** Go to Admin** and then select ** Control > Partitions and Budgets**. 2. 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**. 3. Make changes to the partition in the definition pane. 4. Click the **Code config** tab and [use the Code Config tool](/tooling/gitops#use-the-code-config-tool) to apply your changes. To update partitions with [Chronoctl](/tooling/chronoctl), use the `consumption-config update` command: ```shell theme={null} chronoctl consumption-config update ``` 1. Update the partition definition file. 2. Run the following command to submit the changes: ```shell /FILE_NAME/ theme={null} 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](/tooling/infrastructure/terraform): 1. Create or edit a Terraform file that updates the resource's existing properties. 2. Run this command to apply the changes: ```shell theme={null} terraform apply ``` To complete this action with the Chronosphere API, use the [`UpdateConsumptionConfig`](/tooling/api-info/definition/operations/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](/tooling/api-info#create-an-api-token). ```shell /"TOKEN"/ /INSTANCE/ /METHOD/ /ENDPOINT_PATH/ theme={null} 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](/control/consumption/budgeting#delete-budgets), and then delete the partition. Users can modify Terraform-managed resources only by using Terraform. [Learn more](/tooling/infrastructure/terraform#prevent-changes-to-managed-resources). To delete partitions: 1. In the navigation menu, click ** Go to Admin** and then select ** Control > Partitions and Budgets**. 2. 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**. 3. Click the **Code config** tab and [use the Code Config tool](/tooling/gitops#use-the-code-config-tool) to apply your changes. To delete a partition with [Chronoctl](/tooling/chronoctl), use the `chronoctl consumption-config delete` command: ```shell theme={null} chronoctl consumption-config delete ``` To delete a resource that's managed by [Terraform](/tooling/infrastructure/terraform): 1. Edit your Terraform configuration file to remove the pre-existing resource definition. 2. Run this command to remove the resource from Observability Platform: ```shell theme={null} terraform apply ``` To complete this action with the Chronosphere API, use the [`DeleteConsumptionConfig`](/tooling/api-info/definition/operations/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](/tooling/api-info#create-an-api-token). ```shell /"TOKEN"/ /INSTANCE/ /METHOD/ /ENDPOINT_PATH/ theme={null} 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.