TWI780537B

TWI780537B - 智慧化調整監控告警服務的系統、方法及電腦可讀媒介

Info

Publication number: TWI780537B
Application number: TW109143670A
Authority: TW
Inventors: 徐國華; 許順興
Original assignee: 中華電信股份有限公司
Priority date: 2020-12-10
Filing date: 2020-12-10
Publication date: 2022-10-11
Also published as: TW202223658A

Abstract

本發明揭露一種智慧化調整監控告警服務的系統及方法，係由三個Ceilometer、Gnocchi與Aodh專案模組共同組成OpenStack雲平台之監控告警服務的架構，且OpenStack雲平台上設有至少一管理主機。再者，三個Ceilometer、Gnocchi與Aodh專案模組在管理主機上部署三個Ceilometer、Gnocchi與Aodh工作單元，以提供OpenStack雲平台之監控告警服務。另外，偵測模組可偵測三個Ceilometer、Gnocchi與Aodh工作單元的效能，以於Ceilometer、Gnocchi或Aodh工作單元的效能達到效能瓶頸時，由偵測模組在管理主機上擴充已達到效能瓶頸的Ceilometer、Gnocchi或Aodh工作單元的數量，使OpenStack雲平台之監控告警服務能持續正常運作。本發明復提供一種電腦可讀媒介，係用於執行智慧化調整監控告警服務的方法。

Description

智慧化調整監控告警服務的系統、方法及電腦可讀媒介

本發明係關於一種調整監控告警服務的技術，特別是指一種基於OpenStack之智慧化調整監控告警服務的系統、方法及電腦可讀媒介。

OpenStack是由美國航空暨太空總署和美國Rackspace公司合作研發之自由開放原始碼的雲端運算軟體，讓任何人都可自行建立提供雲端運算服務的雲平台。此OpenStack之雲端運算軟體由多個專案模組組成，每個專案模組具有各自專屬的名稱與各自負責處理的功能，專案模組的名稱通常是有意義的英文單字，但專案模組的功能則不一定跟名稱有關聯。例如，Keystone專案模組提供用戶身分驗證機制，Nova專案模組提供虛擬機之生命週期管理的服務...等。需說明者，前述OpenStack、Keystone、Nova通常直接使用英文(原文)，而不使用或無中文之翻譯(中文用語)，此係所屬技術領域中具有通常知識者所知悉的。

在一現有技術中，提出一種用以對雲計算服務進行監控的系統，可對具有雲服務節點的雲計算服務系統進行監控，並包括至少一個雲管理節點、多個監測節點與至少一個主監控節點。雲管理節點可提供管理功能，包括創建或刪除雲服務節點、主監控節點、監測節點。監測節點可依據從主監控節點所接收到的監控命令對雲計算服務系統中的雲服務節點進行監測，並將監測結果返回給主監控節點。主監控節點可向監測節點發送監控命令，並收集每個監測節點所返回的監測結果。惟，此現有技術並無法智慧化調整多個專案模組所提供的監控告警服務，亦無法擴充專案模組的工作單元(監控節點)。

因此，如何提供一套基於OpenStack之智慧化調整監控告警服務的機制，以智慧化調整多個專案模組所提供的監控告警服務，或者擴充多個專案模組的工作單元(worker)的數量等，實已成為本領域技術人員之一大課題。

需說明者，本發明所述OpenStack、Ceilometer、Gnocchi、Aodh通常直接使用英文(原文)，而不使用或無中文之翻譯(中文用語)，此係所屬技術領域中具有通常知識者所知悉的。

本發明提供一種智慧化調整監控告警服務的系統及方法，例如能由偵測模組智慧化調整三個專案模組所提供的監控告警服務，或者能由偵測模組(自動)擴充該等專案模組的工作單元(worker)的數量。

本發明中智慧化調整監控告警服務的系統包括：第一專案模組、第二專案模組與第三專案模組，係共同組成雲平台之監控告警服務的架構，且該雲平台上設有至少一管理主機，其中，第一專案模組、第二專案模組與第三專案模組在該雲平台之管理主機上分別部署至少一第一工作單元、至少一第二工作單元與至少一第三工作單元，用以共同提供該雲平台之監控告警服務；以及偵測模組，係偵測在該雲平台之管理主機上用以共同提供監控告警服務的第一專案模組之第一工作單元、第二專案模組之第二工作單元與第三專案模組之第三工作單元三者的效能，以於第一工作單元、第二工作單元或第三工作單元的效能達到效能瓶頸時，由偵測模組在該雲平台之管理主機上擴充已達到效能瓶頸的第一工作單元、第二工作單元或第三工作單元的數量，使該雲平台之監控告警服務持續正常運作。

