CCF 資料收集：內部部署

開始進行本地資料收集

本地資料模型

CCF CLI 使用預定義模型接收本地資料。該模型規定了所需資料的類型、內容和格式，以促進正確且準確的資料匯入和操作。您可以在CCF 文件的內部部署部分查看目前的自訂資料模型以及方法編寫。資料模型包含許多常見字段，例如 CPU 核心、記憶體以及特定機器位於世界上的位置。我們將繼續詳細介紹這些內容，但請記住，我們需要每個端點的所有這些數據才能提供準確的估計值。

資料來源

您的組織很可能包含多個端點資料的來源。從 Active Directory 中的電腦帳戶到防毒或系統修補工具等工具中儲存的系統資訊；儲存大量資料。您將在這些地方尋找目標端點並從這些來源中提取相關資料以填充本地資料模型。

端點資料也可能來自一些不太可能的地方。如果您發現自己在搜尋端點資料時迷失了方向，請考慮以下工具列表，看看您的 IT 部門是否擁有以下工具之一：

• 防毒套件
• 漏洞管理套件
• CMDB 應用程式（庫存管理）
• 配置管理套件
  • 木偶
  • 廚師
  • SCCM
  • MEM
• 系統監控套件
  • 納吉奧斯
  • 仙人掌
  • 格拉法納
    • 節點導出器
    • 電訊報
    • 普羅米修斯資料庫

這樣的例子不 rcs資料庫 勝枚舉。目前有無數工具可供組織執行與端點管理、監控和保護相關的各種任務。此類工具的美妙之處在於它們也依賴與端點相關的大量資料。防毒工具需要知道機器是否已在線並與管理控制台通訊以獲取更新和狀態資訊。監控工具完全依賴其名稱所暗示的功能—監控端點。 CMDB 工具直接負責端點和庫存管理。許多 IT 部門認為 CMDB 工具是端點和庫存真相的來源。這裡的數據可能非常準確。

注意：請記住存取這些資料來源所需的權限，並確保您遵循公司在檢索和儲存此資料方面的最佳實踐。如果可能，請始終與資料來源所有者合作，以確保您不僅獲得最佳數據，而且處理數據的方式不會使您的公司面臨不必要的風險或安全事件。
資料來源是開始追蹤和評估企業環境影響之旅中最重要的部分。在開始時，發揮創意並利用與組織內各部門的現有合作夥伴關係來找到這些不太可能的資料來源。繼續依靠本地資料模型將資料來源與所需欄位進行配對。

選擇資料來源時，請注意資 致電中東您需要了解的切 料集的大小以及持續擷取資料的能力。間歇性或正常運作時間不可靠的服務不是優選的來源。具有無法過濾或壓縮的大型資料集的資料來源可能難以攝取或成本高昂。如果可能，請始終嘗試選擇已公開 API 的資料來源。從長遠來看，這將使自動化和安排資料收集變得更加簡單。如果 API 根本不可能，請嘗試使用可以產生包含所需資料的排程報告的工具。如果可能，請選擇 CSV、JSON、XML 輸出，您可以在資料收集和預存程序中輕鬆使用它們。我們將在收集本地數據部分介紹這一點。

在我們繼續討論收集和儲存此資料的方式和方法之前，請記住，本地資料模型中的某些欄位將隨著時間的推移而收集。稍後我們將更詳細地討論這些欄位。只需了解您選擇的資料來源不一定必須包含此資料。您也許能夠透過良好的自動化來產生數據，並從資料來源提供的其他資訊中安排資料檢索。

• 每日正常運轉時間
• 每周正常運作時間
• 每月正常運作時間
• 年度正常運轉時間

一旦您有了可用的資料來源，您將使用該資料來計算上述欄位。

資料收集和儲存技術

例如，假設您選擇了 AntiVirus 作為初始 韓國數據 資料來源。該工具包含本地資料模型所需的所有基本信息，並且具有強大的 REST API，可用於獲取資料。我們該去哪裡？讓我們來看看基本的工作流程圖。

這是表示收集和儲存資料時要採取的操作的最簡單的方法。雖然很容易視覺化，但實現此目標的方法可以從非常簡單到非常複雜，具體取決於您將擁有的資料量、您持有資料的時間長度以及任何安全或風險考慮因素。與資料來源一樣，有無數的工具和技術可以用來執行這些操作。

因為我們需要隨著時間的推移捕捉這些數據，所以選擇一種能夠準確、及時地規劃運行的數據收集技術。能夠每天或每小時收集數據將大大提高數據的準確性。

AWS Glue 與 AWS S3 資料湖

這是一種出色的雲端原生方法，可以輕鬆捕捉大量到極大量的資料。 AWS Glue 提供規劃和基於間隔的運行初始化等功能，而 S3 Datalake 可以處理極大量的資料。

此外，您還可以將其與 AWS Athena、RDS 和 Lambda 等 AWS 功能配對，使資料轉換和檢索變得簡單、有效且準確。

Django 與 Django-Rest-Framework、Celery-Beat 和PostgreSQL

如果您有可用的 Python 開發人員並且對具有成本效益或免費的解決方案感興趣；開源可能是您的最佳選擇。 Django 是一個基於「視圖模型」策略建立的極其強大的 Web 框架。它包含大量內建功能，包括「CRUD」功能，使建立和使用資料庫模型變得輕而易舉。

