如何设计和大小 Panorama 日志收集器环境

Panorama解决方案由两个整体功能组成：
 

1. 配置和设备管理： 这包括配置管理和部署、帕洛阿尔托网络防火墙的部署、软件升级和内容更新等活动。

2. 日志集合： 这包括从一个或多个防火墙收集日志，无论是单个 Panorama 防火墙还是分布式日志收集基数。 除了从已部署的防火墙收集日志外，还可以根据该日志数据生成报告，无论该日志数据是否位于 Panorama M- VM 分布式记录基数上的本地（例如单个系列或设备）。

该 Panorama 解决方案通过将这些功能分配给管理基础设施的不同物理部分，从而在设计上具有灵活性。 例如：设备管理可以从 a 执行 VM Panorama ，而防火墙将日志转发给配置的专用日志收集器：

 

在上面的示例中，设备管理功能和报告在设备上执行 VM Panorama 。 有三个日志收集器组。 组 A ，包含两个日志收集器，并接收来自三个独立防火墙的日志。 组 B ，由一个单一的收集器组成，并在主动/被动的高可用性 （） 配置中接收来自一对防火墙的日志 HA 。 组 C 还包含两个日志收集器，并接收来自两 HA 对防火墙的日志。 日志收集器在任何给定的位置数是取决于若干因素。 设计注意事项涵盖以下方面。 注意：任何平台都可以是仅管理平台，也可以充当包括和系列在内的记录器 VM M- 。

• Panorama支持日志收集功能的任何物理或虚拟功能。
• PAN-OS 8.1及以上

日志收集

管理设备

虽然所有当前 Panorama 平台的上限为 5000 台用于管理目的的设备（使用单个或 M-600 自 9.0 的 5000 个防火墙 PAN-OS ），但 Panorama 对于大小来说，了解所有托管设备的传入日志速率很重要。 首先，对 firewall 将要管理的总设备进行清点 Panorama 。
 
以以下表为例，对需要转发日志的设备进行清点：

有关如何确定日志速率的以下文章：如何确定 Panorama 具有日志收集器记录要求的设备上的日志速率



本节将涵盖正确大小和部署

Panorama 记录基础设施以支持客户需求所需的信息。 确定所需的总存储量以及如何分配存储通过分布式日志收集器时，有三个主要因素。 这些因素是：

1. 登录摄入要求： 这是每秒发送到基础设施的日志总数 Panorama 。

2. 日志存储要求： 这是客户需要在管理平台上保留日志的时间范围。 有不同的驱动因素，包括 policy 基于和监管的合规激励因素。

3. 设备位置： 防火墙的物理位置可以驱动 DLC 基于 WAN 带宽等在远程位置放置电器的决定。

以下各部分讨论了上述每个因素：

日志摄入要求

管理设备的聚合日志转发速率需要了解，以避免设计中定期发送的日志 Panorama 数量超过其接收、处理和写入磁盘的数量。  下表概述了每个 hardware 平台在 Panorama 设计解决方案以计算可转发到客户环境中的最大日志数量时每秒可转发到并可用于的最大日志数 Panorama 。

设备日志转发限制

登录率 Panorama 受使用的平台和模式（混合模式与记录器模式）的影响。 下表显示了 Panorama 不同可用平台和操作模式的摄入率。 括号中的数字旁边 VM 表示 RAM 分配给 VM 。


Panorama 支持日志摄入率

上述数字是所有的最大价值。 在现场部署中，实际的日志率通常是最的一些分数大支持。 确定实际的日志率是严重依赖于客户的流量混合和不一定绑在吞吐量。 例如，单个卸载 SMB 会话将显示高吞吐量，但仅生成一个流量日志。 相反，您可以有一个较小的吞吐量，由数千个查询组成 UDP DNS ，每个查询都会生成单独的流量日志。 对于大小，每秒连接和每秒日志之间可以得出粗略的相关性。

*在 Panorama 虚拟机上，可以通过更多的资源配置实现额外的功能。 有关更多信息，请参阅 Panorama 虚拟设备设置先决条件 。

