CCF 資料收集:內部部署

開始為本地資源收集資料的旅程乍看之下似乎是一項不可能的任務。我實際需要什麼數據?您有合適的工具嗎?您需要哪些利害關係人,這需要多長時間?您將資料儲存在哪裡?最重要的是,一旦確定了可用的工具,如何取得數據?我們將在下面介紹所有這些內容,但首先要知道,儘管您最初感到恐懼;端點資料存在於無數工具中。只要有一點創造力和專業知識,您應該可以輕鬆識別、檢索和儲存要在 CCF 資料收集 儀表板中使用的端點資料。

開始進行本地資料收集

本地資料模型

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

資料來源

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

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

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

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

rcs資料庫

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

選擇資料來源時,請注意資 致電中東您需要了解的切 料集的大小以及持續擷取資料的能力。間歇性或正常運作時間不可靠的服務不是優選的來源。具有無法過濾或壓縮的大型資料集的資料來源可能難以攝取或成本高昂。如果可能,請始終嘗試選擇已公開 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 天正常運轉時間計數器

 

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

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

結論

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

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

標籤:

  • 電子藝術
  • 數據
  • 本地部署

在虛擬機器中運行和部署 CCF

·閱讀 11 分鐘
阿里克·史密斯

資深軟體工程師 

自從推出雲端碳足跡 (CCF) 以來,我們的團隊始終致力於維持和開發該工具的使用方式及其部署選項的靈活性。由於跨組織的基礎設施種類繁多,我們努力在支援盡可能多的開箱即用環境的同時保留您可能需要的自訂選項。

對於將 CCF 實例作為概念驗證以及內部生產環境進行試點,最受歡迎的選擇之一是在虛擬機器中執行 CCF。畢竟,這是一種讓您熟悉 CCF 的好方法,無需對本地電腦產生額外的依賴,不會佔用任何資源,也不會啟用擴展到本地電腦之外的始終在線服務的選項。或者,您可能希望透過自訂或自動化 CCF 如何適應您的用例來發揮創意。例如,也許您可能想要設定一個雲端函數來自動取得最近每天、每週或每月的雲端估計值?或者您可能想要一個完全可存取的 CCF API 供組織或團隊的成員查詢?如果這些好處中的任何一個聽起來很有吸引力,那麼 VM 選項可能適合您,而且您來對地方了!

虛擬機器在不同的雲端供應商平台上有多種形狀和大小,包括 AWS EC2、Google 雲端運算引擎和 Azure 虛擬機器服務。在本文中,我們將重點放在如何建立在 AWS EC2 執行個體上執行的 CCF 應用程式。但是,根據您機器選擇的作業系統或發行版,步驟應該相對相同!

建立您的 EC2實例

CCF 的核心是一個 Node 應用程序,為其 API 運行 Express.JS,為其客戶端運行 React。因此,一旦您為應用程式的一個端點設定了環境,您就可以在同一台電腦上執行 CCF 的 API、CLI 和用戶端的實例,並根據需要在它們之間進行切換。在我們這樣做之前,讓我們創建我們的機器並設定我們的環境。

首先,我們假設您已經具備以下條件:

  • 具有建立和管理 EC2 執行個體權限的現有 AWS 帳戶
  • 遵循為雲端供應商設定帳單資料的步驟(即 AWS 步驟 1-3)
  • 基本熟悉 AWS 主控台的導航

讓我們導航到 EC2 儀表板並選擇使用閃亮的「啟動執行個體」按鈕啟動新執行個體的選項:

