Network egress observability [Beta]

Observability in Control Panel

In the network egress policy page, the Observability tab contains logs and metrics for uses of the network egress policy per data connection source that imports this policy.

Select a data connection source in the source picker and view the network egress logs and metrics that were created with the policy.

Observability in Builds

Network egress logs are included in build telemetry. To view only network egress logs, add the suggested Network egress logs filter .

Log definition

Network egress logs derived from different origins are available to help diagnose connectivity issues across all Foundry networking layer methods, such as direct connection or agent proxy policies.

connectivity-sidecar origin

connectivity-sidecar routes connections to the appropriate network egress policy used for transparent proxy routing, and its logs contain the following parameters:

• connection_id: A unique identifier for the connection.
• response_flags: Response can be either success or failed.
• bytes_sent: The number of bytes sent from the sidecar to the outbound proxy.
• bytes_received: The number of bytes received by the sidecar from the outbound proxy.
• duration_ms: The duration of the connection in milliseconds.
• destination_port: The destination port of the connection.
• metadata:
  • network_policy: Resource identifier of the network egress policy that egress was attempted with.
  • source: Resource identifier of the data connection source that egress was attempted for.
  • network_type: Type can be either direct or agent proxy.
  • network_resources: Data connection agent IDs if agent proxy network egress policy.

egress-proxy origin

egress-proxy is the service that handles explicit proxy connections.

on-prem-proxy origin

on-prem-proxy is the service running in Foundry that proxies traffic to a data connection agent when using agent network egress policies.

agent-proxy origin

agent-proxy is the service running on a data connection agent in a private network. It opens the connection to the end destination for agent network egress policies.

Direct connection

There are two possible outcomes for direct connection egress: successful or failed.

Successful egress

Traffic successfully egressed out of the Palantir platform. The connection could still fail due to issues with ingress firewalls on the destination, authentication, or TLS handshake, but this is considered a successful egress as traffic has left the Palantir platform.

Failed egress

Traffic failed to egress out of the Palantir platform.

Next steps:

• Verify the existence of the address and port through which egress was attempted and ensure that they are resolvable by the Palantir platform's direct connected network.
• If traffic is still failing to egress, contact Palantir Support.

Agent proxy

There are two possible outcomes for agent proxy: successful egress or failed egress.

Successful egress

Traffic was successfully proxied to one of the data connection agents of the policy. The connection could still fail due to issues with ingress firewalls on the destination, authentication, or TLS handshake, but this is considered a successful egress as traffic was proxied to a backing data connection agent.

Failed egress

Traffic failed to egress out of the Palantir platform.

Next steps:

• Verify that the address and port through which egress was attempted have a corresponding network egress policy imported in the data connection source.
• Ensure that all of the backing data connection agents of the agent proxy policy are healthy.
• If traffic is still failing to proxy to the data connection agent, contact Palantir Support.

Limits

Network egress observability is only provided for network egress policies which use TCP-level allowlisting.