如何解决日志收集器之间的连接问题
4294
Created On 05/11/23 05:46 AM - Last Modified 12/27/24 06:28 AM
Objective
- 排除故障并解决与 Panorama 和日志收集器连接和同步相关的问题。
- 通过遵循说明,用户应该能够诊断和纠正 Panorama 和 Log Collector 设置中的常见问题。
- 所讨论的一些问题是在设置中通常会看到的。
-
- 防火墙日志不会发送到 Panorama/Log Collector。
- 日志收集器已与 Panorama 断开连接。
- 启动查询时某些日志丢失或延迟。
Environment
- 任意全景图
- 日志收集器
- PAN-OS 10.0 及以上。
Procedure
- 验证全景图(Panorama 模式和/或日志收集器模式)是否已具有进行通信的适当权限。
- 使用全景连接故障排除。
- 如果中间有防火墙,请确保设备之间的TCP端口 28270 是打开的。
- 如果使用 PAN-OS 11.1 或更高版本,请确保端口 28 和端口 9300-9302 已打开。LC 间通信使用这些端口。
- 检查设备之间是否存在任何不稳定的连接,执行下面的命令几次,查看是否有频繁的断开/重新连接。
> show netstat numeric yes | match 28270
Proto Recv-Q Send-Q Local Address Foreign Address State
- 如果全景图/日志收集器之间的工作通信停止工作:
- 使用命令> less mp-log ms.log检查 ms.log 以查看错误消息
01:20:06.757 -0700 COMM: connection established. sock=29 remote ip=10.253.0.106 port=3978 local port=60640
01:20:06.757 -0700 cms agent: Pre. send buffer limit=46080. s=29
01:20:06.757 -0700 cms agent: Post. send buffer limit=425984. s=29
01:20:06.757 -0700 Error: cs_load_certs_ex(cs_common.c:655): keyfile not exists
01:20:06.757 -0700 Error: pan_cmsa_tcp_channel_setup(src_panos/cms_agent.c:883): cms agent: cs_load_certs_ex failed
01:20:06.757 -0700 cmsa: client will use default context
01:20:06.757 -0700 Warning: pan_cmsa_tcp_channel_setup(src_panos/cms_agent.c:988): client will not use SNI
09:13:27.723 -0800 Error: sc3_ca_exists(sc3_certs.c:221): SC3: Failed to get the current CA name.
09:13:27.723 -0800 Warning: sc3_init_sc3(sc3_utils.c:351): SC3: Failed to get the Current CC name
- 在专用日志收集器上,可以通过重置连接来解决 ms.log 中看到的 sc3 问题。请参阅如何重置防火墙和全景之间的安全通信。
- 请勿在管理防火墙的 Panorama 上或在混合模式下运行 sc3 reset 命令。请咨询支持人员以获取解决方案。运行该命令将导致所有防火墙与 Panorama 断开连接。
- 收集器组中是否有任何设备进行了升级?如果是,请确保收集器组内的所有设备都运行相同的版本。
- 重新启动两台设备上的管理服务器以重置连接。
debug software restart process management-server
- 从 Panorama 的角度验证日志收集器是否全部正常,包括 Panorama 本地的日志收集器。
- 从 Panorama 的 GUI: Panorama > 管理 > 收集器
- 根据发现的问题,请相应地使用以下 KB。
- 验证日志收集器的 ElasticSearch 是否健康,包括 Panorama 本地的日志收集器。
- 以下是不健康的 ElasticSearch 的示例。
admin@Log_Collector> debug elasticsearch es-state option health
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1683877500 07:45:00 __pan_cluster__ red 1 1 461 461 0 0 115 0 - 80.03472222222221
- 使用以下命令重新启动 ElasticSearch 并重新检查运行状况。请注意,如果配置了多个日志收集器,则需要确定出现问题的日志收集器,然后在出现故障的日志收集器上重新启动 elasticsearch。如果需要帮助,请联系支持。
admin@Log_Collector> debug elasticsearch es-restart option all
Elasticsearch was restarted with option all by user admin
- 下面是一个健康的 ElasticSearch 的示例。
admin@Log_Collector> debug elasticsearch es-state option health
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1683877131 07:38:51 __pan_cluster__ green 1 1 32 32 0 0 0 0 - 100.0%
- 如果日志丢失或延迟,请参阅日志转发延迟或由于收集器组中的日志收集器之间的延迟过高而导致的日志丢失。