本發明中智慧化調整監控告警服務的方法包括：由第一專案模組、第二專案模組與第三專案模組共同組成雲平台之監控告警服務的架構，且該雲平台上設置有至少一管理主機，其中，第一專案模組、第二專案模組與第三專案模組在該雲平台之管理主機上分別部署至少一第一工作單元、至少一第二工作單元與至少一第三工作單元，用以共同提供該雲平台之監控告警服務；以及由偵測模組偵測在該雲平台之管理主機上用以共同提供監控告警服務的第一專案模組之第一工作單元、第二專案模組之第二工作單元與第三專案模組之第三工作單元三者的效能，以於第一工作單元、第二工作單元或第三工作單元的效能達到效能瓶頸時，由偵測模組在該雲平台之管理主機上擴充已達到效能瓶頸的第一工作單元、第二工作單元或第三工作單元的數量，使該雲平台之監控告警服務持續正常運作。

本發明復提供一種電腦可讀媒介，應用於計算裝置或電腦中，係儲存有指令，以執行上述之智慧化調整監控告警服務的方法。

為讓本發明之上述特徵與優點能更明顯易懂，下文特舉實施例，並配合所附圖式作詳細說明。在以下描述內容中將部分闡述本發明之額外特徵及優點，且此等特徵及優點將部分自所述描述內容可得而知，或可藉由對本發明之實踐習得。應理解，前文一般描述與以下詳細描述兩者均為例示性及解釋性，且不欲約束本發明所欲主張之範圍。

1:智慧化調整監控告警服務的系統

10:OpenStack雲平台

11:管理主機

20:Ceilometer專案模組

21:Ceilometer服務

22:Ceilometer工作單元

23、33、43:應用程式介面

30:Gnocchi專案模組

31:Gnocchi服務

32:Gnocchi工作單元

40:Aodh專案模組

41:Aodh服務

42:Aodh工作單元

50:資料庫群集

51:資料庫

60:偵測模組

61:偵測工作單元

A:基礎設備

B:管理主機群

S01至S16:步驟

圖1為本發明中智慧化調整監控告警服務的系統的架構示意圖；

圖2為本發明中智慧化調整監控告警服務的系統的實施例示意圖；以及

圖3A至圖3B為本發明中智慧化調整監控告警服務的方法的流程示意圖。

以下藉由特定的具體實施形態說明本發明之實施方式，熟悉此技術之人士可由本說明書所揭示之內容了解本發明之其它優點與功效，亦可因而藉由其它不同的具體等同實施形態加以施行或運用。

圖1為本發明中智慧化調整監控告警服務的系統1的架構示意圖。在一實施例中，該智慧化調整監控告警服務的系統1係基於OpenStack，且包括OpenStack雲平台10、Ceilometer專案模組20、Gnocchi專案模組30、Aodh專案模組40、資料庫群集50與偵測模組60等。資料庫群集50可具有至少一或多個資料庫51，偵測模組60可具有至少一或多個偵測工作單元61，且多個偵測工作單元61分為一個主要的偵測工作單元61與至少一個(如多個)從屬的偵測工作單元61。

OpenStack雲平台10的監控告警服務的架構可由Ceilometer專案模組20、Gnocchi專案模組30與Aodh專案模組40等三個專案模組共同組成，且此三個專案模組可在OpenStack雲平台10上的管理主機群B中部分或全部的管理主機11(見圖2)上分別部署至少一或多個工作單元(即Ceilometer工作單元22、Gnocchi工作單元32、Aodh工作單元42)以共同提供OpenStack雲平台10的監控告警服務，前述工作單元亦可稱為工作程序。又，隨著OpenStack雲平台10的使用規模逐漸增大，此三個提供監控告警服務的專案模組(即Ceilometer專案模組20、Gnocchi專案模組30、Aodh專案模組40)的工作單元的數量也勢必要進行調整，以支撐OpenStack雲平台10持續增加的監控量。

