監控系統資料函式庫設計與資料正規化

在建構高可靠度的監控系統時，資料函式庫設計扮演著至關重要的角色。良好的資料函式庫設計不僅能確保資料的正確性和一致性，還能提升系統的效能和可維護性。本文將探討如何應用資料正規化原則設計監控系統的資料函式庫，並提供實際的 SQL 程式碼範例。首先，我們會從效能讀數、網站組態、排程組態等導向分析資料結構，接著逐步應用第一正規化、第二正規化和第三正規化，消除資料冗餘並提升資料函式庫的完整性。最後，我們將提供完整的 SQL 程式碼，用於建立主機、感測器、檢查設定等核心表格，並說明如何使用外部索引鍵約束來維護資料函式庫的關聯性。

管理與監控子系統的資料函式庫設計與資料正規化

效能讀數與監控資料儲存

在監控系統中，效能讀數（Performance Readings）是最關鍵的資料元件。每個效能讀數都需要記錄其被記錄的時間，以便在時間軸上正確呈現。同時，也需要記錄數值、感測器應用程式回傳碼，以及節點和感測器的識別資訊。

網站組態與集中管理

目前，網站資訊只會儲存監控伺服器位址，但需要預留未來功能擴充的空間。重要的是，網站資訊是在監控伺服器上集中維護的，而代理伺服器會檢索此資訊並更新本地組態。集中儲存組態資訊可以更容易地控制組態，當代理需要更新時，單獨的程式將發出更新命令以自動更新組態。

排程組態與檢查排程

排程組態定義了需要在哪些監控代理上執行哪些感測器命令，以及執行的間隔。每個代理檢查組合都會儲存相關的間隔設定。此資料類別似於UNIX cron檔案中定義的資訊，但不需要像cron那樣靈活地定義執行時間模式。所有時間間隔將具有相同的長度。

資料結構設計與資料函式庫佈局

在前面的章節中，我們簡要描述了將在監控系統中使用的資料結構的高階設計。在本文中，我們將建立資料函式庫佈局和不同資料函式庫表格之間的關係。最後，這些資訊將對映到用於初始化資料函式庫的SQL陳述式。

資料正規化的介紹

資料正規化是一種確保資料以防止資料完整性丟失的方式進行維護的方法。如果資料函式庫結構未正規化，則錯誤的程式碼操作、使用者資料輸入錯誤或更新操作期間的系統或應用程式故障都可能導致資料損壞。

第一正規化形式（1NF）

第一正規化形式定義了兩個重要的規則：列必須是唯一的，並且列內不應有重複群組。第一條規則很明顯，意味著必須有一種方法可以唯一地識別每一列。第二條規則意味著不能定義多個攜帶邏輯上相同資訊的列。

CREATE TABLE monitoring_agents (
  id INT PRIMARY KEY,
  hostname VARCHAR(255) NOT NULL,
  address VARCHAR(255) NOT NULL
);

CREATE TABLE sensors (
  id INT PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  options VARCHAR(255) NOT NULL
);

CREATE TABLE agent_checks (
  id INT PRIMARY KEY,
  agent_id INT NOT NULL,
  sensor_id INT NOT NULL,
  interval INT NOT NULL,
  FOREIGN KEY (agent_id) REFERENCES monitoring_agents(id),
  FOREIGN KEY (sensor_id) REFERENCES sensors(id)
);

內容解密：

上述SQL陳述式建立了三個表格：monitoring_agents、sensors和agent_checks。monitoring_agents表格儲存了監控代理的資訊，sensors表格儲存了感測器的資訊，而agent_checks表格則儲存了代理檢查的排程組態。透過使用外部索引鍵（FOREIGN KEY），我們確保了資料的一致性和完整性。

第二正規化形式（2NF）

第二正規化形式要求資料滿足第一正規化形式的所有規則，並且所有非主鍵欄位都依賴於主鍵的所有欄位。考慮以下範例：

