> ## 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. # Derived attributes export const TUsageAnalyzer = () => <> Telemetry Usage Analyzer ; This feature is in Early Access (EA), and might not be visible in your app. To learn more about this program and the features it contains, see the [Early access](/early-access) page. **Derived attributes** standardize and consolidate how Chronosphere Observability Platform works with telemetry attributes without modifying the underlying data. You can define a centralized derived attribute, and Observability Platform resolves it at the query level from anywhere else in the platform. Observability Platform lists all derived attributes in the **Derived** tab of the **[Attributes Catalog](/investigate/system-library/attributes-catalog)**. Derived labels are now part of derived attributes, as the metric label telemetry type. For configuration-as-code methods and examples for derived labels, see the [Derived labels](/investigate/querying/metrics/derived-telemetry/derived-labels) documentation. Use derived attributes to: * **Query multiple telemetry attributes under one name**. You can map many redundant or related telemetry values to a single derived value, and then query only that derived value as a single source of truth. You can replace complex, brittle, expensive, or redundant references to many values with a single derived value. * **Modify queryable data without re-instrumenting its sources**. You can rename and consolidate telemetry data by creating a derived attribute from the data, instead of changing the data at the source. * **Use a consistent vocabulary for data across Observability Platform**. Derived attributes work the same way as any other type of telemetry attribute across all Observability Platform tools. ## How derived attributes can help you Values like `prod`, `production`, and `prod-eu` might all refer to the same deployment. To query across these inconsistencies, you might use verbose workarounds in every query that references them, such as: ```text theme={null} {__name__="request_errors",cluster=~"prod|production|prod-eu"} ``` Should another value, such as `prod-apac`, be introduced, you then need to find every such query and add it to the list of matches. At a higher level, the `cluster` source key in metric labels might also refer to the same concept as the `environment` source key in trace tags. Derived attributes can map all of these disparate telemetry concepts to a unified, consistently addressable name that you can reference in queries. For example, a derived attribute named `env` can map both `cluster` and `environment` source keys to the set of inconsistent deployment values. The same query then becomes: ```text theme={null} {__name__="request_errors",env="production"} ``` Observability Platform applies this mapping to every query that references `env`, and the original data remains unchanged. If another deployment value is added, you only need to update the `env` derived attribute to propagate the change to every query that references it. ## View derived attributes The Attributes Catalog's **Derived** tab lists all derived attributes in a single table, and provides tools to create, view, update, and delete them depending on your permissions and how each attribute is managed. To view the derived attributes catalog: 1. In the navigation menu, click **System Library > Attributes Catalog**. 2. Click the **Derived** tab to view the table of derived attributes. The table has the following columns, and can be sorted by clicking the column's header: * **Label name**: A link to the derived attribute's [details panel](/investigate/system-library/attributes-catalog#view-attribute-details). * **Values**: The number of values mapped to the attribute. * **Mapped telemetry**: The derived attribute's telemetry type. * **Managed**: How the derived attribute was created, which also defines how it can be modified. Attributes managed by the **UI** can be edited and deleted from the UI, while attributes managed by **Terraform** must be modified or deleted by Terraform. To access additional tools and information about a derived attribute, click its row's three vertical dots icon. * To view a derived attribute's [details](/investigate/system-library/attributes-catalog#view-attribute-details), select ** View details**. * To view a derived attribute's definition as a Terraform resource, Chronoctl YAML, or API-compatible JSON, click ** View code config**. * To open a derived attribute in the [](/investigate/analyze/usage), click ** Open in Usage Analyzer**. * For UI-managed derived attributes only: * To edit a derived attribute, click ** Edit derived attribute**. * To delete a derived attribute, click ** Delete derived attribute**. Click the **Rows per page** dropdown to change the number of displayed rows, and click the ** Previous page** and ** Next page** buttons to navigate between table pages. To display derived attributes for metrics labels with [Chronoctl](/tooling/chronoctl), see [Derived labels](/investigate/querying/metrics/derived-telemetry/derived-labels). To complete this action with the Chronosphere API, use the [`ListDerivedLabels`](/tooling/api-info/definition/operations/ListDerivedLabels) endpoint. ## Create a derived attribute To create a derived attribute in the Observability Platform user interface: 1. In the Attributes Catalog, select the **Derived** tab. 2. Click **Create derived attribute**. 3. Enter a name for the attribute in the **Derived attribute name** field. 4. Optional: Describe the derived attribute in the **Description** field. 5. Add at least one **source key**. See [Source keys](#source-keys) for details. 6. Optional: Add custom value mappings. See [Custom mappings](#custom-mappings) for details. 7. Click **Create** to save and activate the derived attribute. To create a derived attribute from metrics labels, see [Derived labels](/investigate/querying/metrics/derived-telemetry/derived-labels). To create a derived attribute from metrics labels, see [Derived labels](/investigate/querying/metrics/derived-telemetry/derived-labels). To complete this action with the Chronosphere API, use the [`CreateDerivedLabel`](/tooling/api-info/definition/operations/CreateDerivedLabel) endpoint. Creating a derived attribute that shares its name with an existing label can cause unexpected behaviors. Rules that expect a specific set of labels might not match when the derived attribute is present. ### Source keys **Source keys** are the metric labels{/* , trace tags, or log fields */} that comprise a derived attribute. Each derived attribute must have at least one source key. #### Create a source key To add a metric label as a source key: 1. Click **Add metric label**. 2. Enter the source label name. 3. Optional: Add filters to limit which time series the derived attribute applies to. Each filter specifies a label name and a [glob pattern](/investigate/querying/glob-syntax) for matching values. #### Reorder source keys When multiple source keys could apply to the same data, the source key at the top of the list takes priority. To change a source key's order in the list: * Click and drag it by its ** Drag to reorder** handle to its new row. * Click the **Move up** and ** Move down** buttons on its row to reorder it one row at a time. #### Remove a source key To remove a source key: 1. Click the ** Remove** icon on its row. A dialog appears to confirm the source key's removal, which will also remove any [value mappings](#value-mappings) for that source. 2. Click **Remove** to confirm the source key's deletion. You can also remove a source key by clicking the three vertical dots icon on the source key's column in the **Value** section and clicking **Remove source key**. A derived attribute must have at least one source key. If only one source key remains, Observability Platform deactivates all source key removal controls. ### Value mappings A *value mapping* maps one or more source key values to a derived value. A derived attribute's **custom value mappings** each map one or more source values to a derived value. After you add source keys to a derived attribute, Observability Platform displays a preview of **default value mappings** generated by consolidating all observed values across all source keys. When the same value appears in multiple source keys, those are grouped into a single default mapping. A custom value mapping can create a new relationship between one or more source values and a derived value. For example, a derived value can combine multiple equivalent values into a single value, which can simplify queries for that value. A derived value can also rename a value with an obscure name to a more accurate name in Observability Platform, even if you don't have access to modify the source. #### Filter value mappings To filter the list of value mappings, click the **Search values** field in the **Values** section and begin entering text. The table of custom and default value mappings updates to display only the rows with matching derived or source values. To return to the unfiltered view, delete the contents of the **Search values** field. #### Manually create a custom value mapping To manually define a custom value mapping: 1. In the **Values** section, click **+ Add custom value mapping** to create a new custom value mapping row. 2. In the **Derived value** field, enter a target value that Observability Platform produces when source data matches. 3. For each source key column, select one or more source values or enter a source value pattern. A pattern can be a comma-delimited list of source values, and can use [glob syntax](/investigate/querying/glob-syntax) to match values from the corresponding source key. You can add custom mappings for values that don't yet exist in your data. When matching data arrives, the derived attribute maps the data to the target value. #### Create a custom value mapping by merging value mappings You can create a custom value mapping by merging multiple other value mappings: 1. In the **Values** section, click the selection boxes for each value mapping that you want to merge. Your selection can include both default and custom value mappings. 2. Click **Merge selected**. The merged row contains all source value patterns from the selected rows. This either creates a new custom value mapping or updates an existing custom value mapping if one was included in the selection. #### Create a custom value mapping by customizing a default mapping To rename a default value mapping, create a new custom value mapping and populate it with the default mapping's values. 1. In the **Values** section, click the selection boxes for each default value mapping that you want to customize. 2. Click **Customize defaults**. This moves the default value mapping to a new custom value mapping with the same values. 3. Modify the **Derived values** column's value to rename the mapping. You can also customize a default value mapping by clicking the three vertical dots icon on its row and clicking **Customize**. #### Remove a custom value mapping To remove a custom value mapping: 1. In the **Values** section, click the selection boxes for each custom value mapping that you want to remove. 2. Click **Remove custom**. #### Ordering When custom value mappings use glob patterns, the order of rows determines precedence. If a source value matches patterns in multiple rows, the first matching row applies. Overlapping glob patterns within the same source key column aren't allowed. To change a custom value mapping's order in the list: * Click and drag it by its ** Drag to reorder** handle to its new row. * Click the **Move up** and ** Move down** buttons on its row to reorder it one row at a time. ## Edit a derived attribute To edit a derived attribute in the Observability Platform user interface, the attribute must have been created in the user interface. To modify derived attributes created and managed by Terraform, you must update and apply its Terraform resource. To edit a derived attribute in the Observability Platform user interface, you must have administrative privileges. 1. In the Attributes Catalog, click the **Derived** tab. 2. Click the three vertical dots icon for the attribute you want to edit. 3. Click ** Edit derived attribute**. 4. Modify the attribute configuration. 5. Click **Save**. A confirmation dialog displays the entities that use the attribute, including [dashboards](/observe/dashboards), [monitors](/investigate/alerts/monitors), [SLOs](/observe/slo), [recording rules](/control/shaping/shape-metrics/rules/recording), [drop rules](/control/shaping/shape-metrics/rules/drop-rules), and [aggregation rules](/control/shaping/shape-metrics/rules). ## Delete a derived attribute When a derived attribute is deleted, all entities that reference it are affected. To delete a derived attribute in the Observability Platform user interface, you must have administrative privileges. 1. In the Attributes Catalog, select the **Derived** tab. 2. Click the three vertical dots icon for the attribute you want to delete. 3. Select ** Delete derived attribute**. 4. Review the impact summary, which lists the number of [dashboards](/observe/dashboards), [monitors](/investigate/alerts/monitors), [SLOs](/observe/slo), [recording rules](/control/shaping/shape-metrics/rules/recording), [drop rules](/control/shaping/shape-metrics/rules/drop-rules), and [aggregation rules](/control/shaping/shape-metrics/rules) that use the attribute. 5. Click **Delete** to confirm. Deleting a derived attribute doesn't delete the underlying source keys or their data. However, you should update any queries or tools that referenced the derived attribute if you intend to continue using them to track that data.