此三個專案模組(即Ceilometer專案模組20、Gnocchi專案模組30、Aodh專案模組40)有各自負責的工作，三個專案模組的運作方式皆是透過部署至少一或多個工作單元在OpenStack雲平台10的至少一或多個管理主機11上，且三個專案模組的工作單元分別組成三個群組以提供對應的服務。申言之，此三個專案模組所提供的服務可部署多個工作單元在不同的管理主機11上，且三個專案模組(即Ceilometer專案模組20、Gnocchi專案模組30、Aodh專案模組40)可透過資料庫群集50或資料庫51互相溝通，以進行多個工作單元(即Ceilometer工作單元22、Gnocchi工作單元32、Aodh工作單元42)之間的分工及協同運作。例如，在圖1與圖2中，Ceilometer專案模組20具有至少一或多個(如第1個至第n 個)Ceilometer工作單元22以提供Ceilometer服務21，Gnocchi專案模組30具有至少一或多個(如第1個至第n個)Gnocchi工作單元32以提供Gnocchi服務31，Aodh專案模組40具有至少一或多個(如第1個至第n個)Aodh工作單元42以提供Aodh服務41，其中n代表大於1之正整數(如2、3、4、5或以上)。

Ceilometer專案模組20可提供Ceilometer服務21，以接收關聯於OpenStack雲平台10之監控告警服務的監控資料，例如Ceilometer專案模組20可接收所有構成OpenStack雲平台10的基礎設備A與提供給OpenStack雲平台10之用戶使用的虛擬機兩者之「效能值及狀態變化的事件」，且「效能值及狀態變化的事件」可合稱為「監控資料」。例如，基礎設備A可為管理主機11、運算主機、虛擬機、網路交換器、儲存設備等，且運算主機可以運行虛擬機。效能值可為記憶體之使用率、硬碟之空間、網路之流量等，狀態變化可為基礎設備A之開機或關機狀態等。

Gnocchi專案模組30可提供Gnocchi服務31，以儲存或由用戶查詢來自Ceilometer專案模組20(Ceilometer服務21)之關聯於OpenStack雲平台10之監控告警服務的監控資料，且Gnocchi專案模組30(Gnoechi服務31)可事先計算多筆監控資料(如虛擬機之記憶體的使用率等)在一段時間區間內的平均值、最大值或最小值等數值，例如每1小時計算這1小時內某台虛擬機之記憶體的使用率的平均值、最大值或最小值等數值。接著，Gnocchi專案模組30(Gnocchi服務31)可將監控資料的數值儲存在資料庫群集50或資料庫51中，以方便用戶自資料庫群集50或資料庫51中查詢監控資料或其數值，且經過計算(儲存)之監控資料或其數值可稱為「統計資料」。

Aodh專案模組40可提供Aodh服務41，以設定關聯於OpenStack雲平台10之監控告警服務的告警規則或門檻值，且Aodh專案模組40(Aodh服務41)可輪詢(如定期輪詢)Gnocchi專案模組30(Gnocchi服務31)儲存在資料庫群集50或資料庫51中之統計資料的數值是否超過門檻值，以於統計資料的數值超過門檻值時，由Aodh專案模組40(Aodh服務41)發送告警或告警事件。例如，Aodh專案模組40(Aodh服務41)可設定某台虛擬機於每段時間(如每小時)之記憶體的使用率的平均值大於門檻值(如90%)時發送告警或告警事件，故Aodh專案模組40(Aodh服務41)的Aodh工作單元42可定期輪詢Gnocchi專案模組30(Gnocchi服務31)儲存在資料庫群集50或資料庫51中之統計資料(如虛擬機之統計資料)，當統計資料的數值達到或大於門檻值(如90%)時，Aodh專案模組40(Aodh服務41)就會發送告警或告警事件。

偵測模組60或其主要的偵測工作單元61可偵測在OpenStack雲平台10之管理主機11上用以共同提供相關監控告警服務的三個專案模組(即Ceilometer專案模組20、Gnocchi專案模組30、Aodh專案模組40)的工作單元(即Ceilometer工作單元22、Gnocchi工作單元32、Aodh工作單元42)的運作狀態及效能，以透過一些項目分析目前OpenStack雲平台10之管理主機11上的工作單元的運作狀態是否異常、以及是否達到效能瓶頸(如待處理的工作數量持續增加)。