CREATE TABLE agent_sensor_config (
  agent_id INT NOT NULL,
  sensor_id INT NOT NULL,
  default_option VARCHAR(255) NOT NULL,
  PRIMARY KEY (agent_id, sensor_id),
  FOREIGN KEY (agent_id) REFERENCES monitoring_agents(id),
  FOREIGN KEY (sensor_id) REFERENCES sensors(id)
);

內容解密：

上述SQL陳述式建立了一個名為agent_sensor_config的表格，用於儲存代理感測器組態的資訊。這個表格的主鍵是agent_id和sensor_id的組合，確保了每個代理感測器組合的唯一性。同時，使用外部索引鍵確保了與monitoring_agents和sensors表格的關聯。

資料函式庫正規化在監控系統設計中的應用

在設計監控系統的資料函式庫時，資料正規化（Data Normalization）是一項重要的步驟，旨在確保資料的一致性和完整性。資料正規化透過將資料拆分成多個表格，以消除資料冗餘和依賴問題。

第一正規化（First Normal Form）

第一正規化要求每個欄位都包含原子性的資料，且每行資料都有唯一的鍵值。以監控系統中的檢查設定資料為例，最初的表格可能如下：

這個表格不滿足第二正規化，因為 default option 只依賴於 sensor。因此，需要將其拆分成兩個表格：

Sensor 預設值表格

節點檢查表格

第二正規化（Second Normal Form）

第二正規化要求每個非鍵值欄位都完全依賴於主鍵。如果表格沒有複合鍵，則自動滿足第二正規化。上例中的兩個表格都滿足第二正規化。

第三正規化（Third Normal Form）

第三正規化要求非鍵值欄位之間不能有依賴關係。考慮以下範例：

這個表格不滿足第三正規化，因為 sensor location 依賴於 sensor。因此，需要將其拆分成兩個表格：

檢查記錄表格

Sensor 資訊表格

資料正規化的優缺點

資料正規化可以確保資料的一致性和完整性，但也可能增加查詢的複雜度和效能開銷。在某些情況下，為了提高效能，可以適度犧牲正規化程度。

在監控系統中的實際應用

在設計監控系統的資料函式庫時，可以先識別出靜態且獨立的物件，如主機（Host）和感測器（Sensor），然後為每個物件建立表格。

主機表格（Host Entries）

感測器表格（Sensor Entries）

對於感測器檢查的設定，可以將其拆分成多個表格，以滿足第三正規化的要求。這樣不僅可以確保資料的一致性和完整性，也可以提高系統的可擴充套件性和維護性。

程式碼範例

CREATE TABLE Hosts (
    Id INTEGER PRIMARY KEY,
    Name TEXT NOT NULL,
    Address TEXT NOT NULL,
    Port TEXT NOT NULL
);

CREATE TABLE Sensors (
    Id INTEGER PRIMARY KEY,
    Name TEXT NOT NULL
);

CREATE TABLE Sensor_Checks (
    Sensor_Id INTEGER,
    Check_Name TEXT NOT NULL,
    FOREIGN KEY (Sensor_Id) REFERENCES Sensors(Id)
);

內容解密：

上述 SQL 程式碼建立了三個表格：Hosts、Sensors 和 Sensor_Checks。Hosts 表格用於儲存主機的相關資訊，Sensors 表格用於儲存感測器的資訊，而 Sensor_Checks 表格則用於儲存每個感測器對應的檢查專案。透過外部索引鍵約束，確保了感測器與其檢查專案之間的關聯性。這樣的設計滿足了第三正規化的要求，並且提高了資料的一致性和完整性。

管理與監控子系統的資料函式庫設計

在設計管理與監控子系統的資料函式庫時，需要考慮多個關鍵表格及其之間的關聯。本章節將詳細介紹這些表格的結構及其在系統中的作用。

探針（Probe）相關表格

探針是用於檢查系統狀態的機制。相關的表格包括探針定義表格、探針與主機對映表格以及探針讀數表格。

探針定義表格

