Configuring and Managing Log Collectors with Panorama (Version 11.0)
PCNSE Objective Focus
This topic addresses PCNSE objectives related to centralized logging infrastructure using Panorama and dedicated Log Collectors, covering their setup, configuration, and ongoing management.
-
Identify the role and benefits of Log Collectors.
-
Identify the procedure to add and manage Log Collectors in Panorama.
-
Identify the configuration of Collector Groups and Log Forwarding.
-
Understand the relationship between Panorama, Log Collectors, and managed firewalls for logging.
Overview: Centralized Logging with Log Collectors
While Panorama can store logs locally (especially in Management-Only mode or when using Panorama virtual appliances with logging disks), large-scale deployments often require dedicated
Log Collectors (LCs)
. These are specialized appliances (M-series hardware or VMs) managed by Panorama, designed specifically for receiving, aggregating, and storing large volumes of logs from managed firewalls and Panorama itself.
Benefits of using dedicated Log Collectors:
-
Scalability:
Handle higher log rates and larger storage volumes than Panorama's local logging capabilities.
-
Performance:
Offloads the resource-intensive logging functions from the Panorama management server, improving management UI responsiveness and processing speed.
-
Distributed Logging:
Allows placing Log Collectors geographically closer to groups of firewalls, potentially optimizing log transmission over WAN links (though Panorama still manages them centrally).
-
Redundancy:
Log Collectors can be grouped into
Collector Groups
for high availability and load distribution.
Panorama acts as the central point for configuring the Log Collectors, defining Collector Groups, directing log traffic from firewalls, and querying logs stored on the collectors.
Prerequisites for Log Collectors
Before integrating Log Collectors, ensure the following:
-
Hardware/VM Deployment:
The Log Collector appliance (M-series) or VM must be physically deployed and powered on, or the VM provisioned with appropriate resources (CPU, RAM, Disk - ensure sufficient disk space for log storage).
-
Network Connectivity:
-
The Log Collector's management interface requires basic IP configuration (IP, Mask, GW, DNS).
-
The LC's management interface must be able to reach Panorama's management IP (typically TCP/443 for management, potentially other ports like TCP/3978 for log collection status). Verify routing and firewall rules.
-
Panorama must be able to reach the LC's management interface.
-
Firewalls must be able to reach the Log Collector IP(s) they are assigned to forward logs to (typically UDP/4559 or TCP/4560 for logs, depending on configuration).
-
Panorama Configuration:
-
Panorama PAN-OS version must be
equal to or higher than
the Log Collector PAN-OS version.
-
Panorama requires appropriate licensing to manage Log Collectors (often included or part of the support subscription).
-
Know the
serial number
of the Log Collector (physical or virtual).
-
Log Collector State:
-
Compatible PAN-OS version installed.
-
No uncommitted configuration changes.
-
Ideally, configured with basic management settings but not yet pointed to Panorama.
Adding Log Collectors to Panorama (11.0)
The process is similar to adding a firewall:
-
Log Collector Prep:
Configure the LC to point to the Panorama server(s).
Using CLI (Recommended):
configure
set log-collector panorama-server
# Optional: Add secondary Panorama server if applicable
# set log-collector panorama-server-2
commit
exit
Using GUI (Device > Setup > Management > Panorama Settings):
This might vary slightly on an LC interface but generally involves setting the Panorama server addresses.
-
Panorama - Add Serial:
-
Navigate to
Panorama > Managed Collectors
.
-
Click the
Add
button.
-
Enter the
Serial Number
of the Log Collector.
-
Click OK. The LC should appear in the list.
-
Connection & Initial Sync:
The Log Collector attempts to connect to Panorama. Once successful, Panorama recognizes the serial number. Monitor the status in
Panorama > Managed Collectors
until the connection status is 'Connected'.
-
Commit on Panorama:
Perform a
Commit
on Panorama to save the addition of the Log Collector to Panorama's configuration.
Unlike firewalls, Log Collectors are not typically assigned directly to Device Groups or Templates upon addition. Their primary configuration comes from Collector Groups and direct management via Panorama.
Configuring Collector Groups
Collector Groups
are logical containers within Panorama used to group one or more Log Collectors. They are essential for directing log traffic and enabling redundancy.
-
Purpose:
-
Log Forwarding Target:
Firewalls and Panorama are configured to forward logs to a Collector Group, not an individual LC.
-
Redundancy/HA:
If a Collector Group contains multiple LCs, Panorama distributes the log forwarding load across them. If one LC in the group fails, logs are automatically sent to the remaining active LCs in the group.
-
Load Distribution:
Logs are distributed among the LCs within a group.
-
Configuration Location:
Panorama > Collector Groups
.
-
Creating a Collector Group:
-
Click
Add
.
-
Provide a meaningful
Name
for the group (e.g., `Primary-DC-Collectors`, `Regional-Site-Collectors`).
-
Add the desired Log Collectors (by selecting their serial numbers) to the group from the 'Available Collectors' list.
-
(Optional) Configure
Disk Usage Thresholds
and
Log Storage / Forwarding Preferences
within the group settings if needed.
-
Click OK.
-
Commit on Panorama:
Commit the changes on Panorama to activate the new Collector Group configuration.
A Log Collector must be successfully added to Panorama (
Managed Collectors
) before it can be added to a Collector Group.
A single Log Collector can belong to only one Collector Group at a time.
Assigning Log Forwarding to Collector Groups
Once Collector Groups are defined, you need to configure devices to send logs to them.
Forwarding Logs from Managed Firewalls
This is typically configured via
Templates
or
Template Stacks
.
-
Location:
Objects > Templates > [Your Template/Stack Name] > Device > Log Settings
.
-
Within Log Settings, you configure forwarding for different log types (Traffic, Threat, URL, etc.).
-
For each relevant log type section (e.g., System, Config, Traffic), click
Add
.
-
Give the setting a name.
-
Under the
Forwarding
tab or similar section:
-
Configure a
Log Forwarding Profile Match List
(or use built-in forwarding). This uses Log Forwarding Profiles (configured under
Objects > Log Forwarding
) which define detailed filtering criteria and specify the destination (e.g., your Collector Group).
-
Alternatively, some basic log types might have direct options to select a Collector Group as the destination.
-
Click OK.
-
Commit and Push the Template changes to the firewalls.
Using
Log Forwarding Profiles
provides the most granular control over which logs get sent where (Collector Groups, Syslog, Email, SNMP, etc.). These profiles are then referenced in the device Log Settings.
Forwarding Logs from Panorama Itself
Panorama generates its own system and configuration logs, which can also be forwarded to a Collector Group.
-
Location:
Panorama > Log Settings
.
-
Configure forwarding for System and Config logs, selecting the desired
Collector Group
as the destination within the appropriate forwarding settings or profiles.
-
Commit the changes on Panorama.
Managing Log Collectors
Ongoing management tasks for Log Collectors via Panorama include:
-
Monitoring Status:
Check connection status, PAN-OS version, and basic health in
Panorama > Managed Collectors
.
-
Disk Space Management:
-
Monitor disk usage in
Panorama > Managed Collectors > [Select Collector]
.
-
Configure disk usage thresholds and alerts within Collector Group settings or via Log Settings on Panorama.
-
Manage log retention policies (defined globally or per Collector Group) to control how long logs are kept before being purged. Location:
Panorama > Log Settings > Log Storage
.
-
Software Updates:
Upgrade Log Collector PAN-OS versions using Panorama.
-
Download LC software to Panorama:
Panorama > Software
.
-
Push/Install to LCs:
Panorama > Device Deployment > Software
(Select the Log Collectors). Process is similar to firewall upgrades (Push then Install, requires reboot).
-
Content Updates:
Log Collectors generally don't process traffic directly, so dynamic content updates (Apps/Threats) are less critical than for firewalls. However, keeping them updated via Panorama (
Panorama > Device Deployment > Dynamic Updates
) ensures consistency if any features rely on this data.
-
Removing/Replacing LCs:
Requires careful removal from the Collector Group first, then removal from Panorama. Ensure logs are flushed or migrated if necessary before decommissioning.
Best Practices
-
Use Dedicated LCs for Scale:
Deploy dedicated Log Collectors when log volume exceeds Panorama's local capacity or for performance reasons.
-
Use Collector Groups:
Always place LCs within Collector Groups, even if starting with a single LC, to facilitate future expansion and HA.
-
Implement Redundancy:
Use Collector Groups with multiple LCs (ideally in different fault domains) for high availability.
-
Monitor Disk Space Actively:
Set up alerts for disk usage thresholds to prevent log loss due to full disks. Tune retention policies accordingly.
-
Maintain Version Compatibility:
Keep Panorama's PAN-OS version equal to or higher than managed Log Collectors. Upgrade LCs before or alongside Panorama upgrades.
-
Secure Connectivity:
Ensure robust and secure network paths between Firewalls <-> LCs and LCs <-> Panorama.
-
Use Log Forwarding Profiles:
Leverage Log Forwarding Profiles for granular control over log destinations.
-
Plan Resource Allocation:
Provision sufficient CPU, RAM, and especially Disk I/O performance and capacity for Log Collector VMs.
Caveats / Gotchas / Considerations
-
Disk Space Exhaustion:
The most common issue. Leads to log loss if not managed proactively with monitoring and retention policies.
-
Connectivity Issues:
Network problems preventing LCs from reaching Panorama, or firewalls from reaching LCs, will disrupt management and log forwarding.
-
Version Mismatches:
Panorama cannot manage LCs running a higher PAN-OS version.
-
License Limits:
Ensure Panorama is licensed to manage the required number of LCs.
-
Clock Skew:
Significant time differences between Panorama, LCs, and Firewalls can cause issues with certificate validation and log correlation. Use NTP.
-
Collector Group Changes:
Adding/removing LCs from a Collector Group can cause temporary shifts in log distribution. Removing the last LC from a group used by firewalls will stop log forwarding to that destination.
-
Resource Contention (VMs):
Under-provisioned Log Collector VMs (CPU, RAM, Disk I/O) will perform poorly and may drop logs under load.
-
Commit Required:
Changes to Collector Groups, Log Settings, and Log Forwarding Profiles require a Commit on Panorama (and potentially a Push to firewalls for Template changes).
PCNSE Exam Focus (Relevant to 11.0 Concepts)
-
Understand the purpose and benefits of dedicated
Log Collectors
.
-
Know the role of
Collector Groups
for redundancy, load balancing, and as log forwarding targets.
-
Know the Panorama UI locations for managing LCs and Collector Groups:
Panorama > Managed Collectors
,
Panorama > Collector Groups
.
-
Understand that firewalls are directed to forward logs to
Collector Groups
, typically configured via
Templates
(
Device > Log Settings
) and often using
Log Forwarding Profiles
.
-
Know the process for adding an LC to Panorama (similar to firewalls: point LC to Panorama, add serial in Panorama).
-
Be aware of key prerequisites: Connectivity, Licensing, PAN-OS version compatibility (Panorama >= LC).
-
Understand the importance of disk space monitoring and management for LCs.
-
Recognize that LCs can be upgraded (PAN-OS) via Panorama similar to firewalls.
References (Version 11.0)
These links point to the relevant sections within the official Palo Alto Networks documentation for Panorama version 11.0.