Azure Application Proxy Logs
You collect azure application proxy logs from two main sources in your cloud setup. First, check Microsoft Entra sign-in records, and then read local Windows event files. Most teams start by turning on cloud audit streams for their published web apps. They also check the local agent host when users report slow page loads. Still, teams often grant broad admin roles just to view these log files. Giving wide read rights to whole hosts exposes private system data to too many people. How azure appl
Application-to-Application Password Management + Database Proxy (ProxySQL, PgBouncer): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You collect azure application proxy logs from two main sources in your cloud setup. First, check Microsoft Entra sign-in records, and then read local Windows event files. Most teams start by turning on cloud audit streams for their published web apps. They also check the local agent host when users report slow page loads. Still, teams often grant broad admin roles just to view these log files. Giving wide read rights to whole hosts exposes private system data to too many people.
How azure application proxy logs work in your setup
The Microsoft service splits log data between the cloud and your local server. In the cloud, Microsoft Entra records every user login attempt and rule check. These cloud logs show who tried to open an app and when they did it. You can send these cloud records to a central log workspace for long-term storage. From there, security teams run search queries to spot failed login patterns.
On your local network, a small software agent runs on a Windows server. This local agent handles the actual traffic between the cloud and your internal app. When the agent runs into a network fault, it writes to Windows Event Viewer. It stores basic operational alerts and deep session trace events in separate local channels. Admins must log in to the Windows server to read these local agent files. Some teams also install a log shipper to send local Windows events to the cloud.
How to match cloud sign-ins with local agent events
Fixing a broken app session requires matching cloud records with local server events. When a user hits an error page, the cloud generates a unique trace ID. Support engineers ask the user for this ID and the exact time of the error. Next, the engineer searches the cloud sign-in logs for that specific trace string.
If the cloud sign-in passed, the problem sits inside the local network path. The engineer then opens the Windows event logs on the local agent host. They filter the local session records using the same trace ID from the cloud. This match shows whether the local agent failed to reach the backend web server. It also reveals certificate errors, DNS lookup failures, or Kerberos ticket mistakes on the network.
Application-to-Application Password Management + Database Proxy (ProxySQL, PgBouncer): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native logs solve and what they leave out
Native logging proves its value when you need to fix connectivity or sign-in bugs. Cloud records confirm that your conditional access rules block bad login attempts at the edge. Local Windows events help network teams fix broken TLS handshakes and backend routing issues. Together, they give a clear view of user sign-ins and basic HTTP connection health.
Still, this native setup only tracks who logs in and whether the network link works. It does not inspect what users or scripts do inside the session after login. Once the connection opens, the logs do not capture individual database queries or admin commands. Also, native logs cannot mask sensitive fields like emails, phone numbers, or card numbers. If an internal app returns raw customer data, the native service passes it right through. Teams also lack a way to require peer approval for risky actions inside the app.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Where do I find local agent logs on my Windows server?
Open the Windows Event Viewer and look under the Applications and Services Logs folder. There you will find the Microsoft Entra private network connector operational and session channels.
Why do my local session logs appear empty during a check?
Local session trace logs are turned off by default to save disk space. An admin must manually turn on the session log channel inside Event Viewer while testing.
Can I send local agent logs to a central cloud workspace?
Yes, you can install a monitoring agent on the Windows host that runs the connector. That monitoring agent reads the local Windows event channels and forwards them to your workspace.