例如，若OpenStack雲平台10之管理主機11上的工作單元(即Ceilometer工作單元22、Gnocchi工作單元32、Aodh工作單元42)的運作狀態有異常，則偵測模組60或其主要的偵測工作單元61可重啟有異常的工作單元(即Ceilometer工作單元22、Gnocchi工作單元32、Aodh工作單元42)予以自動修復。或者，若OpenStack雲平台10之管理主機11上的工作單元(即Ceilometer工作單元22、Gnocchi工作單元32、Aodh工作單元42)的效能達到效能瓶頸，則偵測模組60或其主要的偵測工作單元61可於OpenStack雲平台10之負載度(如中央處理器的使用率、記憶體的使用率等)最低的管理主機11上擴充(如自動擴充)達到效能瓶頸的工作單元(即Ceilometer工作單元22、Gnocchi工作單元32、Aodh工作單元42)的數量，使OpenStack雲平台10的監控告警服務能持續正常運作，俾確保監控告警服務的品質。

圖2為本發明中智慧化調整監控告警服務的系統的實施例示意圖，並參閱圖1予以說明。

如圖2所示，偵測模組60或其主要的偵測工作單元61可偵測Ceilometer專案模組20、Gnocchi專案模組30與Aodh專案模組40等三個專案模組共同組成之OpenStack雲平台10的監控告警服務的架構，以克服或解決此三個專案模組之監控告警服務的過載問題。亦即，偵測模組60或其主要的偵測工作單元61可使用輪詢(如定期輪詢)的方式逐一檢查Ceilometer專案模組20(Ceilometer服務21)之Ceilometer工作單元22、Gnocchi專案模組30(Gnocchi服務31)之Gnocchi工作單元32與Aodh專案模組40(Aodh服務41)之Aodh工作單元42在OpenStack雲平台10之管理主機11上的運作狀態，以由偵測模組60或其主要的偵測工作單元61依據此運作狀態判斷是否需要修復或擴充Ceilometer工作單元22、Gnocchi工作單元32或Aodh工作單元42。

偵測模組60可具有至少一或多個偵測工作單元61，例如多個偵測工作單元61包括第1個至第n個(n代表大於1之正整數)偵測工作單元61，以將多個偵測工作單元61分別部署於OpenStack雲平台10之多個管理主機11上，且多個偵測工作單元61可採用主從(Master-Slave)模式。例如，主從模式為以第1個部署的偵測工作單元61為主要的偵測工作單元(Master)，第2個以後(即第2個至第n個)部署的偵測工作單元61為從屬的偵測工作單元(Slave)，且所有或多個偵測工作單元61使用共同的資料庫群集50或資料庫51，以透過資料庫群集50或資料庫51記錄偵測工作單元61自身是否存活。當主要的偵測工作單元61出現異常時，多個從屬的偵測工作單元61可透過選舉機制找出一個從屬的偵測工作單元61當作新的主要的偵測工作單元61，俾確保偵測模組60能持續不中斷的運作。

偵測模組60或其主要的偵測工作單元61可(自動)啟動輪詢程序(輪詢檢查程序)，以使用輪詢的方式檢查(如定期檢查)Ceilometer專案模組20(Ceilometer服務21)之佇列(queue)中尚未處理的監控資料的累積數量是否有持續增加的趨勢且超過門檻值(如設定上限)？若偵測模組60或其主要的偵測工作單元61檢查出尚未處理的監控資料的累積數量大於前次輪詢時的累積數量且超過門檻值(如設定上限)，則偵測模組60或其主要的偵測工作單元61判定Ceilometer專案模組20(Ceilometer服務21)的效能達到效能瓶頸，即現有的Ceilometer專案模組20(Ceilometer服務21)之Ceilometer工作單元22無法有效在輪詢的週期內接收完這週期內所增加的監控資料。

在此情況下，偵測模組60或其主要的偵測工作單元61可透過Ceilometer專案模組20(Ceilometer服務21)所提供的應用程式介面23判斷Ceilometer專案模組20(Ceilometer服務21)中是否有Ceilometer工作單元22出現異常而需要透過重啟的方式予以修復。若有Ceilometer工作單元22出現異常，則偵測模組60或其主要的偵測工作單元61可將有異常的Ceilometer工作單元22進行重啟作業(程序)予以修復。反之，若所有的Ceilometer工作單元22皆無出現異常，則偵測模組60或其主要的偵測工作單元61可啟動Ceilometer工作單元22的擴充作業(程序)，以藉由擴充作業(程序)找出OpenStack雲平台10之管理主機群B中最近一段時間內負載度(如中央處理器的使用率等)最低的管理主機11增加至少一個Ceilometer工作單元22，俾利用所增加的Ceilometer工作單元22加快消化累積在Ceilometer專案模組20(Ceilometer服務21)之佇列中尚未處理的監控資料。在完成重啟作業或擴充作業(程序)後，結束本次輪詢Ceilometer專案模組20(Ceilometer服務21)的檢查。

