Troubleshoot Syslog Issues in Prisma Cloud

Provide guidance on configuring Syslog logging in Prisma Cloud, understanding the end-to-end log flow, and troubleshooting common integration issues.

• Prisma Cloud SAAS
• Prisma Cloud Compute

Understanding Syslog Configuration

Prisma Cloud provides the ability to forward audit and operational logs using Syslog. This functionality can be enabled from the Prisma Cloud Console under:

Runtime Security -> Manage -> Alerts -> Logging

 

In Prisma Cloud Compute Edition (self-hosted), when Syslog logging is enabled, logs will be written locally to the Console host via the /dev/log socket. This is the standard local syslog socket, allowing logs to be collected directly from the host by a local syslog daemon.
In addition, an external Syslog endpoint can be configured to forward logs to a remote system or SIEM.

In Prisma Cloud Enterprise Edition (SaaS), there is no option to write logs to a local host socket, as the Console is managed by Palo Alto Networks. In this deployment model, the only supported method for Syslog integration is to configure an external Syslog endpoint to which Prisma Cloud forwards the logs.

Configuring an external Syslog endpoint in Prisma Cloud is straightforward. Prisma Cloud supports the following delivery options:

• UDP on port 514 - Unreliable and unencrypted

• TCP on port 514 - Reliable, but unencrypted

• TCP with TLS on port 6514 - Reliable and encrypted

  • When using this option, a certificate is required. Prisma Cloud expects a trusted root CA certificate so it can validate the server certificate and securely encrypt the Syslog traffic using TLS.

These are the only configurations required on the Prisma Cloud side.

On the receiver side, the customer must ensure that:

• A Syslog listener is running on the configured port

• The listener matches the selected protocol (UDP, TCP, or TCP with TLS)

• No network security rules or firewalls are blocking inbound traffic on the selected port

Once the configuration is enabled and saved, Prisma Cloud will begin forwarding both Console and Defender logs to the configured external Syslog endpoint.

There is also an option under Runtime Security -> Manage -> Logs -> Console, to "Send Debug Logs to Syslog".

 

When clicked, Prisma Cloud forwards the entire set of debug logs to the configured external Syslog endpoint in a single operation. During this process, the forwarding of other logs is temporarily paused until all debug logs have been successfully sent.

In Prisma Cloud Enterprise Edition (SaaS), an external Syslog endpoint must be configured for this operation to succeed. If no endpoint is defined, the operation will fail and an error message will be recorded in the Console logs.


This error may also occur if the configured Syslog endpoint URL is malformed.

Other common errors are:

"Failed dialing syslogger, failed to parse server certificate"

This typically indicates that the certificate is incorrect or that the provided certificate is not a valid CA certificate.

"Failed dialing syslogger, grace period has not yet passed since last syslog dial failure"

This error may appear when attempting to send logs immediately after a previous failure.

How to Setup a Syslog Lab for Reproduction and Troubleshooting:

In some cases, you may want to verify whether Prisma Cloud is sending any Syslog messages at all. For this purpose, you can set up a simple, temporary Syslog server for testing.

This approach is also useful when guiding a customer to configure a secondary Syslog endpoint. By doing so, you can help determine whether the issue lies with the original endpoint or with network or firewall restrictions in the customer’s environment.

Steps to Create a Syslog Server / Lab
1. Create a VM on any Cloud Provider.
2. In this example we will use commands for a Ubuntu / Debian.
3. Install rsyslog

sudo apt update
sudo apt install -y rsyslog

4. Edit configuration file and set correct protocol and port.

sudo nano /etc/rsyslog.conf

5. Uncomment or add these lines near the top (depends on udp/tcp)

module(load="imudp")
input(type="imudp" port="514")

6. Restart the service

sudo systemctl restart rsyslog
sudo systemctl status rsyslog

7. Observe logs incoming live

sudo tail -f /var/log/syslog

8. You can also run a "tcpdump" to capture traffic

sudo tcpdump -n udp port 514

• If no logs are forwarded after configuring the public IP address in Prisma Cloud, this typically indicates that firewall rules or network security controls are blocking traffic on the selected port or protocol.
• If you suspect the issue is related to Prisma Cloud, you can send a test Syslog message to the endpoint from your laptop or from another host to validate reachability and confirm whether the endpoint is receiving traffic.
  

  logger -n <PUBLIC_IP> -P 514 -d "TEST SYSLOG UDP 514"

• In Windows you can use PowerShell:
  

  $udp = New-Object System.Net.Sockets.UdpClient
  $udp.Connect("<PUBLIC_IP>", 514)
  
  $msg = "<13>EXTERNAL UDP TEST from Windows"
  $bytes = [Text.Encoding]::ASCII.GetBytes($msg)
  
  $sent = $udp.Send($bytes, $bytes.Length)
  $sent
  $udp.Close()

• If the test log appears in your Syslog test environment, this confirms that the Syslog receiver and network path are functioning correctly. In this case, the issue is likely related to Prisma Cloud itself or to the network route between Prisma Cloud and the configured endpoint.
  
  
• As a best practice, it is important to map the entire log-delivery path. Identify where the Prisma Cloud Console is hosted, whether it is a SaaS deployment or a self-hosted environment, and verify that nothing along the path is preventing outbound traffic to the Syslog endpoint. This includes checking for firewalls, proxies, network security devices, or TLS/SSL inspection mechanisms that may block or intercept the traffic.

• Official Prisma Cloud Syslog Documentation