透過新增 2 個附加插件，它可以提供您需要的所有資料儲存和檢索功能。 Django-Rest-Framework 讓在 Django 中建立 API 變得簡單，有助於擷取儲存的資料。 Celery-Beat 是一個資料庫支援的任務調度程序，可以讓調度準確、及時的資料收集變得輕而易舉。

Django 在 Docker 和 Kubernetes 等容器化環境中也能運作得非常好。

本地資料 – 資料模型

您將收集的大部分數據都非常簡單。機器名稱、CPU 類型和記憶體數量可能很容易獲得。然而，有些數據需要特別考慮。讓我們簡單探討一下這些內容。

特殊資料模型字段

收集資料時需要特別注意以下資料點。請注意確保將這些注意事項納入資料模型中，以確保資料收集過程準確。

• 機器類型：
  • 不同的機器類型會產生不同的電力負載。用於計算不同類型機器的功耗的公式將根據類型而有所不同。如果您的資料來源包含類型，則應確保其格式為「伺服器」、「筆記型電腦」或「桌上型電腦」。無法提供此資訊將影響用電量計算的準確性。
• CPU利用率：
  • 您的資料收集工具可能無法提供此資訊。如果是這種情況，您最好的選擇是做出最佳情況估計。
• [每日、每週、每月、每年]正常運作時間：
  • 這4個領域是最重要的，也需要良好的資料收集過程。使用資料來源時，您需要使用正常運作時間資料（如果可用）為這些欄位提供增量總計。無法提供這些數據將導致碳影響估算非常不準確。

收集本地數據

一旦確定了合適的資料來源和方法，您現在就可以開始收集和儲存本地資料的過程。為了撰寫本文，我們將使用「防毒軟體」作為我們的資料來源。

資料來源 -防毒

我們的資料來源是一個防毒套件，它提供涵蓋所有基本來源的最新端點統計資料。

• cpu描述
• 記憶
• 機器類型（伺服器、筆記型電腦、桌上型電腦）
• 機器名稱

除了基礎知識之外，資料來源還包含一些附加數據，這些數據將在以後使用。

• 最後一次代理通信
  • 這告訴我們端點上次在線的時間。它將有助於確定係統正常運作時間。
• 代理公共IP
  • 了解端點所在的國家和地區有助於我們計算碳強度。公共 IP 可用於識別與代理程式關聯的地理位置數據，以將其付諸實踐。

收集數據

為了讓我們的事情變得更容易，我們的資料來源還提供了一個 REST API，我們可以在其中即時收集資料。如果您的資料來源不提供 API，請嘗試取得 CSV、XML 或 JSON 格式的定期報告，您可以使用這些報告來取代發出 API 請求。

根據您選擇的資料收集和儲存方法，很可能需要一些編碼。尋求開發人員或資料工程師的幫助來幫助您可靠地收集和儲存這些資料將非常有益。能夠從 API 檢索和解析資料、使用 S3 或簡單資料庫以及建立基本自動化將在整個過程中派上用場。記住上面的插圖。

您需要確保無論選擇哪種資料收集方法，都能夠按照設定的時間間隔執行收集。追蹤機器的正常運作時間對於在這裡取得成功至關重要。

計算 upTime小時數

本機資料模型中的許多欄位表示代理程式在一段時間內的正常運作時間。當您收集有關端點的正常運行時間資訊時，您將需要填入這些欄位並遞增每個單獨的計數器。

每個正常運轉時間計數器代表一個歷史時間段。每日、每週、每年以及可能 30、60、90 天的增量。這些欄位可能從第一天起就出現在您的資料來源中，但也許您可能需要建立和計算這些欄位。

上圖中是單一端點的資料收集事件的過於簡化的視圖。例如，假設您要遞增的計數器是dailyUptime計數器。當有關端點的資料傳入時，確定該端點在過去 1 小時內一直在線上。要增加每日計數器，我們首先需要檢查計數器上次重設的時間戳記。如果計數器不到 24 小時，那麼我們可以將計數器增加 1 小時。如果超過 24 小時，我們應該將計數器重設為 1。

這是一個偽代碼的快速範例，用於說明其中的幾個用例。

增加每日正常運轉時間計數器

增加 30 天正常運轉時間計數器

同樣的原則適用於與正常運作時間相關的所有其他值。WeeklyUptime、MonthlyUptime和YearlyUptime都可以這樣計算。您也可以根據需要添加其他正常運行時間計數器；但是，請確保存在本機資料模型中所需的正常運行時間欄位。

在建立初始時間戳記時，請始終記住從機器首次新增至資料模型的那一刻開始時間戳記。不建議建立任意初始時間戳，因為這可能會導致正常運行時間欄位非常不準確。

結論

為修補、庫存和生命週期管理等活動收集本地資料已經在 IT 組織中進行了很長時間。為了實現這些目標，我們在工具的開發和部署方面投入了大量的工作。隨著世界越來越傾向於實施綠色舉措，以更好地塑造其技術未來，計算和報告我們的基礎設施對環境影響的能力也在增強。

即使您可能沒有適合目的的工具來收集本地數據，但這並不意味著您仍然無法取得所需的數據。這些數據很可能已經存在於您的組織已使用的許多其他工具中。本文中使用的防毒軟體顯然不適用於此任務，但經過一些嘗試和錯誤，它可以準確地完成收集所有必要數據所需的操作。要有創造力並保持開放的心態。數據無所不在。