接著，偵測模組60或其主要的偵測工作單元61可檢查Gnocchi專案模組30(Gnocchi服務31)中用以接收來自Ceilometer專案模組20(Ceilometer服務21)之監控資料的Gnocchi工作單元32的工作日誌(log)，以確認Gnocchi工作單元32的工作日誌(log)中最近一段時間內是否有出現(多個或大量)用以連接可存放監控資料之資料庫群集50或資料庫 51的存取資料庫錯誤的紀錄。若Gnocchi工作單元32的工作日誌中有出現存取資料庫錯誤的紀錄，則表示此Gnocchi工作單元32用以連接資料庫群集50或資料庫51之連接池(connection pool)的連線數不足。

在此情況下，偵測模組60或其主要的偵測工作單元61可透過Gnocchi專案模組30(Gnocchi服務31)所提供的應用程式介面33判斷Gnocchi專案模組30(Gnocchi服務31)中是否有Gnocchi工作單元32出現異常需要透過重啟的方式予以修復。若有Gnocchi工作單元32出現異常，則偵測模組60或其主要的偵測工作單元61可將有異常的Gnocchi工作單元32進行重啟作業(程序)予以修復。反之，若所有的Gnocchi工作單元32皆無出現異常，則偵測模組60或其主要的偵測工作單元61可啟動Gnocchi工作單元32的擴充作業(程序)，以藉由擴充作業(程序)找出OpenStack雲平台10之管理主機群B中最近一段時間內負載度(如中央處理器的使用率等)最低的管理主機11增加至少一個Gnocchi工作單元32而增加可用的連線數，進而解決連接池之連線數不足的問題。

偵測模組60或其主要的偵測工作單元61在確認Gnocchi專案模組30(Gnocchi服務31)之Gnocchi工作單元32的工作日誌無任何錯誤的情況下，可透過Gnocchi專案模組30(Gnocchi服務31)所提供的應用程式介面33檢查Gnocchi專案模組30(Gnocchi服務31)中所有等待事先計算的監控資料的累積數量是否有持續增加的趨勢且超過門檻值(如設定上限)？若監控資料的累積數量於一段時間內達到一定的累積數量或超過門檻值(如假設1分鐘會監控一次虛擬機，若5分鐘內累積了5筆等待處理的監控資料，代表這台虛擬機有5分鐘沒有統計資料)，則偵測模組60 或其主要的偵測工作單元61可啟動Gnocchi工作單元32的擴充作業(程序)，以藉由擴充作業(程序)找出OpenStack雲平台10之管理主機群B中最近一段時間內負載度(如中央處理器的使用率等)最低的管理主機11增加至少一個Gnocchi工作單元32，俾增加整體Gnocchi專案模組30(Gnocchi服務31)處理事先計算的監控資料的效能。在完成上述Gnocchi工作單元32的重啟作業或擴充作業(程序)後，結束本次輪詢Gnocchi專案模組30(Gnocchi服務31)的檢查。

在輪詢程序(輪詢檢查程序)的最後一個檢查項目中，偵測模組60或其主要的偵測工作單元61可透過Aodh專案模組40(Aodh服務41)所提供的應用程式介面43檢查Aodh專案模組40(Aodh服務41)之每個Aodh工作單元42於輪詢Gnocchi專案模組30(Gnocchi服務31)儲存在資料庫群集50或資料庫51中之統計資料時的功能是否有異常，以及每個Aodh工作單元42輪詢Gnocchi專案模組30(Gnocchi服務31)之統計資料所花費的時間是否超過輪詢的週期(如Aodh工作單元每2分鐘輪詢一次，但輪詢所花費的時間超過2分鐘)。

若有Aodh工作單元42的功能出現異常，則偵測模組60或其主要的偵測工作單元61可重啟有異常的Aodh工作單元42予以修復，以在完成重啟(修復)Aodh工作單元42後，結束本次輪詢Aodh專案模組40(Aodh服務41)的檢查。又，若是Aodh工作單元42輪詢Gnocchi專案模組30(Gnocchi服務31)之統計資料所花費的時間超過輪詢的週期(過長)，代表Aodh工作單元42被分配到的工作太多而導致無法在輪詢的週期內處理完成，則偵測模組60或其主要的偵測工作單元61可啟動Aodh工作單元42的擴充作業(程序)，以藉由擴充作業(程序)找出OpenStack雲平台10之管理主機群B中最近一段時間內負載度(如中央處理器的使用率等)最低的管理主機11增加至少一個Aodh工作單元42來分擔其它Aodh工作單元42的處理量。在完成重啟作業或擴充作業(程序)後，結束本次輪詢Aodh專案模組40(Aodh服務41)的檢查。

