Caveats for a Collector Group with Multiple Log Collectors
Table of Contents
Expand all | Collapse all
-
- Determine Panorama Log Storage Requirements
-
- Setup Prerequisites for the Panorama Virtual Appliance
- Perform Initial Configuration of the Panorama Virtual Appliance
- Set Up The Panorama Virtual Appliance as a Log Collector
- Set Up the Panorama Virtual Appliance with Local Log Collector
- Set up a Panorama Virtual Appliance in Panorama Mode
- Set up a Panorama Virtual Appliance in Management Only Mode
-
- Preserve Existing Logs When Adding Storage on Panorama Virtual Appliance in Legacy Mode
- Add a Virtual Disk to Panorama on an ESXi Server
- Add a Virtual Disk to Panorama on vCloud Air
- Add a Virtual Disk to Panorama on Alibaba Cloud
- Add a Virtual Disk to Panorama on AWS
- Add a Virtual Disk to Panorama on Azure
- Add a Virtual Disk to Panorama on Google Cloud Platform
- Add a Virtual Disk to Panorama on KVM
- Add a Virtual Disk to Panorama on Hyper-V
- Add a Virtual Disk to Panorama on Oracle Cloud Infrastructure (OCI)
- Mount the Panorama ESXi Server to an NFS Datastore
-
- Increase CPUs and Memory for Panorama on an ESXi Server
- Increase CPUs and Memory for Panorama on vCloud Air
- Increase CPUs and Memory for Panorama on Alibaba Cloud
- Increase CPUs and Memory for Panorama on AWS
- Increase CPUs and Memory for Panorama on Azure
- Increase CPUs and Memory for Panorama on Google Cloud Platform
- Increase CPUs and Memory for Panorama on KVM
- Increase CPUs and Memory for Panorama on Hyper-V
- Increase the CPUs and Memory for Panorama on Oracle Cloud Infrastructure (OCI)
- Complete the Panorama Virtual Appliance Setup
-
- Convert Your Evaluation Panorama to a Production Panorama with Local Log Collector
- Convert Your Evaluation Panorama to a Production Panorama without Local Log Collector
- Convert Your Evaluation Panorama to VM-Flex Licensing with Local Log Collector
- Convert Your Evaluation Panorama to VM-Flex Licensing without Local Log Collector
- Convert Your Production Panorama to an ELA Panorama
-
- Register Panorama
- Activate a Panorama Support License
- Activate/Retrieve a Firewall Management License when the Panorama Virtual Appliance is Internet-connected
- Activate/Retrieve a Firewall Management License when the Panorama Virtual Appliance is not Internet-connected
- Activate/Retrieve a Firewall Management License on the M-Series Appliance
- Install the Panorama Device Certificate
- Install the Device Certificate for a Dedicated Log Collector
-
- Migrate from a Panorama Virtual Appliance to an M-Series Appliance
- Migrate a Panorama Virtual Appliance to a Different Hypervisor
- Migrate from an M-Series Appliance to a Panorama Virtual Appliance
- Migrate from an M-100 Appliance to an M-500 Appliance
- Migrate from an M-100 or M-500 Appliance to an M-200 or M-600 Appliance
-
- Configure an Admin Role Profile
- Configure an Access Domain
-
- Configure a Panorama Administrator Account
- Configure Local or External Authentication for Panorama Administrators
- Configure a Panorama Administrator with Certificate-Based Authentication for the Web Interface
- Configure an Administrator with SSH Key-Based Authentication for the CLI
- Configure RADIUS Authentication for Panorama Administrators
- Configure TACACS+ Authentication for Panorama Administrators
- Configure SAML Authentication for Panorama Administrators
- Configure Tracking of Administrator Activity
-
- Add a Firewall as a Managed Device
-
- Add a Device Group
- Create a Device Group Hierarchy
- Create Objects for Use in Shared or Device Group Policy
- Revert to Inherited Object Values
- Manage Unused Shared Objects
- Manage Precedence of Inherited Objects
- Move or Clone a Policy Rule or Object to a Different Device Group
- Push a Policy Rule to a Subset of Firewalls
- Device Group Push to a Multi-VSYS Firewall
- Manage the Rule Hierarchy
- Manage the Master Key from Panorama
- Schedule a Configuration Push to Managed Firewalls
- Redistribute Data to Managed Firewalls
-
- Plan the Transition to Panorama Management
- Migrate a Firewall to Panorama Management and Reuse Existing Configuration
- Migrate a Firewall to Panorama Management and Push a New Configuration
- Migrate a Firewall HA Pair to Panorama Management and Reuse Existing Configuration
- Migrate a Firewall HA Pair to Panorama Management and Push a New Configuration
- Load a Partial Firewall Configuration into Panorama
- Localize a Panorama Pushed Configuration on a Managed Firewall
-
- Configure a Managed Collector
- Configure Log Forwarding to Panorama
- Configure Syslog Forwarding to External Destinations
- Forward Logs to Strata Logging Service
- Verify Log Forwarding to Panorama
- Modify Log Forwarding and Buffering Defaults
- Configure Log Forwarding from Panorama to External Destinations
-
- Add Standalone WildFire Appliances to Manage with Panorama
- Remove a WildFire Appliance from Panorama Management
-
-
- Configure a Cluster and Add Nodes on Panorama
- Configure General Cluster Settings on Panorama
- Remove a Cluster from Panorama Management
- Configure Appliance-to-Appliance Encryption Using Predefined Certificates Centrally on Panorama
- Configure Appliance-to-Appliance Encryption Using Custom Certificates Centrally on Panorama
- View WildFire Cluster Status Using Panorama
-
-
- Preview, Validate, or Commit Configuration Changes
- Enable Automated Commit Recovery
- Compare Changes in Panorama Configurations
- Manage Locks for Restricting Configuration Changes
- Add Custom Logos to Panorama
- Use the Panorama Task Manager
- Reboot or Shut Down Panorama
- Configure Panorama Password Profiles and Complexity
-
-
- Verify Panorama Port Usage
- Resolve Zero Log Storage for a Collector Group
- Replace a Failed Disk on an M-Series Appliance
- Replace the Virtual Disk on an ESXi Server
- Replace the Virtual Disk on vCloud Air
- Migrate Logs to a New M-Series Appliance in Log Collector Mode
- Migrate Logs to a New M-Series Appliance in Panorama Mode
- Migrate Logs to a New M-Series Appliance Model in Panorama Mode in High Availability
- Migrate Logs to the Same M-Series Appliance Model in Panorama Mode in High Availability
- Migrate Log Collectors after Failure/RMA of Non-HA Panorama
- Regenerate Metadata for M-Series Appliance RAID Pairs
- View Log Query Jobs
- Troubleshoot Registration or Serial Number Errors
- Troubleshoot Reporting Errors
- Troubleshoot Device Management License Errors
- Troubleshoot Automatically Reverted Firewall Configurations
- View Task Success or Failure Status
- Generate a Stats Dump File for a Managed Firewall
- Recover Managed Device Connectivity to Panorama
- Restore an Expired Device Certificate
Caveats for a Collector Group with Multiple Log Collectors
You can Configure
a Collector Group with multiple Log Collectors (up to 16)
to ensure log redundancy, increase the log retention period, and
accommodate logging rates that exceed the capacity of a single Log
Collector (see Panorama
Models for capacity information). In any single Collector
Group, all the Log Collectors must run on the same Panorama model:
all M-600 appliances, all M-500 appliances, all, M-200 appliances
all, or all Panorama virtual appliances. For example, if a single
managed firewall generates 48TB of logs, the Collector Group that
receives those logs will require at least six Log Collectors that
are M-200 appliances or two Log Collectors that are M-500 appliances
or Panorama virtual appliances.
A Collector Group with multiple Log Collectors uses the available
storage space as one logical unit and uniformly distributes the
logs across all its Log Collectors. The log distribution is based
on the disk capacity of the Log Collectors (see Panorama
Models) and a hash algorithm that dynamically decides which
Log Collector owns the logs and writes to disk. Although Panorama
uses a preference list to prioritize the list of Log Collectors
to which a managed firewall can forward logs, Panorama does not
necessarily write the logs to the first Log Collector specified
in the preference list. For example, consider the following preference
list:
Managed Firewall | Log Forwarding Preference
List Defined in a Collector Group |
---|---|
FW1 | L1,L2,L3 |
FW2 | L4,L5,L6 |
Using this list, FW1 will forward logs to L1 so long as that
primary Log Collector is available. However, based on the hash algorithm,
Panorama might choose L2 as the owner that writes the logs to its
disks. If L2 becomes inaccessible or has a chassis failure, FW1
will not know because it can still connect to L1.
Example - Typical Log Collector Group Setup
![](/content/dam/techdocs/en_US/dita/_graphics/10-1/panorama/CollectorGroup.png)
In the case where a Collector Group has only one Log Collector
and the Log Collector fails, the firewall stores the logs to its
HDD/SSD (the available storage space varies by firewall model). As soon
as connectivity is restored to the Log Collector, the firewall resumes
forwarding logs where it left off before the failure occurred.
In the case of a Collector Group with multiple Log Collectors,
the firewall does not buffer logs to its local storage if only one
Log Collector is down. In the example scenario where L2 is down,
FW1 continues sending logs to L1, and L1 stores the log data that
would be sent to L2. Once L2 is back up, L1 no longer stores log
data intended for L2 and distribution resumes as expected. If one
of the Log Collectors in a Collector Group goes down, the logs that
would be written to the down Log Collector are redistributed to
the next Log Collector in the preference list.
Palo Alto Networks recommends adding
at least three Log Collectors to a Collector Group to avoid split
brain and log ingestion issues should one Log Collector go down.
See the changes to default Collector
Group behavior for more information.
Two Log Collectors
in a Collector Group is supported but the Collector Group becomes
non-operational if one Log Collector goes down.
Example - When a Log Collector Fails
![](/content/dam/techdocs/en_US/dita/_graphics/10-1/panorama/CollectorGroup_Failed.png)
Palo Alto Networks recommends the following mitigations if using
multiple Log Collectors in a Collector Group:
- Enable log redundancy when you Configure a Collector Group. This ensures that no logs are lost if any one Log Collector in the Collector Group becomes unavailable. Each log will have two copies and each copy will reside on a different Log Collector. Log redundancy is available only if each Log Collector has the same number of logging disks.Because enabling redundancy creates more logs, this configuration requires more storage capacity. When a Collector Group runs out of space, it deletes older logs.Enabling redundancy doubles the log processing traffic in a Collector Group, which reduces its maximum logging rate by half, as each Log Collector must distribute a copy of each log it receives.
- Obtain an On-Site-Spare (OSS) to enable prompt replacement if a Log Collector failure occurs.
- In addition to forwarding logs to Panorama, configure forwarding to an external service as backup storage. The external service can be a syslog server, email server, SNMP trap server, or HTTP server.