從現在起,我們將為新機器選擇配置選項。雖然免費套餐可能很誘人,但我們將選擇 t2.medium。我發現在較小的實例(例如 t2.micro)上,有限的硬體有時會在安裝節點模組或運行應用程式時導致問題。所以我們可以使用額外的“魅力”。但是,為了您自己的實例,請考慮以下事項:

  • 如果您期望進行大量估計,請考慮具有更高記憶體和運算能力的更大實例。
  • 如果您打算在同一台電腦上執行MongoDB 實例並儲存大量估計,請考慮增加實例的儲存容量。
  • 如果成本和效率是首要考慮因素,請考慮選擇 ARM 實例選項,因為此後您將無法從非 ARM 實例遷移。
  • 運行 EC2 執行個體會產生成本!因此,請確保在使用完實例後停止/刪除實例,並選擇適合您預算的功能強大的實例。

您可能還注意到,我們將使用 Ubuntu 映像作為我們的作業系統 – 一種流行且廣泛接受的發行版,您可以將其與任何 VM 主機一起使用。歡迎您選擇不同的基於 Linux 的作業系統,例如對於 EC2 實例,選擇 Amazon Linux。 Amazon Linux 是針對在 AWS 中運作而最佳化的 Linux 發行版。它還針對運行大多數基於 Linux 的軟體進行了最佳化,使您遵循的步驟幾乎相同。為了使本教學對其他雲端虛擬機服務更加友好,我們將堅持使用 Ubuntu。

在建立金鑰對(透過 SSH 用戶端連線所需)和選擇安全群組方面做出一些最終決定後,我們將點擊更閃亮的「啟動實例」按鈕。短暫等待後,您應該會看到一條通知,表示實例已建立並正在運行。那麼讓我們連接到它吧!

附註:如果您更熟悉雲端提供者 CLI或其他配置資源的方法,也可以使用這些方法複製這些步驟。

設定您的 CCF實例

使用您的首選方法連接到您的實例 – 無論是在雲端提供者控制台中還是透過 SSH 透過本地端。進入後,我們需要配置 NPM 和 Node,以便我們的伺服器可以支援 CCF 的程式碼。

安裝Node.JS

我們將按照官方建議的步驟在EC2實例上設定 Node.JS。今後,我們將依靠 NVM 來使這個過程變得簡單!NVM將為我們管理 Node 版本,使遷移或降級變得更加容易。

然後我們需要透過執行以下命令來啟動 NVM:

您可以透過運行來驗證它是否處於活動狀態nvm -v,您應該在其中看到 或類似的輸出0.39.5

CCF 需要 NodeJS 16 或更高版本。雖然我更喜歡 18,因為它是當前的 LTS 版本,但您需要運行以下命令 – 將數字替換為您希望安裝的版本

注意:請務必檢查您的映像支援的最新版本相容性。例如,在撰寫本文時,Amazon Linux 2 不支援 Node 18。

NVM 也會通知您它將目前版本設定為預設版本。當您需要切換節點版本或由於某種原因停用節點時,這非常有用,因為您可以使用它nvm use –default來重新啟用它。您可以透過執行來驗證 Node 是否已成功安裝node -v,您應該在其中看到您安裝的版本的輸出。

安裝紗線

在安裝 Node 的同時也會自動安裝 npm,CCF 使用Yarn作為其套件管理器。幸運的是,Node 16 及更高版本由於包含corepack使其安裝起來超級容易。

要安裝 Yarn,我們只需使用以下命令啟用 corepack:

corepack enable

透過一點魔法,您現在可以使用yarn -v它來驗證您的伺服器中是否已安裝並啟用了yarn。您將看到版本 1(yarn classic)已啟用。如果您一直在閱讀 CCF 文檔,您可能會注意到它需要 Yarn 3。

現在是有趣的部分!

安裝CCF

安裝 CCF 的方法有多種,如“入門”部分所述。雖然您可以克隆應用程式並在其所有軟體包和最新功能可用後立即獲得對其的完全訪問權限,但我們將使用“創建應用程式”選項作為更穩定和更簡單的解決方案。

首先,我們將執行 create-app 命令,並附加一個標誌以表示我們希望跳過該yarn install步驟。如果我們希望使用引導安裝過程連接數據,這為我們提供了靈活性,最終將為我們完成安裝步驟:

npx @cloud-carbon-footprint/create-app --skip-install

系統會要求您安裝該create-app軟體包的最新版本,您可以回答「是」。

 

當提示輸入名稱時,請隨意選擇您希望應用程式使用的名稱。在這個例子中,我們將去my-ccf-app.請注意,這也將是在其中建立應用程式的目錄的名稱。

之後,您將看到該腳本負責建立檔案並將它們移至以您的應用程式命名的目錄中。您的應用程式將成功創建!

用於cd my-ccf-app切換到您的應用程式的目錄。您應該在目錄中看到以下內容:

lerna.json  package.json  packages  tsconfig.json

注意:如果您在目錄中再次運行yarn -v,您會看到版本已像魔術一樣自動更新至 3.1.1。 ✨

此時,您可以透過.env在您的目錄packages/apipackages/cli基於.env.template相同目錄中的檔案的目錄中手動建立檔案來連接資料。請務必查看有關如何連接所選雲端提供者的資料的文件:

  • AWS
  • Google雲
  • 天藍色

或者,您可以使用上面提到的引導安裝方法來運行一個友好的 CLI 程序,該程序將引導您完成設定憑證並.env為您建立文件!

如果您不想完全連接數據,也可以使用模擬數據運行並繼續下一步。

運行您的應用程式

在遵循您選擇的設定方法之後,讓我們透過執行yarn install.一旦依賴項安裝完成,我們就可以啟動我們的應用程式了!

現在您可以yarn start同時啟動客戶端(React 儀表板)和 API(Express 應用程式)。

  • 如果執行用戶端或使用類比數據,您的 CCF 儀表板將在執行個體的連接埠 3000 上可用。您可以透過導覽至執行個體的公共 IP,然後導覽至對應的連接埠來查看儀表板。
    • 請注意,您需要設定安全或網路設定才能使該連接埠可用
  • 您也可以使用yarn start-api它來僅執行 API。您可以透過向實例的連接埠 4000 上的端點之一發出請求來驗證 API 是否正在執行。
    • 例如,嘗試在另一個終端實例中執行以下命令:
    • 請注意,如果嘗試在執行個體外部發出請求,您將需要設定安全或網路設定以使此連接埠可用。
  • 您也可以使用yarnstart-cli來運行CLI並直接在終端機中請求估計。

恭喜!現在您已成功建立在虛擬機器中執行的 CCF 應用程式。

您可能會注意到,如果退出 SSH 或終端會話,正在運行的進程將不會持續存在。在這種情況下,您可以使用Screen等工具建立不間斷的終端會話來執行您的應用程式。

這將創建一個名為“ccf”的新螢幕會話。從這裡,您可以運行命令之一來運行您的應用程序,然後使用命令鍵從會話中分離。會話將保留在後台,您的 CCF 應用程式將繼續運行!

您始終可以透過在終端機中輸入來重新連線到會話。

如果您更習慣並且不喜歡在背景執行終端會話的想法,您也可以建立一個檔案來將應用程式作為後台服務運行。

現在怎麼辦?

現在,您在基於雲端的虛擬機器上擁有始終運行的 CCF 實例,您現在可以繼續探索雲端中所有服務的即時和歷史估計。如果您想探索增強 CCF 應用程式的其他方法,請考慮以下事項:

  • 使用 Docker 運行 CCF 應用程式
  • 建立一個 cron 觸發的雲函數來自動取得新的估計
  • 配置 MongoDB 實例以保存新的和歷史的估計數據
  • 使用 CLI 應用程式將資料植入到為您的實例配置的快取選項中
  • 為您的團隊或組織建立內部儀表板以查看估算數據

希望您發現本演練很有幫助,並認識到這只是您的雲碳足跡之旅的開始,並採取措施幫助創建更綠色的雲!如需更多演練和技術深入探討,請務必繼續關注CCF 部落格並在我們的討論頁面上分享您的經驗!

返回頂端