因此，本發明能夠在OpenStack雲平台10之管理主機群B整體的負載度(如中央處理器的使用率等)還充足的情況下，有效且可靠地維持OpenStack雲平台10上之監控告警服務的運作，大幅減少維運監控告警服務的人力成本。

圖3A至圖3B為本發明中智慧化調整監控告警服務的方法的流程示意圖，並參閱圖1與圖2予以說明。在一實施例中，該智慧化調整監控告警服務的方法係基於OpenStack，且其主要內容如下，而相同於上述圖1與圖2之說明，於此不再重覆敘述。

該智慧化調整監控告警服務的方法可包括：由Ceilometer專案模組20、Gnocchi專案模組30與Aodh專案模組40共同組成OpenStack雲平台10之監控告警服務的架構，且OpenStack雲平台10上設置有至少一管理主機11，其中，Ceilometer專案模組20、Gnocchi專案模組30與Aodh專案模組40在OpenStack雲平台10之管理主機11上分別部署至少一Ceilometer工作單元22、至少一Gnocchi工作單元32與至少一Aodh工作單元42，用以共同提供OpenStack雲平台10之監控告警服務。再者，由偵測模組60偵測在OpenStack雲平台10之管理主機11上用以共同提供監控告警服務的Ceilometer專案模組20之Ceilometer工作單元22、 Gnocchi專案模組30之Gnocchi工作單元32與Aodh專案模組40之Aodh工作單元42三者的效能，以於Ceilometer工作單元22、Gnocchi工作單元32或Aodh工作單元42的效能達到效能瓶頸時，由偵測模組60在OpenStack雲平台10之管理主機11上自動擴充已達到效能瓶頸的Ceilometer工作單元22、Gnocchi工作單元32或Aodh工作單元42的數量，使OpenStack雲平台10之監控告警服務持續正常運作。

如圖1與圖2所示，偵測模組60之多個(如第1個至第n個)偵測工作單元61分別部署於OpenStack雲平台10之多個(如第1個至第n個)管理主機11上，且多個偵測工作單元61以主從(Master-Slave)模式的高可靠性方式運行，其中n代表大於1之正整數(如2、3、4、5或以上)。

偵測模組60或其主要的偵測工作單元61可使用輪詢(如定期輪詢)的方式逐一檢查Ceilometer專案模組20(Ceilometer服務21)之Ceilometer工作單元22、Gnocchi專案模組30(Gnocchi服務31)之Gnocchi工作單元32與Aodh專案模組40(Aodh服務41)之Aodh工作單元42在多個管理主機11上的運作狀態，以依據此運作狀態判斷是否需要修復或擴充Ceilometer工作單元22、Gnocchi工作單元32或Aodh工作單元42。

如圖3A之步驟S01所示，偵測模組60或其主要的偵測工作單元61可每段時間(如每小時)定期或自動啟動輪詢程序(輪詢檢查程序)。

如圖3A之步驟S02所示，偵測模組60或其主要的偵測工作單元61檢查Ceilometer專案模組20(Ceilometer服務21)之佇列中尚未處理的監控資料的累積數量是否有持續增加的趨勢且超過門檻值(如設定上限)？若是(監控資料的累積數量有持續增加的趨勢且超過門檻值)，則進行圖3A之步驟S03。反之，若否(監控資料的累積數量無持續增加的趨勢或未超過門檻值)，則進行圖3A之步驟S06。

如圖3A之步驟S03所示，偵測模組60或其主要的偵測工作單元61可透過Ceilometer專案模組20(Ceilometer服務21)所提供的應用程式介面23檢查Ceilometer專案模組20(Ceilometer服務21)中是否有Ceilometer工作單元22出現異常？若是(有Ceilometer工作單元22出現異常)，則進行圖3A之步驟S04，由偵測模組60或其主要的偵測工作單元61重啟Ceilometer工作單元22予以修復。反之，若否(無Ceilometer工作單元22出現異常)，則進行圖3A之步驟S05，由偵測模組60或其主要的偵測工作單元61判定是Ceilometer專案模組20(Ceilometer服務21)的效能達到效能瓶頸，故偵測模組60或其主要的偵測工作單元61可進行Ceilometer工作單元22的擴充作業(程序)，以藉由擴充作業(程序)找出最近一段時間內負載度最低的管理主機11增加至少一個Ceilometer工作單元22。