确定日志速率新

客户的方法：

• 利用现有客户来源的信息。 许多客户都有第三方日志记录解决方案，如斯普伦克、ArcSight、Qradar 等。 从其现有解决方案发送的日志数量 firewall 可以从这些系统中提取。 使用此方法时，从第三方解决方案获取一整天的日志计数，并除以 86，400（一天的秒数）。 做这几天平均获得了。 请务必同时包括业务和非工作日，因为两者之间的日志速率通常差异很大。

• 使用评估设备中的数据。 此信息可以为分级目的提供非常有用的起点，和来自客户的意见，数据可以推广到其他网站中的相同的设计。 此方法的优点是几天平均生成。 A 本文档中附有用于协助计算此信息的脚本（附有说明）。 要使用，请从"设计日志收集器文档"下载名为"ts_lps.zip"的文件.rar。 拆开拉链文件并引用 README .txt以获得说明。

• 如果没有可用的信息，请使用上面的设备日志转发表作为参考点。 这将是任何特定客户的最准确方法。

现有客户：

对于现有客户，我们可以利用从现有防火墙和日志收集器收集的数据：

• 要检查单个文件的日志速率 firewall ，请从 设计日志收集器文档下载名为"设备.zip"的文件.rar拆开 zip 文件并引用 README .txt文件以获得说明。 此包将在 firewall 指定时间段内查询单个（您可以选择多少个样本），并给出该期间每秒的平均日志数。 至少这个脚本应该在一个工作日连续运行24小时。 运行脚本整整一周将有助于捕获网络的周期性衰退和流动。 如果客户没有日志收集器，则此过程将需要与环境中的每个收款器对接 firewall 。

• 如果客户有日志收集器（或日志收集器），从 设计日志收集器文档下载名为"lc_lps.zip"的文件.rar，拆开 zip 文件并引用 README .txt文件进行说明此包将查询日志收集器 MIB ，以在指定时间段内对传入日志速率进行取样。

日志存储要求
 

因素影响日志存储要求

：有几个因素驱动日志存储要求。 大多数的这些要求是规管性质。 客户可能需要满足 HIPAA PCI 萨班斯-奥克斯利的合规要求。

• PCI DSS 要求10.7
• 萨班斯-奥克斯利法案, 802 节
• HIPAA -= 164.316 （b） 2）

有可能需要考虑的其他政府和行业标准。 此外，一些公司有内部要求。 例如： 一定数量的天价值的日志被保持在原来的管理平台上。 确保所有这些要求得到解决的客户设计日志存储解决方案时。
 
关注需要存储的日志的最小天数。 如果需要 最多 天数（由于法规或 policy ），则可以设置最大天数以保留配额配置中的日志。
 

计算所需存储：

根据给定客户的要求计算所需的存储空间是一个相当简单的过程，但在达到更高的精度时，可能会耗费大量人力。 PAN-OS9.1，所有日志类型的平均大小为 489 字节*。 此数字占存储在磁盘上的总日志大小。 
 
* 平均日志大小可能因流量/记录组合和启用的功能而异。

请注意，我们可能不是长期存档的伐木解决方案。 在这些情况下，建议系统日志转发存档。 

确定特定日志类型的存储要求的方程：

示例： 客户希望能够保持 30 天的交通日志日志率为每秒 1500年日志：

上述计算的结果仅计算 ElasticSearch 详细日志。 使用默认配额设置可为详细日志预留60% 的可用存储空间。 这意味着计算的数字表示弹性搜索使用的存储的 60%。 要计算 ElasticSearch 所需的总存储量，请将这个数字除以 0.60：

三分之一（+33%）可用磁盘空间分配给已记录格式化的日志。 存储已记录格式化的日志以支持升级、降级和支持修复数据库损坏。 要计算需要购买的总存储， 将弹性搜索所需的存储除以 。66：

默认日志配额为 Panorama 8.0 及以后：

