topic Re: Log Collector Redundancy in Panorama Discussions

Log Collector Redundancy

mb_nexon — Mon, 23 Feb 2026 05:29:54 GMT

I have a client with a Panorama HA Pair that spans facilities via DWDM. It's fast enough (sub 10ms) to run an LCG that spans both DCs, but this is still poor design as it effectively halves the MTBF (you're now dependent on both members of a 2-node cluster to be operational thanks to the Elasticsearch quorum).

So we run 2 independent LCGs to improve overall availability of each LC, which also minimises log traffic over the DCI by including only the local devices in each LCG's preference list.

The only challenge with this approach, or any Panorama HA pair for that matter, is that there is no redundancy in the log collection layer without introducing 2 additional collectors at each site (since we don't want an LCG to span facilities). If a Panorama instance fails, the devices logging to that instance buffer until it's available.

Is there a way to achieve redundant log collection in a Panorama HA pair without increasing the deployment footprint?

Re: Log Collector Redundancy

reaper — Thu, 26 Feb 2026 12:17:36 GMT

the short answer, no: you need 3 collectors to form a LCG

you could consider Strata Logging Service, which would take away the redundancy concerns

Re: Log Collector Redundancy

mb_nexon — Thu, 26 Feb 2026 23:02:32 GMT

Thanks for confirming Tom, I had figured that. It's an air-gapped network and the devices will log in parallel to a local SIEM, so 2x 1 member LCGs is still acceptable. In this case the SIEM provides the redundancy and retention required for compliance.

Appreciate your help.

Re: Log Collector Redundancy

reaper — Wed, 04 Mar 2026 12:25:13 GMT

gotcha, yea there's no real middle ground in your case...

You can put in a featuire request for a hybrid LCG with 2x1 primary and 1 dual secondary... 🙂