目錄

簡介

必要條件

需求

採用元件

背景資訊

問題

解決方案

簡介

本文說明如何解決思科原則套件(CPS)中的consolidated-engine.log生成問題。

必要條件

需求

思科建議您瞭解以下主題：

- Linux

- CPS

思科建議您必須具有對CPS CLI的Root訪問許可權的許可權。

採用元件

本文中的資訊係根據以下軟體和硬體版本：

- CPS 20.2

- UCS-B

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

在CPS中，策略引擎日誌從所有Quantum網路套件(QNS)虛擬機器(VM)收集，並在pcrfclient VM上進行隔離。

回退框架用於收集策略引擎相關的日誌，並在活動的pcrfclient虛擬機器上儲存/隔離。

Logback是Java應用程式的日誌記錄框架，它是作為流行的log4j專案的後繼而建立的。

以下是/etc/broadhop/logback.xml檔案中生成和收集引擎日誌的相關配置。

1.將策略引擎日誌傳送到SOCKET附加器。

<logger name="policy.engine" level="info" additivity="false">

<appender-ref ref="SOCKET" />

</logger>

2. SOCKET附加器是指SOCKET-BASE附加器。

<appender name="SOCKET" class="com.broadhop.logging.appenders.AsynchAppender">

<appender-ref ref="SOCKET-BASE"/>

3. SOCKET-BASE具有將日誌傳送到遠端主機的配置：連接埠.

<appender name="SOCKET-BASE" class="com.broadhop.logging.net.SocketAppender">

<RemoteHost>${logging.controlcenter.host:-lbvip02}</RemoteHost>

<Port>${logging.controlcenter.port:-5644}</Port>

<ReconnectionDelay>10000</ReconnectionDelay>

<IncludeCallerData>false</IncludeCallerData>

</appender>

問題

如果CPS環境設定中存在任何型別的網路擺動或TCP相關錯誤，則pcrfclient VM會停止從各個VM接收SOCKET附加器型別日誌。

在SOCKET-BASE下配置的埠5644顯示TIMEWAIT。

[root@dc1-pcrfclient01 ~]# netstat -plan|grep 5644

tcp6 0 0 192.168.10.135:5644 192.168.10.137:47876 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:57042 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:60888 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:60570 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:32902 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:57052 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:47640 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:36484 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:57040 TIME_WAIT -

tcp6 0 0 192.168.10.135:5644 192.168.10.137:55788 TIME_WAIT -

[root@dc1-pcrfclient01 ~]#

如果幾分鐘後檢查相同的狀態，則沒有與埠5644相關的條目。

[root@dc1-pcrfclient01 ~]# netstat -plan|grep 5644

[root@dc1-pcrfclient01 ~]#

解決方案

恢復SOCKET連線的過程是在活動pcrfclient中重新啟動qns-1進程。

[root@dc1-pcrfclient01 ~]# monit stop qns-1

[root@dc1-pcrfclient01 ~]# monit status qns-1

Monit 5.26.0 uptime: 4d 22h 43m

Process 'qns-1'

status Not monitored

monitoring status Not monitored

monitoring mode active

on reboot start

data collected Tue, 04 Jan 2022 11:52:38

[root@dc1-pcrfclient01 ~]# monit start qns-1

[root@dc1-pcrfclient01 ~]# monit status qns-1

Monit 5.26.0 uptime: 4d 22h 42m

Process 'qns-1'

status OK

monitoring status Monitored

monitoring mode active

on reboot start

pid 25368

parent pid 1

uid 0

effective uid 0

gid 0

uptime 0m

threads 31

children 0

cpu 0.0%

cpu total 0.0%

memory 1.2% [197.4 MB]

memory total 1.2% [197.4 MB]

security attribute -

disk read 0 B/s [112 kB total]

disk write 0 B/s [60.2 MB total]

port response time -

data collected Tue, 04 Jan 2022 11:51:04