Create and verify the application inventory

Reference information for creating and verifying the application inventory and planning OpenTelemetry service identity.

Generate the required reports by following Generate Reports.

When you need to confirm report-generation activity, review the Report entries on the Audit Logs page. Audit entries identify the recorded action, user, and timestamp. Use the generated reports to verify the application scope and inventory details.

Report Actions Result

Application Discovery

Confirm the Controller and account. Review the discovered applications and monitoring domains. Compare the application count with the environment assessment. Identify missing, unexpected, test, obsolete, or duplicate applications.

Mark every discovered application as In scope, Out of scope, Deferred, or Review required.

APM Application Inventory

For each in-scope application, verify its tiers, nodes, Business Transactions, Health Rules, backend dependencies, agents, and instrumentation against Splunk AppDynamics.

Document differences, missing information, and configurations requiring further assessment.

Complete the inventory with information the reports cannot determine:

  • Application owner and business purpose.
  • Business criticality and service objectives.
  • Change window.
  • Traffic patterns and peak periods.
  • External integrations and notification requirements.
  • Custom metrics, data collectors, exit calls, extensions, and instrumentation.
  • For every .NET application, record the .NET runtime and framework version, operating system, architecture, hosting model, agent packaging method, current Splunk AppDynamics Agent version, and deployment process. Identify applications that might not support the .NET combined agent so that you can confirm compatibility before deployment.
  • Historical-data and retention requirements.
  • Known monitoring gaps and dependencies.
  • Owner and action for every unresolved finding.
  • Application-owner approval of the completed inventory.
  • Record the preliminary target mapping and naming requirements for each important APM concept.
  • Assign an initial migration disposition to each material telemetry type, configuration, artifact, and capability.

Plan the OpenTelemetry service identity

Define the target service identity for every in-scope application before configuring the combined agents.

Attribute Starting point How to determine the value

service.name

Splunk AppDynamics tier name

Select the stable name of the logical service represented by the tier. Use the same value for every instance of that service. Do not include host names, node names, versions, or environment names.

service.namespace

Splunk AppDynamics application name

Select the stable grouping for related services. Use it to distinguish services with the same name that belong to different applications or business domains.

deployment.environment

Approved environment name

Use the organization’s approved environment value, such as production, staging, or development. Apply the same convention to every service in that environment.

For each application:

  1. Review its Splunk AppDynamics application, tier, node, and environment structure.
  2. Determine whether each tier represents one logical target service.
  3. Define the service.name, service.namespace, and deployment.environment values.
  4. Document any tiers that require renaming, combining, or separating in Splunk Observability Cloud.
  5. Record the source-to-target mapping in the application inventory.
  6. Confirm that the combination of environment, namespace, and service name uniquely identifies the logical service.
  7. Obtain approval from the application owner and observability administrator.

Reuse the approved values when configuring agents, validating traces, and creating dashboards, detectors, and filters.

The inventory reaches completion when every application has a scope decision and every in-scope APM application has a verified inventory.