如圖3A之步驟S06所示，偵測模組60或其主要的偵測工作單元61檢查用以接收來自Ceilometer專案模組20(Ceilometer服務21)之監控資料的Gnocchi工作單元32的工作日誌(log)，以確認工作日誌中最近一段時間內是否有出現存取資料庫錯誤的紀錄(情況)？若是(工作日誌中有出現存取資料庫錯誤的紀錄)，則進行圖3A之步驟S07。反之，若否(工作日誌中無出現存取資料庫錯誤的紀錄)，則進行圖3B之步驟S10。

如圖3A之步驟S07所示，偵測模組60或其主要的偵測工作單元61可透過Gnocchi專案模組30(Gnocchi服務31)所提供的應用程式介面33檢查Gnocchi專案模組30(Gnocchi服務31)中是否有Gnocchi工作單元32出現異常？若是(有Gnocchi工作單元32出現異常)，則進行圖3A之步驟S08，由偵測模組60或其主要的偵測工作單元61重啟Gnocchi工作單元32予以修復。反之，若否(無Gnocchi工作單元32出現異常)，則進行圖3A之步驟S09，由偵測模組60或其主要的偵測工作單元61判定是Gnocchi工作單元32用以連接可存放監控資料之資料庫群集50或資料庫51之連接池的連線數不足而導致存取資料庫錯誤，故偵測模組60或其主要的偵測工作單元61可進行Gnocchi工作單元32的擴充作業(程序)，以藉由擴充作業(程序)找出OpenStack雲平台10之管理主機群B中最近一段時間內負載度(如中央處理器的使用率等)最低的管理主機11增加至少一個Gnocchi工作單元32，俾增加整體Gnocchi專案模組30(Gnocchi服務31)處理事先計算的監控資料的效能。

如圖3B之步驟S10所示，偵測模組60或其主要的偵測工作單元61可透過Gnocchi專案模組30(Gnocchi服務31)所提供的應用程式介面33檢查Gnocchi專案模組30(Gnocchi服務31)中所有等待事先計算的監控資料的累積數量是否有持續增加的趨勢且超過門檻值(如設定上限)？若是(監控資料的累積數量有持續增加的趨勢且超過門檻值)，則進行圖3B之步驟S11，由偵測模組60或其主要的偵測工作單元61判定是用以處理事先計算的Gnocchi工作單元32不足而導致處理延遲，故偵測模組60或其主要的偵測工作單元61可進行Gnocchi工作單元32的擴充作業(程序)，以藉由擴充作業(程序)找出OpenStack雲平台10之管理主機群B中最近一段時間內負載度(如中央處理器的使用率等)最低的管理主機11 增加至少一個Gnocchi工作單元32，俾增加整體Gnocchi專案模組30(Gnocchi服務31)處理事先計算的監控資料的效能。反之，若否(監控資料的累積數量無持續增加的趨勢或未超過門檻值)，則進行圖3B之步驟S12。

如圖3B之步驟S12所示，偵測模組60或其主要的偵測工作單元61可透過Aodh專案模組40(Aodh服務41)所提供的應用程式介面43檢查每個Aodh工作單元42於輪詢Gnocchi專案模組30(Gnocchi服務31)之統計資料所花費的時間是否超過輪詢的週期？若是(輪詢所花費的時間超過輪詢的週期)，則進行圖3B之步驟S13。反之，若否(輪詢所花費的時間未超過輪詢的週期)，則進行圖3B之步驟S16，完成本次的偵測監控告警服務的流程。

如圖3B之步驟S13所示，偵測模組60或其主要的偵測工作單元61檢查是否有Aodh工作單元42出現異常？若是(有Aodh工作單元42出現異常)，則進行圖3B之步驟S14，由偵測模組60或其主要的偵測工作單元61重啟有異常的Aodh工作單元42予以修復。反之，若否(無Aodh工作單元42出現異常)，則進行圖3B之步驟S15，由偵測模組60或其主要的偵測工作單元61判定是出現Aodh工作單元42的數量不足而導致無法在輪詢的週期內處理完成，故偵測模組60或其主要的偵測工作單元61可啟動Aodh工作單元42的擴充作業(程序)，以藉由擴充作業(程序)找出OpenStack雲平台10之管理主機群B中最近一段時間內負載度(如中央處理器的使用率等)最低的管理主機11增加至少一個Aodh工作單元42來分擔其它Aodh工作單元42的處理量。在完成圖3B之步驟S14與步驟S15後，即完成本次的偵測監控告警服務的流程。

