Linking Splunk AppDynamics (Cisco) as a source

Alpha release

This source is currently in alpha. The interface and available tables may change.

The Splunk AppDynamics (Cisco) connector syncs your APM data into the PostHog Data warehouse, including applications, business transactions, tiers, nodes, health rule violations, and metric time series. This lets you join application performance signals with your product data for SLA and SLO reporting.

Prerequisites

You need access to an AppDynamics controller (SaaS or on-premises) and either:

an API client created under Administration → API Clients in your controller (recommended), or
a username and password for a local controller user.

The API client or user needs read access to the applications you want to sync. If your account signs in via Cisco Identity Provider, basic authentication is disabled and an API client is required.

Adding a data source

In PostHog, go to the Sources tab of the data pipeline section.
Click + New source and click Link next to this source.
Enter your credentials (see Configuration below) and click Next.
Select the tables you want to sync, choose a sync method and frequency, then click Import.

Once the syncs are complete, you can start querying this data in PostHog.

When linking AppDynamics, you'll need:

Controller URL – your controller's base URL, e.g. https://mycompany.saas.appdynamics.com.
Account name – your controller account name, e.g. mycompany. You can find it under Settings → License in the controller.
Authentication – either an API client name and client secret, or a username and password.
Metric paths (optional) – the metric browser paths to sync into the metric_data table, one per line. Wildcards are supported, e.g. Business Transaction Performance|*|*|Average Response Time (ms). Defaults to Overall Application Performance|*.

Sync modes

Each table can be synced in one of several modes, depending on what the source supports:

Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
Incremental – only new or updated rows are synced on each run, using a cursor field (such as an updated_at timestamp). Cheaper than a full refresh, but deletes aren't captured.
Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.

See sync methods for a full explanation of how each mode works and how to choose between them.

The health_rule_violations and metric_data tables sync incrementally using the row's start time (startTimeInMillis). Violations are synced when they start, so status changes to previously synced violations (for example, a violation resolving) are only picked up on a full refresh. The other tables support full refresh only.

Configuration

Option	Type	Required
`Controller URL`	text	Yes
`Account name`	text	Yes
`Authentication method`	select	Yes
`Metric paths (one per line)`	textarea	No

Supported tables

Table	Description	Sync method	Incremental field	Primary key
`applications`	Business applications monitored by the AppDynamics controller.	Full refresh	—	—
`business_transactions`	Business transactions registered for each monitored application.	Full refresh	—	—
`tiers`	Tiers (logical service groupings of nodes) for each monitored application.	Full refresh	—	—
`nodes`	Nodes (individual monitored processes or JVMs/CLRs) for each monitored application.	Full refresh	—	—
`health_rule_violations`	Health rule violations are synced by their start time. Status changes to previously synced violations (e.g. a violation resolving) are only picked up on a full refresh. Only syncs the last 30 days on initial sync.	Incremental, Full refresh	startTimeInMillis	—
`metric_data`	Metric time series for the metric paths configured on the source (defaults to 'Overall Application Performance\|*'). One row per metric per interval. Only syncs the last 7 days on initial sync.	Incremental, Full refresh	startTimeInMillis	—

Troubleshooting

If you see an authentication error, your credentials are invalid or expired, or the OAuth token exchange failed. Check your controller URL, account name, and API client name and secret, then reconnect.
If you see a permissions error, your user or API client is missing read access to application data. Grant the required roles in the controller, then reconnect.
If the metric_data table is empty, check that your configured metric paths match entries in the controller's metric browser for the synced applications.

If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.