排出FMC未處理事件和頻繁排出事件運行狀況監視器警報故障排除
簡介
本文檔介紹如何對Firepower管理中心上未處理事件的消耗和頻繁發生的事件消耗運行狀況警報進行故障排除。
問題概述
Firepower管理中心(FMC)生成以下運行狀況警報之一：
- 頻繁地清空統一低優先順序事件
- 從統一低優先順序事件中排出未處理的事件
儘管這些事件在FMC中生成並顯示，但它們與受管裝置感測器相關，無論是Firepower威脅防禦(FTD)裝置還是下一代入侵防禦系統(NGIPS)裝置。在本文檔的其餘部分，術語「感測器」同時指FTD和NGIPS裝置，除非另有說明。
這是健康警示結構：
- 頻繁清空<SILO NAME>
- 從<SILO NAME>中清空未處理的事件
在本示例中，思洛儲存器名稱為「統一低優先順序事件」。這是磁碟管理器孤島之一（有關更全面的說明，請參見「背景資訊」部分）。
此外：
- 儘管從技術上講，任何思洛儲存器都可以頻繁地生成<思洛儲存器名稱>健康警報的清空，但最常見的是與事件相關的事件，其中低優先順序事件只是因為這些是感測器更頻繁生成的事件型別。
- 如果<SILO NAME>事件是事件相關的思洛儲存器，則頻繁的清空事件具有「警告」嚴重性，因為如果處理了此事件（下面提供了有關未處理事件的組成部分的說明），則這些事件在FMC資料庫中。
- 對於非事件相關的思洛儲存器（如備份思洛儲存器），警報是嚴重的，因為此資訊已丟失。
- 只有事件型別孤島會從<SILO NAME>運行狀況警報中生成未處理事件的清空。此警報始終具有「嚴重」嚴重性。
其他症狀可能包括：
- FMC UI緩慢
- 事件丟失
常見故障排除場景
頻繁的清空<SILO NAME>事件是由於對思洛儲存器大小輸入過多造成的。在這種情況下，磁碟管理器將在最後5分鐘間隔內至少兩次清空（清除）該檔案。在事件型別思洛儲存器中，這通常是由該事件型別的過度記錄引起的。如果<SILO NAME>運行狀況警報的未處理事件已耗盡，則這也可能由事件處理路徑中的瓶頸導致。
圖中存在3個潛在的瓶頸：
- FTD上的EventHandler處理序已超額訂閱（其讀取速度比Snort寫入的速度慢）。
- 事件介面已超額訂閱。
- FMC上的SFDataCorrelator進程超訂用。
案例 1.過多的記錄
如上一節所述，導致此類運行狀況警報的最常見原因之一是輸入過多。
透過show disk-manager CLISH命令收集到的低水位標籤(LWM)與高水位標籤(HWM)之間的區別顯示了接收思洛儲存器需要多少空間才能從LWM（新瀝乾）變為HWM值。如果事件頻繁流失（無論有無未處理的事件），您必須首先檢視日誌記錄配置。
無論是雙日誌記錄還是整個manager-sensors生態系統中的事件率很高，都必須檢查日誌記錄設定。
建議的動作
步驟 1.檢查雙重記錄。
如果您檢視FMC上的相關器效能統計資訊，則可以辨識雙重日誌記錄方案，如以下輸出所示：
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
129 statistics lines read
host limit: 50000 0 50000
pcnt host limit in use: 0.01 0.01 0.01
rna events/second: 0.00 0.00 0.06
user cpu time: 0.48 0.21 10.09
system cpu time: 0.47 0.00 8.83
memory usage: 2547304 0 2547304
resident memory usage: 28201 0 49736
rna flows/second: 126.41 0.00 3844.16
rna dup flows/second: 69.71 0.00 2181.81
ids alerts/second: 0.00 0.00 0.00
ids packets/second: 0.00 0.00 0.00
ids comm records/second: 0.02 0.01 0.03
ids extras/second: 0.00 0.00 0.00
fw_stats/second: 0.00 0.00 0.03
user logins/second: 0.00 0.00 0.00
file events/second: 0.00 0.00 0.00
malware events/second: 0.00 0.00 0.00
fireamp events/second: 0.00 0.00 0.00
在這種情況下，輸出中可看到很高的重複流率。
步驟 2.複查ACP的記錄設定。
您必須從檢閱存取控制原則(ACP)的記錄設定開始。確保使用本文檔連線日誌記錄的最佳實踐中描述的最佳實踐
建議在所有情況下都檢查日誌記錄設定，因為列出的建議不僅包括雙重日誌記錄情況。
若要檢查FTD上產生事件的速率，請檢查此檔案並專注於TotalEvents和PerSec資料欄：
admin@firepower:/ngfw/var/log$ sudo more EventHandlerStats.2023-08-13 | grep Total | more
{"Time": "2023-08-13T00:03:37Z", "TotalEvents": 298, "PerSec": 0, "UserCPUSec": 0.995, "SysCPUSec": 4.598, "%CPU": 1.9, "MemoryKB": 33676}
{"Time": "2023-08-13T00:08:37Z", "TotalEvents": 298, "PerSec": 0, "UserCPUSec": 1.156, "SysCPUSec": 4.280, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:13:37Z", "TotalEvents": 320, "PerSec": 1, "UserCPUSec": 1.238, "SysCPUSec": 4.221, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:18:37Z", "TotalEvents": 312, "PerSec": 1, "UserCPUSec": 1.008, "SysCPUSec": 4.427, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:23:37Z", "TotalEvents": 320, "PerSec": 1, "UserCPUSec": 0.977, "SysCPUSec": 4.465, "%CPU": 1.8, "MemoryKB": 33676}
{"Time": "2023-08-13T00:28:37Z", "TotalEvents": 299, "PerSec": 0, "UserCPUSec": 1.066, "SysCPUSec": 4.361, "%CPU": 1.8, "MemoryKB": 33676}
步驟 3. 檢查是否應該進行過度記錄。
您必須檢閱過多的記錄是否有預期的原因。如果DOS/DDoS攻擊、路由環路或建立大量連線的特定應用程式/主機導致日誌記錄過多，則必須檢查並緩解/停止來自意外過多連線源的連線。
步驟 4. 檢查損壞的diskmanager.log檔案。
通常，一個條目可以有12個逗號分隔值。檢查欄位數不同的損壞行：
admin@firepower:/ngfw/var/log$ sudo cat diskmanager.log | awk -F',' 'NF != 12 {print}'
admin@firepower:/ngfw/var/log$
如果有一行損毀，但欄位數不是12，則顯示。
步驟 5.升級型號。
將FTD硬體裝置升級為效能更高的型號（例如FPR2100 —> FPR4100），思洛儲存器的來源將會增加。
步驟 6.考慮是否可以停用Log to Ramdisk。
對於Unified Low Priority Events思洛儲存器，您可以停用Log to Ramdisk，以增大思洛儲存器大小，其缺點在相應的深入分析部分中討論。
案例 2.感測器與FMC之間通訊通道的瓶頸
這種型別的警報的另一個常見原因是感測器和FMC之間的通訊通道(sftunnel)存在連線問題和/或不穩定。通訊問題可能是由於：
- sftunnel已關閉或不穩定（抖動）。
- sftunnel超訂用。
對於sftunnel連線問題，請確保FMC和感測器在TCP埠8305上的管理介面之間具有可接通性。
在FTD上，您可以在[/ngfw]/var/log/messages檔案中搜尋sftunneld字串。連線問題會導致生成如下消息：
Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_ch_util [INFO] Delay for heartbeat reply on channel from 10.62.148.75 for 609 seconds. dropChannel... Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_connections [INFO] Ping Event Channel for 10.62.148.75 failed Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState dropChannel peer 10.62.148.75 / channelB / EVENT [ msgSock2 & ssl_context2 ] << Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState freeChannel peer 10.62.148.75 / channelB / DROPPED [ msgSock2 & ssl_context2 ] << Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_connections [INFO] Need to send SW version and Published Services to 10.62.148.75 Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_peers [INFO] Confirm RPC service in CONTROL channel Sep 9 15:41:35 firepower SF-IMS[5458]: [27602] sftunneld:sf_channel [INFO] >> ChannelState do_dataio_for_heartbeat peer 10.62.148.75 / channelA / CONTROL [ msgSock & ssl_context ] << Sep 9 15:41:48 firepower SF-IMS[5458]: [5464] sftunneld:tunnsockets [INFO] Started listening on port 8305 IPv4(10.62.148.180) management0 Sep 9 15:41:51 firepower SF-IMS[5458]: [27602] sftunneld:control_services [INFO] Successfully Send Interfaces info to peer 10.62.148.75 over managemen Sep 9 15:41:53 firepower SF-IMS[5458]: [5465] sftunneld:sf_connections [INFO] Start connection to : 10.62.148.75 (wait 10 seconds is up) Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_peers [INFO] Peer 10.62.148.75 needs the second connection Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Interface management0 is configured for events on this Device Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Connect to 10.62.148.75 on port 8305 - management0 Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Initiate IPv4 connection to 10.62.148.75 (via management0) Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Initiating IPv4 connection to 10.62.148.75:8305/tcp Sep 9 15:41:53 firepower SF-IMS[5458]: [27061] sftunneld:sf_ssl [INFO] Wait to connect to 8305 (IPv6): 10.62.148.75
FMC管理介面的超訂用可能是管理流量激增或持續超訂用。健康監測器的歷史資料是很好的指標。
需要注意的第一件事是，在大多數情況下，FMC使用單個NIC進行部署以進行管理。此介面用於：
- FMC管理
- FMC感測器管理
- 從感測器收集FMC事件
- 更新情報源
- 從軟體下載站點下載SRU、軟體、VDB和GeoDB更新
- 查詢URL信譽和類別（如果適用）
- 檔案處置（如果適用）的查詢
建議的動作
您可以在FMC上為事件專用介面部署第二個NIC。具體實施可能取決於使用案例。
有關一般準則，請參閱FMC硬體指南在管理網路上部署
案例 3.SFDataCorrelator進程的一個瓶頸
最後一個要覆蓋的場景是SFDataCorrelator端(FMC)出現瓶頸的情況。
第一步是檢視diskmanager.log檔案，因為要收集的重要資訊包括：
- 排水管的頻率。
- 已排出未處理事件的檔案數。
-
具有「未處理事件」的清空事件。
有關diskmanager.log檔案及其解釋方法的資訊，請參閱磁碟管理器部分。從diskmanager.log收集的資訊可用於幫助縮小後續步驟的範圍。
此外，您需要檢視相關器效能統計資訊：
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
129 statistics lines read
host limit: 50000 0 50000 pcnt host limit in use: 100.01 100.00 100.55 rna events/second: 1.78 0.00 48.65 user cpu time: 2.14 0.11 58.20 system cpu time: 1.74 0.00 41.13 memory usage: 5010148 0 5138904 resident memory usage: 757165 0 900792 rna flows/second: 101.90 0.00 3388.23 rna dup flows/second: 0.00 0.00 0.00 ids alerts/second: 0.00 0.00 0.00 ids packets/second: 0.00 0.00 0.00 ids comm records/second: 0.02 0.01 0.03 ids extras/second: 0.00 0.00 0.00 fw_stats/second: 0.01 0.00 0.08 user logins/second: 0.00 0.00 0.00 file events/second: 0.00 0.00 0.00 malware events/second: 0.00 0.00 0.00 fireamp events/second: 0.00 0.00 0.01
這些統計資訊用於FMC，並且對應於由其管理的所有感測器的聚合。對於Unified低優先順序事件，您主要查詢：
- 任何事件型別的每秒總流數，用於評估SFDataCorrelator進程可能的超訂用。
- 在先前輸出中反白的兩列：
- rna flows/second -表示SFDataCorrelator處理的低優先順序事件的速率。
- rna dup flows/second -表示SFDataCorrelator處理的重複低優先順序事件的速率。如前一個場景所述，這是透過雙重日誌記錄生成的。
根據輸出可以得出結論：
- 沒有重複記錄，如rna dup flows/second行所示。
- 在rna流/秒行中，「最大值」遠高於「平均值」，因此SFDataCorrelator進程處理的事件率出現峰值。如果在使用者工作日剛開始時看到今天凌晨，這種情況是可以預料的，但總的來說，這是一個危險訊號，需要進一步調查。
有關SFDataCorrelator進程的更多資訊，請參閱事件處理部分。
建議的動作
首先，您需要確定何時發生峰值。為此，您需要檢視每5分鐘取樣間隔的相關器統計資訊。從diskmanager.log中收集的資訊可幫助您直接進入重要的時間範圍。
admin@FMC:~$ sudo perfstats -C < /var/sf/rna/correlator-stats/now
<OUTPUT OMITTED FOR READABILITY>
Wed Sep 9 16:01:35 2020 host limit: 50000 pcnt host limit in use: 100.14 rna events/second: 24.33 user cpu time: 7.34 system cpu time: 5.66 memory usage: 5007832 resident memory usage: 797168 rna flows/second: 638.55 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.02 ids extras/second: 0.00 fw stats/second: 0.00 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:06:39 2020 host limit: 50000 pcnt host limit in use: 100.03 rna events/second: 28.69 user cpu time: 16.04 system cpu time: 11.52 memory usage: 5007832 resident memory usage: 801476 rna flows/second: 685.65 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.01 ids extras/second: 0.00 fw stats/second: 0.00 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:11:42 2020 host limit: 50000 pcnt host limit in use: 100.01 rna events/second: 47.51 user cpu time: 16.33 system cpu time: 12.64 memory usage: 5007832 resident memory usage: 809528 rna flows/second: 1488.17 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.02 ids extras/second: 0.00 fw stats/second: 0.01 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 Wed Sep 9 16:16:42 2020 host limit: 50000 pcnt host limit in use: 100.00 rna events/second: 8.57 user cpu time: 58.20 system cpu time: 41.13 memory usage: 5007832 resident memory usage: 837732 rna flows/second: 3388.23 rna dup flows/second: 0.00 ids alerts/second: 0.00 ids pkts/second: 0.00 ids comm records/second: 0.01 ids extras/second: 0.00 fw stats/second: 0.03 user logins/second: 0.00 file events/second: 0.00 malware events/second: 0.00 fireAMP events/second: 0.00 197 statistics lines read host limit: 50000 0 50000 pcnt host limit in use: 100.01 100.00 100.55 rna events/second: 1.78 0.00 48.65 user cpu time: 2.14 0.11 58.20 system cpu time: 1.74 0.00 41.13 memory usage: 5010148 0 5138904 resident memory usage: 757165 0 900792 rna flows/second: 101.90 0.00 3388.23 rna dup flows/second: 0.00 0.00 0.00 ids alerts/second: 0.00 0.00 0.00 ids packets/second: 0.00 0.00 0.00 ids comm records/second: 0.02 0.01 0.03 ids extras/second: 0.00 0.00 0.00 fw_stats/second: 0.01 0.00 0.08 user logins/second: 0.00 0.00 0.00 file events/second: 0.00 0.00 0.00 malware events/second: 0.00 0.00 0.00 fireamp events/second: 0.00 0.00 0.01
使用輸出中的資訊可以：
- 確定事件的正常/基線速率。
- 確定發生尖峰事件的5分鐘間隔。
在前一個例子中，在16:06:39及以後收到的事件率出現明顯的峰值。這些是5分鐘的平均值，所以增加可能會比顯示的更突然（突發），但是如果增加開始接近尾聲的話，在5分鐘間隔內就會被稀釋。
雖然這可以得出這樣的結論：此事件激增導致未處理事件的流失，但您可以使用適當的時間窗口從FMC圖形使用者介面(GUI)檢視連線事件，以瞭解此激增中穿越FTD框的連線型別：
套用此時間視窗以取得已篩選的連線事件。別忘了說明時區。在本示例中，感測器使用UTC和FMC UTC+1。使用「表格檢視」來檢視觸發事件多載的事件，並相應採取行動：
根據時間戳（第一個和最後一個資料包的時間），可以看到這些連線是短暫的。此外，Initiator和Responder Packets列顯示每個方向只交換1個資料包。這證實這些連線是短暫的，交換的資料很少。
您還可以看到所有這些流都指向相同的響應方IP和埠。此外，它們都由同一感測器報告（與入口和出口介面資訊一起可說明此流量的位置和方向）。其他動作：
- 檢查目標端點上的Syslog。
- 實施DOS/DDOS保護，或採取其他預防措施。
在聯絡思科技術支援中心(TAC)之前要收集的專案
強烈建議您在聯絡思科TAC之前收集以下專案：
- 檢視的運行狀況警報的截圖。
- 排除從FMC生成的檔案故障。
- 對從受影響的感測器生成的檔案進行故障排除。
- 第一次發現問題的日期和時間。
- 有關最近對策略所做的任何更改的資訊（如果適用）。
- stats_unified.pl命令的輸出(如事件處理部分所述)以及受影響的感測器的說明。
深入探討
本節深入說明可以參與此類健康警示的各種元件。這包括：
- 事件處理-涵蓋感測器裝置和FMC上事件採用的路徑。當運行狀況警報引用事件型別思洛儲存器時，這很有用。
- 磁碟管理器-介紹磁碟管理器過程、孤島及其耗盡方式。
- 運行狀況監控器-介紹如何使用運行狀況監控器模組生成運行狀況警報。
- Log to Ramdisk -介紹ramdisk功能的日誌記錄及其對運行狀況警報的潛在影響。
為了瞭解事件漏出運行狀況警報並能夠辨識潛在的故障點，需要研究這些元件如何工作以及如何相互互動。
事件處理
儘管頻繁漏電型別的健康風險通告可能由與事件無關的孤島觸發，但思科TAC發現的絕大多數案例都與事件相關資訊的漏電有關。此外，要瞭解什麼情況會耗盡未處理的事件，需要瞭解事件處理架構以及構成該架構的元件。
當Firepower感測器從新連線接收資料包時，snort進程會以unified2格式生成事件，該格式是一種二進位制格式，允許更快的讀取/寫入以及更輕的事件。
輸出顯示FTD命令system support trace，您可以在其中看到建立的新連線。重點介紹並解釋以下重要部分：
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Packet: TCP, SYN, seq 3310981951
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Session: new snort session
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 AppID: service unknown (0), application unknown (0)
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 new firewall session
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 using HW or preset rule order 4, 'Default Inspection', action Allow and prefilter rule 0
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 HitCount data sent for rule id: 268437505,
192.168.0.2-42310 > 192.168.1.10-80 6 AS 1-1 I 0 allow action
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Firewall: allow rule, 'Default Inspection', allow
192.168.0.2-42310 - 192.168.1.10-80 6 AS 1-1 CID 0 Snort id 0, NAP id 1, IPS id 0, Verdict PASS
Snort unified_events檔案按例項在路徑[/ngfw]var/sf/detection_engine/*/instance-N/下生成，其中：
- *是Snort UUID。每個裝置都是唯一的。
- N是可以作為上一個輸出（示例中突出顯示的0） + 1中的例項ID計算的Snort例項ID
在任何給定的Snort例項資料夾中都可以有2種型別的unified_events檔案：
- unified_events-1（包含高優先順序事件。）
- unified_events-2（包含低優先順序事件。）
高優先順序事件是與潛在惡意連線相對應的事件。
事件型別及其優先順序：
| 高優先順序(1) |
低優先順序(2) |
| 入侵 |
連線 |
| 惡意軟體 |
發現 |
| 安全情報 |
檔案 |
| 關聯的連線事件 |
統計資料 |
下一個輸出顯示屬於上一個示例中跟蹤的新連線的事件。格式為unified2，取自位於[/ngfw]/var/sf/detection_engine/*/instance-1/下的各個統一事件日誌輸出，其中1是上一個輸出+1中以粗體顯示的snort例項id。統一事件日誌格式名稱使用unified_events-2.log.1599654750語法，其中2表示表中顯示的事件優先順序，最後一個粗體(1599654750)部分是建立檔案時的時間戳（Unix時間）。
Unified2 Record at offset 2190389
Type: 210(0x000000d2)
Timestamp: 0
Length: 765 bytes
Forward to DC: Yes
FlowStats:
Sensor ID: 0
Service: 676
NetBIOS Domain: <none>
Client App: 909, Version: 1.20.3 (linux-gnu)
Protocol: TCP
Initiator Port: 42310
Responder Port: 80
First Packet: (1599662092) Tue Sep 9 14:34:52 2020
Last Packet: (1599662092) Tue Sep 9 14:34:52 2020
<OUTPUT OMITTED FOR READABILITY>
Initiator: 192.168.0.2
Responder: 192.168.1.10
Original Client: ::
Policy Revision: 00000000-0000-0000-0000-00005f502a92
Rule ID: 268437505
Tunnel Rule ID: 0
Monitor Rule ID: <none>
Rule Action: 2
每個unified_events檔案旁邊都有一個書籤檔案，其中包含兩個重要值：
- 該例項和優先順序的當前unified_events檔案對應的時間戳。
- Unified_event檔案中最後一個讀取事件的位置（以位元組為單位）。
這些值按逗號分隔的順序排列，如以下示例所示：
root@FTD:/home/admin# cat /var/sf/detection_engines/d5a4d5d0-6ddf-11ea-b364-2ac815c16717/instance-1/unified_events-2.log.bookmark.1a3d52e6-3e09-11ea-838f-68e7af919059
1599862498, 18754115
這樣，磁碟管理器進程就可以知道哪些事件已處理（傳送到FMC），哪些事件尚未處理。
注意：當磁碟管理器耗盡事件思洛儲存器時，它會刪除統一事件檔案。
有關清理孤島的詳細資訊，請參閱磁碟管理器部分。
當以下情況之一為真時，已耗盡的統一檔案將被視為具有未處理的事件：
- 書籤時間戳記低於檔案建立時間。
- 書籤時間戳記與檔案建立時間相同，且檔案中位元組的位置低於其大小。
EventHandler進程從統一檔案讀取事件，並透過sftunnel將其作為metadata流傳輸到FMC，這是負責感測器與FMC之間加密通訊的進程。這是基於TCP的連線，因此事件流由FMC確認
您可以在[/ngfw]/var/log/messages檔案中看到以下消息：
sfpreproc:OutputFile [INFO] *** Opening /ngfw/var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478 for output" in /var/log/messages
EventHandler:SpoolIterator [INFO] Opened unified event file /var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478
sftunneld:FileUtils [INFO] Processed 10334 events from log file var/sf/detection_engines/77d31ce2-c2fc-11ea-b470-d428d53ed3ae/instance-1/unified_events-2.log.1597810478
此輸出提供以下資訊：
- Snort打開了unified_events檔案以便輸出（在其中寫入）。
- 事件處理程式打開了相同的unified_events檔案（以便從中讀取）。
- sftunnel報告從該unified_events檔案處理的事件數。
然後相應地更新書籤檔案。Sftunnel為高優先順序事件和低優先順序事件分別使用2個稱為統一事件(UE)通道0和1的不同通道。
使用FTD上的sfunnel_status CLI指令，您可以看到串流處理的事件數目。
Priority UE Channel 1 service
TOTAL TRANSMITTED MESSAGES <530541> for UE Channel service
RECEIVED MESSAGES <424712> for UE Channel service
SEND MESSAGES <105829> for UE Channel service
FAILED MESSAGES <0> for UE Channel service
HALT REQUEST SEND COUNTER <17332> for UE Channel service
STORED MESSAGES for UE Channel service (service 0/peer 0)
STATE <Process messages> for UE Channel service
REQUESTED FOR REMOTE <Process messages> for UE Channel service
REQUESTED FROM REMOTE <Process messages> for UE Channel service
在FMC中，事件由SFDataCorrelator進程接收。
使用stats_unified.pl命令可以檢視從每個感測器處理的事件的狀態：
admin@FMC:~$ sudo stats_unified.pl
Current Time - Fri Sep 9 23:00:47 UTC 2020
**********************************************************************************
* FTD - 60a0526e-6ddf-11ea-99fa-89a415c16717, version 6.6.0.1
**********************************************************************************
Channel Backlog Statistics (unified_event_backlog)
Chan Last Time Bookmark Time Bytes Behind
0 2020-09-09 23:00:30 2020-09-07 10:41:50 0
1 2020-09-09 23:00:30 2020-09-09 22:14:58 6960
此命令顯示每個通道特定裝置的事件積壓狀態，使用的通道ID與sftunnel相同。
Bytes Behind值可以計算為統一事件書籤檔案中顯示的位置與統一事件檔案大小之間的差值，加上時間戳高於書籤檔案內時間戳的任何後續檔案。
SFDataCorrelator進程還儲存效能統計資訊，這些統計資訊儲存在/var/sf/rna/correlator-stats/中。每天建立一個檔案，以CSV格式儲存該日的效能統計資訊。檔案名稱使用YYYY-MM-DD格式，目前日期對應的檔案現在稱為。
統計資訊每5分鐘收集一次（每5分鐘間隔有一行）。
可使用perfstats命令讀取此檔案的輸出。
注意：此命令還用於讀取snort效能統計資訊檔案，因此必須使用相應的標誌：
-C：指示perfstats輸入為相關器統計檔案（如果沒有此標誌，perfstats假設輸入為snort效能統計檔案）。
-q：安靜模式，只列印檔案的摘要。
admin@FMC:~$ sudo perfstats -Cq < /var/sf/rna/correlator-stats/now
287 statistics lines read
host limit: 50000 0 50000
pcnt host limit in use: 100.01 100.00 100.55
rna events/second: 1.22 0.00 48.65
user cpu time: 1.56 0.11 58.20
system cpu time: 1.31 0.00 41.13
memory usage: 5050384 0 5138904
resident memory usage: 801920 0 901424
rna flows/second: 64.06 0.00 348.15
rna dup flows/second: 0.00 0.00 37.05
ids alerts/second: 1.49 0.00 4.63
ids packets/second: 1.71 0.00 10.10
ids comm records/second: 3.24 0.00 12.63
ids extras/second: 0.01 0.00 0.07
fw_stats/second: 1.78 0.00 5.72
user logins/second: 0.00 0.00 0.00
file events/second: 0.00 0.00 3.25
malware events/second: 0.00 0.00 0.06
fireamp events/second: 0.00 0.00 0.00
摘要中的每一列都有三個依此順序的值：平均、最小值、最大值。
如果列印時沒有-q旗標，您也會看到5分鐘間隔值。總結在末尾顯示。
註：每個FMC在其資料表中都有一個描述的最大流速。下表包含各個資料表中每個模組的值。
| 型號 |
FMC 750 |
FMC 1000 |
FMC 1600 |
FMC 2000 |
FMC 2500 |
FMC 2600 |
FMC 4000 |
FMC 4500 |
FMC 4600 |
FMCv |
FMCv300 |
| 最大流速(fps) |
2000 |
5000 |
5000 |
12000 |
12000 |
12000 |
20000 |
20000 |
20000 |
變數 |
12000 |
注意：這些值用於SFDataCorrelator統計資訊輸出中以粗體顯示的所有事件型別的聚合。
如果您檢視輸出並調整FMC的大小，使您已準備好應對最壞的情況（當所有最大值同時發生時），則此FMC看到的事件速率為48.65 + 348.15 + 4.63 + 3.25 + 0.06 = 404.74 fps。
此總值可以與相應模型資料表中的值進行比較。
SFDataCorrelator還可以對收到的事件進行額外工作（例如關聯規則），然後將它們儲存在資料庫中，然後查詢該資料庫以在FMC圖形使用者介面(GUI)中填充各種資訊，例如控制台和事件檢視。
磁碟管理員
下一個邏輯圖顯示了運行狀況監視器和磁碟管理器進程的邏輯元件，因為它們相互交織以生成與磁碟相關的運行狀況警報。
簡而言之，磁碟管理器進程管理該盒的磁碟使用情況，並且其配置檔案位於[/ngfw]/etc/sf/資料夾中。磁碟管理員程式有多個組態檔可在特定情況下使用：
- diskmanager.conf -標準組態檔。
- diskmanager_2hd.conf -當包裝箱已安裝2個硬碟時使用。第二個硬碟驅動器與惡意軟體擴展相關，用於儲存檔案策略中定義的檔案。
- ramdisk-diskmanager.conf -在啟用「記錄到Ramdisk」時使用。有關詳細資訊，請檢視記錄到Ramdisk部分。
磁碟管理器監視的每種檔案型別都分配了一個思洛儲存器。根據系統上可用的磁碟空間量，磁碟管理器會為每個思洛儲存器計算高水位標籤(HWM)和低水位標籤(LWM)。
當磁碟管理器進程耗盡思洛儲存器時，它會一直耗盡到到達LWM的位置。由於每個檔案都會排出事件，因此可以超過此閾值。
要檢查感測器裝置上的思洛儲存器狀態，您可以使用此命令：
> show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.208 MB 130.417 MB Temporary Files 0 KB 108.681 MB 434.726 MB Action Queue Results 0 KB 108.681 MB 434.726 MB User Identity Events 0 KB 108.681 MB 434.726 MB UI Caches 4 KB 326.044 MB 652.089 MB Backups 0 KB 869.452 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.089 MB 1.274 GB Performance Statistics 45.985 MB 217.362 MB 2.547 GB Other Events 0 KB 434.726 MB 869.452 MB IP Reputation & URL Filtering 0 KB 543.407 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.736 GB Archives & Cores & File Logs 0 KB 869.452 MB 4.245 GB Unified Low Priority Events 974.109 MB 1.061 GB 5.307 GB RNA Events 879 KB 869.452 MB 3.396 GB File Capture 0 KB 2.123 GB 4.245 GB Unified High Priority Events 252 KB 3.184 GB 7.429 GB IPS Events 3.023 MB 2.547 GB 6.368 GB
當滿足下列條件之一時，會執行磁碟管理員程式：
- 流程開始（或重新啟動）
- 思洛儲存器到達HWM
- 手動清空思洛儲存器
- 每小時一次
每次運行磁碟管理器進程時，它都會在自己的日誌檔案中為每個不同的思洛儲存器生成一個條目，該日誌檔案位於[/ngfw]/var/log/diskmanager.log下並具有CSV格式的資料。
接下來，顯示來自diskmanager.log檔案的範例行。它來自一個感測器，該感測器觸發從統一低優先順序事件運行狀況警報中排出未處理的事件，以及各個列的細分：
priority_2_events,1599668981,221,4587929508,1132501868,20972020,4596,1586044534,5710966962,1142193392,110,0
| 欄 | 價值 |
| 思洛儲存器標籤 |
priority_2_事件 |
| 排出時間（紀元時間） |
1599668981 |
| 已耗盡的檔案數目 | 221 |
| 已耗盡的位元組 | 4587929508 |
| 排出後資料的目前大小（位元組） | 1132501868 |
| 已耗盡的最大檔案（位元組） | 20972020 |
| 已耗盡的最小檔案（位元組） | 4596 |
| 最舊的檔案已耗盡（紀元時間） | 1586044534 |
| 高浮水印（位元組） | 5710966962 |
| 低水位線（位元組） | 1142193392 |
| 已耗盡未處理事件的檔案數 | 110 |
| Diskmanager狀態標誌 | 0 |
然後，相應的運行狀況監控器模組會讀取此資訊，以觸發相關的運行狀況警報。
手動清空思洛儲存器
在某些情況下，您可以手動清空思洛儲存器。例如，使用手動清空思洛儲存器來清除磁碟空間而不是手動刪除檔案，其優點是允許磁碟管理器決定要保留和刪除哪些檔案。磁碟管理器保留該思洛儲存器的最新檔案。
任何思洛儲存器都可以被清空，並且如前所述（磁碟管理器會清空資料，直到資料量低於LWM閾值）。FTD CLISH模式中提供system support silo-drain 命令，該命令提供可用思洛的清單（名稱+數字id）。
以下是手動清空統一低優先順序事件思洛儲存器的示例：
> show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.213 MB 130.426 MB Temporary Files 0 KB 108.688 MB 434.753 MB Action Queue Results 0 KB 108.688 MB 434.753 MB User Identity Events 0 KB 108.688 MB 434.753 MB UI Caches 4 KB 326.064 MB 652.130 MB Backups 0 KB 869.507 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.130 MB 1.274 GB Performance Statistics 1.002 MB 217.376 MB 2.547 GB Other Events 0 KB 434.753 MB 869.507 MB IP Reputation & URL Filtering 0 KB 543.441 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.737 GB Archives & Cores & File Logs 0 KB 869.507 MB 4.246 GB Unified Low Priority Events 2.397 GB 1.061 GB 5.307 GB RNA Events 8 KB 869.507 MB 3.397 GB File Capture 0 KB 2.123 GB 4.246 GB Unified High Priority Events 0 KB 3.184 GB 7.430 GB IPS Events 0 KB 2.547 GB 6.368 GB > system support silo-drain Available Silos 1 - misc_fdm_logs 2 - Temporary Files 3 - Action Queue Results 4 - User Identity Events 5 - UI Caches 6 - Backups 7 - Updates 8 - Other Detection Engine 9 - Performance Statistics 10 - Other Events 11 - IP Reputation & URL Filtering 12 - arch_debug_file 13 - Archives & Cores & File Logs 14 - Unified Low Priority Events 15 - RNA Events 16 - File Capture 17 - Unified High Priority Events 18 - IPS Events 0 - Cancel and return Select a Silo to drain: 14 Silo Unified Low Priority Events being drained. > show disk-manager Silo Used Minimum Maximum misc_fdm_logs 0 KB 65.213 MB 130.426 MB Temporary Files 0 KB 108.688 MB 434.753 MB Action Queue Results 0 KB 108.688 MB 434.753 MB User Identity Events 0 KB 108.688 MB 434.753 MB UI Caches 4 KB 326.064 MB 652.130 MB Backups 0 KB 869.507 MB 2.123 GB Updates 304.367 MB 1.274 GB 3.184 GB Other Detection Engine 0 KB 652.130 MB 1.274 GB Performance Statistics 1.002 MB 217.376 MB 2.547 GB Other Events 0 KB 434.753 MB 869.507 MB IP Reputation & URL Filtering 0 KB 543.441 MB 1.061 GB arch_debug_file 0 KB 2.123 GB 12.737 GB Archives & Cores & File Logs 0 KB 869.507 MB 4.246 GB Unified Low Priority Events 1.046 GB 1.061 GB 5.307 GB RNA Events 8 KB 869.507 MB 3.397 GB File Capture 0 KB 2.123 GB 4.246 GB Unified High Priority Events 0 KB 3.184 GB 7.430 GB IPS Events 0 KB 2.547 GB 6.368 GB
運行狀況監視器
以下是要點：
- 在Health Monitor選單或Message Center的Health頁籤中的FMC上看到的任何運行狀況警報都由運行狀況監視器進程生成。
- 此過程會監控系統的運行狀況，包括FMC和受管感測器的運行狀況，並且由許多不同的模組組成。
- 健康風險通告模組在健康策略中定義，可以針對每個裝置連線這些模組。
- 運行狀況警報由磁碟使用模組生成，該模組可在FMC管理的每個感測器上運行。
- 當FMC上的運行狀況監視器進程運行時（每5分鐘一次或觸發手動運行時），磁碟使用模組將檢視diskmanager.log檔案，如果滿足正確的條件，將觸發相應的運行狀況警報。
若要觸發未處理事件漏出(Drain of Unprocessed events)運行狀況警報，必須滿足以下所有條件：
- Bytes drawed欄位大於0（這表示來自此思洛儲存器的資料被清空）。
- 已排出未處理事件的檔案數大於0（這表示已排出資料中存在未處理事件）。
- 排水時間是在過去1小時內。
若要觸發事件頻繁漏出運行狀況警報，以下條件必須為true：
- diskmanager.log檔案的最後兩個條目需要：
- Have Bytes drawed欄位大於0（這表示來自此思洛儲存器的資料被清空）。
- 間隔時間不超過5分鐘。
- 此思洛儲存器最後一個條目的耗盡時間是在過去1小時內。
從磁碟使用模組收集的結果（以及其他模組收集的結果）透過sftunnel傳送到FMC。使用sftunnel_status命令，您可以檢視透過sftunnel交換的運行狀況事件的計數器：
TOTAL TRANSMITTED MESSAGES <3544> for Health Events service
RECEIVED MESSAGES <1772> for Health Events service
SEND MESSAGES <1772> for Health Events service
FAILED MESSAGES <0> for Health Events service
HALT REQUEST SEND COUNTER <0> for Health Events service
STORED MESSAGES for Health service (service 0/peer 0)
STATE <Process messages> for Health Events service
REQUESTED FOR REMOTE <Process messages> for Health Events service
REQUESTED FROM REMOTE <Process messages> for Health Events service
登入到Ramdisk
即使大多數事件都儲存在磁碟中，裝置預設配置為記錄到ramdisk，以防止由於不斷向磁碟寫入和刪除事件而導致SSD逐漸損壞。
在此場景中，事件不儲存在[/ngfw]/var/sf/detection_engine/*/instance-N/下，但它們位於[/ngfw]/var/sf/detection_engine/*/instance-N/connection/中，這是指向/dev/shm/instance-N/connection的符號連結。在這種情況下，事件駐留在虛擬記憶體中，而不是實體記憶體中。
admin@FTD4140:~$ ls -la /ngfw/var/sf/detection_engines/b0c4a5a4-de25-11ea-8ec3-4df4ea7207e3/instance-1/connection
lrwxrwxrwx 1 sfsnort sfsnort 30 Sep 9 19:03 /ngfw/var/sf/detection_engines/b0c4a5a4-de25-11ea-8ec3-4df4ea7207e3/instance-1/connection -> /dev/shm/instance-1/connection
要驗證裝置當前配置為執行什麼操作，請從FTD CLISH運行show log-events-to-ramdisk命令。如果使用命令configure log-events-to-ramdisk <enable/disable>：
> show log-events-to-ramdisk
Logging connection events to RAM Disk.
> configure log-events-to-ramdisk
Enable or Disable enable or disable (enable/disable)
當您登入ramdisk時，主要缺點是各個思洛儲存器分配了較小的空間，因此在相同的情況下會更加頻繁地耗盡它們。下一個輸出是來自FPR 4140的磁碟管理器，其中啟用了ramdisk的日誌事件以供比較。
記錄至Ramdisk已啟用。
> show disk-manager
Silo Used Minimum Maximum
Temporary Files 0 KB 903.803 MB 3.530 GB
Action Queue Results 0 KB 903.803 MB 3.530 GB
User Identity Events 0 KB 903.803 MB 3.530 GB
UI Caches 4 KB 2.648 GB 5.296 GB
Backups 0 KB 7.061 GB 17.652 GB
Updates 305.723 MB 10.591 GB 26.479 GB
Other Detection Engine 0 KB 5.296 GB 10.591 GB
Performance Statistics 19.616 MB 1.765 GB 21.183 GB
Other Events 0 KB 3.530 GB 7.061 GB
IP Reputation & URL Filtering 0 KB 4.413 GB 8.826 GB
arch_debug_file 0 KB 17.652 GB 105.914 GB
Archives & Cores & File Logs 0 KB 7.061 GB 35.305 GB
RNA Events 0 KB 7.061 GB 28.244 GB
File Capture 0 KB 17.652 GB 35.305 GB
Unified High Priority Events 0 KB 17.652 GB 30.892 GB
Connection Events 0 KB 451.698 MB 903.396 MB
IPS Events 0 KB 12.357 GB 26.479 GB
已停用登入Ramdisk。
> show disk-manager
Silo Used Minimum Maximum
Temporary Files 0 KB 976.564 MB 3.815 GB
Action Queue Results 0 KB 976.564 MB 3.815 GB
User Identity Events 0 KB 976.564 MB 3.815 GB
UI Caches 4 KB 2.861 GB 5.722 GB
Backups 0 KB 7.629 GB 19.074 GB
Updates 305.723 MB 11.444 GB 28.610 GB
Other Detection Engine 0 KB 5.722 GB 11.444 GB
Performance Statistics 19.616 MB 1.907 GB 22.888 GB
Other Events 0 KB 3.815 GB 7.629 GB
IP Reputation & URL Filtering 0 KB 4.768 GB 9.537 GB
arch_debug_file 0 KB 19.074 GB 114.441 GB
Archives & Cores & File Logs 0 KB 7.629 GB 38.147 GB
Unified Low Priority Events 0 KB 9.537 GB 47.684 GB
RNA Events 0 KB 7.629 GB 30.518 GB
File Capture 0 KB 19.074 GB 38.147 GB
Unified High Priority Events 0 KB 19.074 GB 33.379 GB
IPS Events 0 KB 13.351 GB 28.610 GB
思洛儲存器大小越小，訪問事件並將其流向FMC的速度就越快，從而得到補償。雖然在適當的條件下這是更好的選擇，但是必須考慮它的缺點。
常見問題 (FAQ)
事件漏出運行狀況警報是否僅由連線事件生成？
編號
- 任何磁碟管理器思洛儲存器都可以生成頻繁清空的警報。
- 任何與事件相關的思洛儲存器都可以生成未處理事件的清空警報。
連線事件是最常見的罪魁禍首。
當出現頻繁清空運行狀況警報時，是否始終建議停用Log to Ramdisk？
否。僅適用於DOS/DDOS以外的過度記錄情況，當受影響的思洛儲存器是連線事件思洛儲存器時，以及無法進一步調整記錄設定的情況。
如果DOS/DDOS導致過多的日誌記錄，解決方案是實施DOS/DDOS保護或消除DOS/DDOS攻擊的來源。
預設的Log to Ramdisk功能可以減少SSD的磨損，因此強烈建議使用它。
什麼是未處理的事件？
事件不會單獨標籤為未處理。在下列情況下，檔案具有未處理的事件：
它的建立時間戳記高於相應書籤檔案中的時間戳記欄位。
或
其建立時間戳等於相應書籤檔案中的時間戳欄位，並且其大小高於相應書籤檔案上的位元組欄位中的位置。
FMC如何知道特定感測器的延遲位元組數？
感測器傳送有關unified_events檔名和大小的後設資料，以及書籤檔案上的資訊，為FMC提供足夠的資訊來計算後面的位元組，如下所示：
當前unified_events檔案大小-書籤檔案中的Bytes欄位中的位置+時間戳高於相應書籤檔案中的時間戳的所有unified_events檔案的大小。
已知的問題
打開Bug Search Tool，然後使用此查詢：
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
3.0 |
03-May-2024 |
已更新簡介、PII、替代文字、機器翻譯、連結目標和格式設定。 |
1.0 |
25-Sep-2020 |
初始版本 |
意見