在上述實施例中，例如：雲平台可為OpenStack雲平台10，第一專案模組、第二專案模組、第三專案模組可分別為Ceilometer專案模組20、Gnocchi專案模組30、Aodh專案模組40，第一服務、第二服務、第三服務可分別為Ceilometer服務21、Gnocchi服務31、Aodh服務41，第一工作單元、第二工作單元、第三工作單元可分別為Ceilometer工作單元22、Gnocchi工作單元32、Aodh工作單元42。但是，本發明並不以此為限。

此外，本發明還揭示一種電腦可讀媒介，係應用於具有處理器(例如，CPU、GPU等)及/或記憶體的計算裝置或電腦中，且儲存有指令，並可利用此計算裝置或電腦透過處理器及/或記憶體執行此電腦可讀媒介，以於執行此電腦可讀媒介時執行上述之方法及各步驟。

綜上，本發明中智慧化調整監控告警服務的系統、方法及電腦可讀媒介係至少具有下列特色、優點或技術功效。

一、本發明之偵測模組(主要的偵測工作單元)能智慧化調整三個Ceilometer、Gnocchi與Aodh專案模組所提供的監控告警服務，亦能(自動)擴充Ceilometer、Gnocchi或Aodh專案模組的工作單元的數量。

二、本發明之偵測模組(主要的偵測工作單元)能偵測OpenStack雲平台之監控告警服務的效能瓶頸及擴充監控告警服務的效能，亦能有效且可靠地維持OpenStack雲平台的監控告警功能的運作，也能減少問題排除的時間與維運所耗費的時間與人力。

三、本發明能在不佔用過多管理主機的運算資源(如中央處理器的使用率等)的情況下，維持OpenStack雲平台之監控告警服務的穩定運作，以克服或解決OpenStack雲平台的規模持續擴大時，大量監控與告警相關資料的處理(如儲存、計算、比對等)造成監控告警服務之負載過大而出現延遲甚至停擺(crash)的情況。

四、習知技術通常事先在管理主機群中配置好大量監控告警服務的工作單元，故易導致工作單元沒事做但卻佔用管理主機的運算資源，或事先配置的工作單元的數量不足而導致服務延遲或停擺。相對地，本發明可於監控告警服務的效能達到瓶頸時才(自動)擴充工作單元，故能在佔用最少管理主機之運算資源的情況下，讓監控告警服務發揮最大的處理能力，不但能改善OpenStack雲平台之監控告警服務的穩定性，亦能減少OpenStack雲平台上管理主機的運算資源的浪費。

五、本發明透過輪詢或定期排程以循序方式逐一檢查OpenStack雲平台上之管理主機中，三個Ceilometer、Gnocchi、Aodh專案模組所提供的監控告警服務的工作單元的運作狀態，以利偵測模組(主要的偵測工作單元)判斷是否需要透過重啟方式來修復工作單元的運作，或判斷達到效能瓶頸時自動於管理主機群中負載度(如中央處理器的使用率或記憶體的使用率等)最低的管理主機上擴充工作單元的數量。

六、本發明之三個Ceilometer、Gnocchi、Aodh專案模組可無需事先配置過多的工作單元，亦可無需維運人員之人工介入以針對三個專案模組的工作單元做擴充，有利於節省OpenStack雲平台的建置費用與維運人力成本。

七、本發明能同時部署多個採用主從模式的偵測工作單元於多個管理主機上，例如以第1個部署的偵測工作單元為主要的偵測工作單元(Master)，第2個以後部署的偵測工作單元為從屬的偵測工作單元(Slave)，多個偵測工作單元使用共同的資料庫群集，當主要的偵測工作單元出現異常時，多個從屬的偵測工作單元可透過選舉機制找出一個從屬的偵測工作單元當作新的主要的偵測工作單元，俾確保偵測模組或系統能持續不中斷的運作而維持監控告警服務的品質。

上述實施形態為例示性說明本發明之原理、特點及其功效，並非用以限制本發明之可實施範疇，任何熟習此項技藝之人士均能在不違背本發明之精神及範疇下，對上述實施形態進行修飾與改變。任何使用本發明所揭示內容而完成之等效改變及修飾，均仍應為申請專利範圍所涵蓋。因此，本發明之權利保護範圍應如申請專利範圍所列。