探針定義表格（Table 9-3）儲存了不同探針的詳細資訊，包括其名稱、引數、預設的警告及錯誤閾值等。初始設計中，該表格包含了警告及錯誤閾值，但進一步分析發現這違反了資料函式庫正規化的原則。因此，考慮將閾值資訊獨立成一個新的表格，以提高資料函式庫的靈活性。

CREATE TABLE probes (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    parameter TEXT NOT NULL,
    sensor_id INTEGER NOT NULL,
    FOREIGN KEY (sensor_id) REFERENCES sensors(id)
);

閾值定義表格

為瞭解決正規化問題，引入了一個新的表格來儲存閾值定義。這樣可以支援多種閾值型別，而不僅限於警告和錯誤。

CREATE TABLE thresholds (
    id INTEGER PRIMARY KEY,
    probe_id INTEGER NOT NULL,
    type TEXT NOT NULL,  -- 例如：warning, error
    value FLOAT NOT NULL,
    FOREIGN KEY (probe_id) REFERENCES probes(id)
);

探針與主機對映表格

探針與主機對映表格（Table 9-4）定義了哪些探針需要在哪些主機上執行。同時，它也允許為特定的主機設定閾值覆寫。

CREATE TABLE host_probe_mapping (
    id INTEGER PRIMARY KEY,
    probe_id INTEGER NOT NULL,
    host_id INTEGER NOT NULL,
    warning FLOAT,
    error FLOAT,
    FOREIGN KEY (probe_id) REFERENCES probes(id),
    FOREIGN KEY (host_id) REFERENCES hosts(id)
);

內容解密：

1. probes表格：儲存探針的基本資訊，如名稱和引數。sensor_id欄位參考sensors表格，實作了探針與感測器之間的關聯。
2. thresholds表格：用於儲存不同型別的閾值，支援更靈活的閾值管理。probe_id欄位確保每個閾值都與特定的探針相關聯。
3. host_probe_mapping表格：實作了探針與主機之間的對映，並允許為特定主機設定覆寫預設的閾值。

效能資料表格

效能資料表格（Table 9-5）儲存了監控代理傳回的讀數及其對應的時間戳。透過與探針與主機對映表格的關聯，可以取得相關的感測器和檢查引數資訊。

CREATE TABLE probe_readings (
    id INTEGER PRIMARY KEY,
    host_probe_id INTEGER NOT NULL,
    timestamp TEXT NOT NULL,
    probe_value FLOAT NOT NULL,
    ret_code INTEGER NOT NULL,
    FOREIGN KEY (host_probe_id) REFERENCES host_probe_mapping(id)
);

內容解密：

• host_probe_id欄位參考host_probe_mapping表格，提供執行探針的主機及探針相關資訊。
• probe_value和ret_code欄位分別儲存了探針傳回值和感測器程式碼的傳回碼。

排程相關表格

排程資料包括兩個部分：排程資料和工單佇列。排程資料定義了探針執行的間隔，而工單佇列則用於存放待執行的探針指令。

排程表格

排程表格（Table 9-6）儲存了靜態的排程資訊，包括探針執行的間隔。

CREATE TABLE probe_scheduling (
    id INTEGER PRIMARY KEY,
    host_probe_id INTEGER NOT NULL,
    probe_interval INTEGER NOT NULL,
    FOREIGN KEY (host_probe_id) REFERENCES host_probe_mapping(id)
);

工單佇列表格

工單佇列表格（Table 9-7）存放了待執行的探針指令，排程器或其它程式會填充此表格，而分派器程式則會讀取並處理這些指令。

CREATE TABLE ticket_queue (
    id INTEGER PRIMARY KEY,
    host_probe_id INTEGER NOT NULL,
    status TEXT NOT NULL,  -- 例如：pending, dispatched
    FOREIGN KEY (host_probe_id) REFERENCES host_probe_mapping(id)
);

內容解密：

1. probe_scheduling表格：定義了探針執行的頻率，確保監控系統能夠按照設定的間隔收集效能資料。
2. ticket_queue表格：作為動態資料表，用於存放待執行的指令。狀態列位用於標記指令的處理狀態，防止重複執行。