cancel
Showing results for 
Search instead for 
Did you mean: 
Administration & Architecture
Explore discussions on Databricks administration, deployment strategies, and architectural best practices. Connect with administrators and architects to optimize your Databricks environment for performance, scalability, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 

Correlate Databricks App with Logs

discuss_darende
New Contributor III

I have a question about correlating Databricks system tables.

We are currently using the outbound_network and audit system tables. When a Databricks App makes an outbound network request, the request appears in the outbound network table with details such as the destination, event_id, and timestamp. However, the network_source_type is shown as unknown.

I have tried matching the outbound network event_id and timestamp with records in the audit table, but I have not found a reliable relationship between them.

What is the recommended way to identify which Databricks App generated a specific outbound network request?

For example, if we have 100 applications and several outbound calls to different destinations, how can we reliably associate each network event with the application that initiated it?

 

PS. I have checked event_id and timestamps doesn't work to identify the solution.

1 REPLY 1

iyashk-DB
Databricks Employee
Databricks Employee

Hi @discuss_darende, there's no join key today that ties an outbound_network row back to a specific app instance. network_source_type only tells you the request came from the "Apps" compute category, not which of your 100 apps made it. That's also why matching on event_id or timestamp against audit isn't working, audit's app events (createApp, updateApp, the ACL change events) are control plane actions. They don't fire once per outbound HTTP call, so there's nothing on that side to line up with a network event in the first place.

A few ways to actually get there at your scale:

  1. Filter by destination and time window first. Since you're presumably allowlisting domains per app already, most outbound_network rows can be mapped back to an app just by which destination it hit and when that app was running. With 100 apps, odds are most of them aren't calling the exact same handful of third party endpoints, so this gets you further than it sounds.
  2. Instrument the apps themselves. You control the app code, so this is the reliable fix. Turn on OpenTelemetry auto instrumentation for whatever framework you're running (Flask, FastAPI, Streamlit, etc.) and it'll capture outbound HTTP calls as spans. Databricks Apps can export otel_logs, otel_spans, and otel_metrics into Unity Catalog once you wire up the OTel exporter, so you get per app, per request traces you control instead of trying to reverse engineer identity out of the network table.
  3. If you're on serverless egress with Network Connectivity Configs, you can scope a separate NCC per app so each one can only reach its own destinations. That makes the destination itself a de facto identifier. Not a real join key, but workable if you're already set up that way.

Instrumenting the apps directly (option 2) is going to be more durable option.