日志类型% 存储
详细信息 Firewall 日志 60
摘要 Firewall 日志 30
基础设施和审核日志 5
Palo Alto 网络平台日志 。1
第三方外部日志 。1

请参阅以下文章了解有关空间分配的更多信息 Panorama ：

磁盘空间如何分配在日志收集器上

， 所附工作表将考虑默认配额 Panorama ，并提供所需的存储总量。



日志可用性

使用日志收集器基建（专用或混合模式）时，有两种方法可以实现日志冗余。
 

日志冗余

PAN-OS ：8.1，然后包含一个明确的选项，将每个日志写入日志收集器组中的2个日志收集器。 通过启用此选项，设备将其日志发送到其主日志收集器，然后将日志复制到同一组中的另一个收集器：




日志复制确保日志收集器组中有任何给定日志的两个副本。 这是一个不错的选择，为那些需要在任何时候都保证日志可用性的客户。 要考虑的事项：

1. 复制只发生在日志收集器组内。

2. 总体可用的存储空间被减半 （因为每个日志写的两倍）。

3. 整体日志摄食率将减少达 50%。

4. 延迟应该是 <10ms between the multiple LCs within the same collector group  to avoid an Inter- LC 问题。

 
  
收集器组首选项列表：

方法是将多个日志收集器放入一个组中。 在此情景中， firewall 可以使用首选项列表进行配置，因此，如果主日志收集器出现下落，列表中的第二个收集器将接收并存储日志。

将日志转发给日志收集器的最佳做法是拥有日志收集器首选项列表。 

欲了解更多信息，请参阅 具有多个日志收集器的收藏家组的警告。

在下面显示的架构中 Firewall A ，&a0 Firewall B 被配置为主要将其日志发送到日志收集器1，以日志收集器2作为备份。 如果日志收集器 1 无法访问，设备将将其日志发送到日志收集器 2。






日志收集器组设计的考虑
在
组中配置日志收集器有三个主要原因：
  

1. 与 firewall 单个日志收集器（缩放保留）相比，特定（或一组防火墙）需要更大的日志保留。

2. 特定的摄入能力 firewall 比单个日志收集器（以缩放摄入量）所能提供的要大。

3. 日志冗余要求。

 

在考虑使用日志收集器组时，在设计阶段需要考虑几个注意事项：
 

1. 跨可用收集器展开引入：可以创建多个设备转发首选项列表。 这允许收集器组中的多个收集程序处理摄取。 例如, 首选项列表1将有一半的防火墙和列表收集器1作为主目录和收集器2作为辅助。 首选项列表2将使其余的防火墙和列表收集器2作为主目录和收集器1作为辅助。

2. 延迟问题: 日志收集器组中的收集程序之间的网络延迟是性能的一个重要因素。 A 一般设计准则是让同一组成员的所有收藏家紧密团结在一起。 下表提供了在启用和禁用冗余时的不同延迟测量时可以预期什么。 在这种情况下，"日志延迟"是高延迟的不理想结果 - 日志不会出现在 UI ，直到他们发送到 Panorama 。

NOTE：延迟应该是 <10ms between the multiple LCs within the same collector group  to avoid an Inter- LC 问题。 


 
使用大小工作表：

您需要的信息包括所需的保留期和平均日志速率。



保留期： 需要保留日志的天数。

平均日志速率： 已测量或估计的总日志速率。

需要冗余： 如果需要日志冗余，请检查此框。

详细日志的存储： 满足详细日志的保留期所需的存储量（千兆字节）。

所需总存储： 要购买的存储（千兆字节）。 这用于默认配额设置中的所有日志类型。



EXAMPLE USE CASES









 

• 如果您有任何其他问题或需要有关日志记录环境设计和部署的帮助，请与客户团队联系。

• 上述文档被压缩并附加到本文作为设计日志收集器文档，可供下载。

• 有关如何验证防火墙上的首选项列表配置，请参阅以下文 NGFW 档。 验证日志转发到 Panorama

• 请参阅以下有关如何配置日志转发的文档