Scribd
Upload
27 views3 pages

Caveats for a Collector Group with Multiple Log Collectors

The document provides guidance on configuring a Collector Group with multiple Log Collectors in Panorama to ensure log redundancy and accommodate high logging rates. It emphasizes the importance of using the same Panorama model for all Log Collectors and recommends having at least three Log Collectors to prevent issues during failures. Additionally, it discusses enabling log redundancy and suggests obtaining an On-Site-Spare for prompt replacements in case of failures.

Uploaded by

bibist
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
27 views3 pages

Caveats for a Collector Group with Multiple Log Collectors

The document provides guidance on configuring a Collector Group with multiple Log Collectors in Panorama to ensure log redundancy and accommodate high logging rates. It emphasizes the importance of using the same Panorama model for all Log Collectors and recommends having at least three Log Collectors to prevent issues during failures. Additionally, it discusses enabling log redundancy and suggests obtaining an On-Site-Spare for prompt replacements in case of failures.

Uploaded by

bibist
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

(/content/techdocs/en_US.

html)

Updated on Mar 13, 2025

Home (/) | Panorama (/content/techdocs/en_US/panorama.html)


| Panorama Administrator's Guide (/content/techdocs/en_US/panorama/10-1/panorama-admin.html)
| Panorama Overview (/content/techdocs/en_US/panorama/10-1/panorama-admin/panorama-overview.html)
| Centralized Logging and Reporting (/content/techdocs/en_US/panorama/10-1/panorama-admin/panorama-overview/centralized-logging-
and-reporting.html)
| Caveats for a Collector Group with Multiple Log Collectors (/content/techdocs/en_US/panorama/10-1/panorama-admin/panorama-
overview/centralized-logging-and-reporting/caveats-for-a-collector-group-with-multiple-log-collectors.html)

DOWNLOAD PDF (/CONTENT/DAM/TECHDOCS/EN_US/PDF/PANORAMA/10-1/PANORAMA-ADMIN/PANORAMA-


ADMIN.PDF)

Panorama Administrator's Guide


(/content/techdocs/en_US/panorama/10-
1/panorama-admin.html)
Caveats for a Collector Group with Multiple Log Collectors

Table of Contents

You can Configure a Collector Group (/content/techdocs/en_US/panorama/10-1/panorama-admin/manage-log-


collection/manage-collector-groups/configure-a-collector-group.html#ide673d91e-8a6f-439a-a269-6536c092b28e) 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 (/content/techdocs/en_US/panorama/10-
1/panorama-admin/panorama-overview/panorama-models.html#id6a2d6388-f727-45aa-ae7e-ef7599379871) 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 (/content/techdocs/en_US/panorama/10-1/panorama-admin/panorama-overview/panorama-
models.html#id6a2d6388-f727-45aa-ae7e-ef7599379871)) 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
This site uses cookies essential to its operation, for analytics, and for personalized content and ads. By
continuing to browse this site, you acknowledge the use of cookies. Privacy statement ❯ Cookie Settings
(https://www.paloaltonetworks.com/legal-notices/privacy)
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.

FIGURE: Example - Typical Log Collector Group Setup

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 (https://docs.paloaltonetworks.com/hardware.html)). 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 be-
havior (https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-release-notes/pan-os-10-0-release-

 information/changes-to-default-behavior.html) for more information.

( PAN-OS 10.1.14 and later 10.1 releases ) Two Log Collectors in a Collector Group are supported and the
Collector Group remains operational even if one Log Collector goes down.

FIGURE: Example - When a Log Collector Fails

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 (/content/techdocs/en_US/panorama/10-1/panorama-


admin/manage-log-collection/manage-collector-groups/configure-a-collector-group.html#ide673d91e-8a6f-439a-a269-
6536c092b28e). 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
This site uses cookies essentialGroup runs out for
to its operation, of analytics,
space, it and
deletes older logs. content and ads. By
for personalized


continuing to browse this site, you acknowledge the use of cookies. Privacy statement ❯
Enabling redundancy doubles the log processing traffic in a Collector Group, which reduces its maximum
(https://www.paloaltonetworks.com/legal-notices/privacy)
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


(https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/monitoring/use-external-services-for-monitoring) as
backup storage. The external service can be a syslog server, email server, SNMP trap server, or HTTP server.
Was this information helpful?

Yes No

Previous (/content/techdocs/en_US/panorama/10- Next (/content/techdocs/en_US/panorama/10-


Local and 1/panorama-admin/panorama-
Log 1/panorama-admin/panorama-
Distributed overview/centralized-logging-and-
Forwarding overview/centralized-logging-and-
Log reporting/local-and-distributed-log-
Options reporting/log-forwarding-options.html)
Collection collection.html)

Technical Documentation Co

Release Notes (/content/techdocs/en_US/release-notes.html) Abo


Search (/content/techdocs/en_US/search.html) Care
Blog (https://www.paloaltonetworks.com/blog/category/technical- Cus
documentation/) LIVE
Compatibility Matrix (/content/techdocs/en_US/compatibility- Kno
matrix.html)
OSS Listings (/content/techdocs/en_US/oss-listings.html)
Sitemap (/content/techdocs/en_US/sitemap.html)

(https://www.facebook.com/PaloAltoNetworks) (https://w
(https://www.youtube.com/channel/UCPRouchFt58TZnjoI65aelA)

(/content/techdocs/en_US.html) © 2025 Palo Alto Ne

This site uses cookies essential to its operation, for analytics, and for personalized content and ads. By
continuing to browse this site, you acknowledge the use of cookies. Privacy statement ❯
(https://www.paloaltonetworks.com/legal-notices/privacy)

You might also like