Monday, 9 a.m.: finance forwards a Snowflake invoice that is 40% higher than last month and asks who burned the credits. Nobody on the team can answer without digging through query history by hand. That is the situation Snowflake Dynatrace is meant for: putting credits, warehouses and queries in the same tool as the rest of your telemetry. The vendor introduces the feature in its announcement; what follows is a practitioner’s reading of the documentation pages and the agent’s repository.
I will frame it around three decisions you have to make before opening anything: who runs the installation SQL, how you prove data is flowing, and which questions to ask first. Everything here is Dynatrace SaaS with Grail.
A word on method: span.observer has not deployed this integration on a Snowflake account. The facts below come from pages read on 8 November 2026, and anything I could not read is marked « not verified ».
What Snowflake Dynatrace actually installs
Behind the wizard sits an open source component, the Dynatrace Snowflake Observability Agent (DSOA). It lives inside your Snowflake account as objects and scheduled tasks, and ships logs, OpenTelemetry spans, metrics, events and business events to Dynatrace. The documentation lists five uses: warehouse health, query performance, credits, security and data quality.
Two warnings up front. The integration needs a SaaS environment with Grail; I found no equivalent Managed page, so I promise nothing there. And if you still run the older Snowflake extension (the one that goes through an ActiveGate and queries Account Usage), it is declared deprecated: its page advises moving from password authentication to programmatic access tokens or to DSOA. Migrate rather than reconfigure it.
First decision: who touches the SQL?
In the Data Observability app, New connection then Snowflake opens a wizard built around one trade-off: how much you trust Dynatrace inside your account.
- Managed deployment: you hand over temporary credentials and Dynatrace runs the scripts. Quicker, but it needs EdgeConnect and means letting a third party run DDL in your account.
- Manual scripts: you download them, your security team reviews and runs them. This is my default in a regulated setting, because every statement is traceable on your side.
The second setting is future grants. Enabling them means « also watch the schemas and tables that appear tomorrow ». Declining forces you to list visible objects, which is tidier but heavier to maintain. Before going further, read the summary the wizard prints: it separates the scripts that are yours from those Dynatrace executes.
Connecting the account without leaving secrets lying around
Line up an ACCOUNTADMIN login, once, for initialisation. In managed mode you run the initialisation script, create a dedicated service user and grant it the DTAGENT_OWNER role. The wizard then asks for the account name (the docs use myorganization-myaccount as an example), the host and an environment label such as production. Pick JWT, PAT or OAuth, enter the user and its private key, then select Validate.
A reassuring detail: those credentials are only used for the installation, and the page says you can remove them afterwards. In manual mode you only supply account, host, label and the Dynatrace token. The wizard can generate that token and shows it once, so copy it into a vault straight away. Run scripts may take up to 30 minutes.
The cost of the integration appears on none of the pages I read: not verified. For the old extension the docs described plain billing of ingested data; watch your Dynatrace consumption over the following days.
For automation: the agent from the command line
If you manage several accounts or want a repeatable CI deployment, the dynatrace-oss/dynatrace-snowflake-observability-agent repository (MIT) ships a Docker image. Its docs/INSTALL.md makes that the recommended route: a first interactive run produces conf/config-production.yml, a second one deploys. The conf folder must be mounted, otherwise the configuration vanishes with the container.
The token goes in the DTAGENT_TOKEN variable and needs five scopes: logs.ingest, metrics.ingest, bizevents.ingest, openpipeline.events and openTelemetryTrace.ingest. Add storage:events:read if you want to check telemetry from the Dynatrace side; the repository also provides deploy.sh --env=production --scope=verify. Allow 30 minutes before the Snowflake tasks first run, and up to 24 hours for budget metrics. How this path relates to the graphical wizard, the pages I read do not say: not verified.
Second decision: how will you know data arrives?
A silent pipe is worse than no pipe. Three checks, in order:
- Settings > Apps > Data Observability connections: Health Status should read Connected, and Last data received should keep moving.
- Data Observability > Ready-made dashboards > Snowflake Observability Agent Self-Monitoring: the Plugin runs tile shows whether the agent’s plugins fire at regular intervals.
- Then let time do its work: fourteen dashboards (security, costs, performance, quality, operations) are created and usually fill within two hours.
Treat this as your first freshness indicator: if the gap between receipts grows, investigate the agent before you trust any cost chart.
Third decision: the first two DQL questions
The ready-made dashboards answer generic questions. For the invoice Monday, you have to go down to the spans. The Snowflake page of the Semantic Dictionary supplies reference queries; the first looks, over seven days, for queries where a join emits more rows than it receives, the classic sign of a join that multiplies rows. My screenshot shows a shortened version.
Read it as a funnel. db.system == "snowflake" drops everything that is not Snowflake; dsoa.run.plugin == "query_history" keeps only spans from the query history; snowflake.query.operator.type == "Join" isolates joins, whose numbers live in snowflake.query.operator.stats. To rank the culprits, timings are in snowflake.time.total_elapsed, snowflake.time.execution and snowflake.time.compilation.
The second question is about warehouses: the same page offers a time series of resume and suspend latency, using snowflake.warehouse.name and the RESUME_WAREHOUSE and SUSPEND_WAREHOUSE events. A warehouse that wakes every ten minutes for a query lasting a few seconds often explains a credit spike. I ran none of these queries on a real environment: not verified. For syntax, revisit the DQL filter, summarize and timeseries commands.
What can go wrong
- SaaS with Grail only; nothing read about Managed.
- No initial installation without
ACCOUNTADMIN, and it can take half an hour. - Credits and budgets lag: up to 24 hours for budgets, per the repository.
- The repository showed 10 stars when I read it, so little community feedback, but its README states official vendor support.
- Credentials of the old extension cannot be read back, and its end-of-life date is not given in the pages I consulted.
Habits worth adopting
- A dedicated service user on JWT or PAT, never a shared password.
- One label per connection (
production,staging) so your queries filter cleanly. - A token limited to the listed scopes and kept in a vault; for the rest of the SaaS API, see the API schemas.
- Cost dashboards in front of the FinOps team, extended with custom DQL dashboards.
- No reconciling Snowflake credits with your Dynatrace invoice before reading your contract: not verified here.
Frequently asked questions
Does the Snowflake Dynatrace integration work on Managed?
The documentation I consulted reserves it for SaaS environments with Grail, and I found no Managed page. Until someone shows otherwise, treat it as SaaS only.
What happens to the old Snowflake extension?
It is marked deprecated and replaced. The 1.349 release notes spoke of an upcoming deprecation, while its page already calls it deprecated. Password authentication gives way to PATs or DSOA.
Do I have to install the agent myself?
Not necessarily: the wizard can deploy everything. The repository’s Docker image mainly suits scripted or CI deployments.
Conclusion
Decide who runs the SQL, prove data arrives, then question the spans instead of settling for dashboards. Try a test account first and keep an eye on consumption. The natural next read: the differences between Grail and Classic.
span.observer is an independent community blog, not affiliated with Dynatrace LLC (nor with Snowflake). Brands mentioned belong to their owners. Tools change quickly: check commands and options in the official documentation.
Originally published on span.observer. French version: https://span.observer/fr/snowflake-dynatrace-data-observability/.
Top comments (0)