Configure operation grouping rules

Configure an operation grouping rule when related operations share a common naming pattern and you want to analyze their combined performance. For example, group checkout/validate, checkout/submit, and checkout/confirm by the checkout/ prefix to monitor the overall request rate, error rate, and duration of checkout operations. Grouping reduces unnecessary cardinality and simplifies aggregate analysis while keeping the original operation name available in trace search.

Operation grouping complements low-cardinality OpenTelemetry span names. Operation grouping rules do not change the operation names that your instrumentation generates. If an operation name contains dynamic values, such as request IDs, user IDs, or raw URL parameters, update the OpenTelemetry instrumentation before configuring an operation grouping rule. For example, correct an operation name such as GET /orders/847293 to a stable pattern such as GET /orders/{orderId} before grouping it.

Prerequisites

Confirm that:

• [ ] Business Transaction compliance analysis identified operations that need grouping.

• [ ] Representative traces include all important operation variants.

• [ ] The service and environment values match the migration inventory.

• [ ] The proposed group represents one meaningful operational outcome.

Decide whether to group operations

Use an operation grouping rule when:

• Many operations share a stable prefix.

• The variants have the same monitoring and alerting requirements.

• Grouping materially reduces cardinality.

• Operators do not need separate RED metrics for each variant.

Do not group operations when the variants have different owners, service objectives, detector thresholds, or diagnostic meaning.

Configure the rule

For each proposed grouping:

1. Select the service that reports the operations.

2. Review the observed operations and the estimated cardinality reduction.

3. Select a stable prefix that does not contain identifiers, timestamps, request values, or other unbounded data.

4. Compare the proposed group with the Splunk AppDynamics Business Transaction behavior.

5. Configure the rule at the service level.

6. Record the rule name, service, prefix, affected operations, purpose, and owner.

7. Generate representative traffic.

Verify the result

Confirm that:

• The expected group aggregates matching operations.

• Unrelated operations remain separate.

• Dashboard and metric views use the intended aggregation.

• The original operation names remain visible and searchable in traces.

• Cardinality is reduced without hiding an operationally important distinction.

• Update detectors and workflows that use the affected operations when required.

If operation names still contain dynamic identifiers, correct the OpenTelemetry instrumentation or span naming before expanding the grouping rule.

This task is complete when every approved grouping behaves as intended and its operational effect is documented.