星期四, 12月 25, 2025

Gemini CLI extension - observability 小記

Gemini CLI extension - observability 小記



OS: macOS 14.3

Gemini: 0.22.2


今天來寫另外一個 Gemini CLI extension - observability


主要是可以使用自然語言來查詢觀測性的資訊

  • Logging

  • Monitoring

  • Trace

  • Error Reporting


安裝方式如前一篇文章所提直接使用 gemini extension install 就可以


% gemini  extensions  install https://github.com/gemini-cli-extensions/observability


觀察已經安裝的 extension

% gemini  extension  list | grep  '('


✓ nanobanana (1.0.10)

 Source: https://github.com/gemini-cli-extensions/nanobanana (Type: github-release)

 Enabled (User): true

 Enabled (Workspace): true

✓ observability (0.1.0)

 Source: https://github.com/gemini-cli-extensions/observability (Type: git)

 Enabled (User): true

 Enabled (Workspace): true


啟動 gemini


來進行以下的測試


> 請幫我確認我目前所有的專案 Log 保留的期限 /observability


✦ 根據 Observability MCP 的查詢結果,您所有專案的 Log 保留期限設定皆一致,均為預設值:


  所有專案的設定如下:



目前所有專案都採用標準設定。如果您需要延長特定專案的  _Default bucket 保留時間(例如延長至 90 天或 1 年),我可以協助您進行調整。


> 請列出我所有專案的 Alert 規則 /observability



> 請列出我所有專案 最近 14 天被觸發 Alert 使用 observability.list_alerts 工具



> 請幫我分析 sakana-2024-gcp 專案 gcs 的使用情形, 使用 Observability MCP 的 list_time_series 工具來讀取


✦ sakana-2024-gcp 專案 Cloud Storage (GCS) 使用情形分析


  根據 list_time_series 的查詢結果,分析如下:


  1. 儲存桶 (Bucket) 資訊

   * Bucket 名稱: run-sources-sakana-2024-gcp-asia-east1

   * 地區: asia-east1 (台灣)

   * 儲存級別: REGIONAL


  2. 數據概況 (最近 24 小時)

   * 儲存總量 (Total Bytes): 3,097 Bytes (約 3 KB)

       * 數據非常穩定,從 2025-12-25 07:20 到 11:25 這段期間內完全沒有變化。

   * 物件總數 (Object Count): 1 個

       * 同樣保持不變,顯示目前該 Bucket 內只有一個檔案。


  3. 分析結論

   * 極低使用量: 這個專案的 GCS 使用量非常低,僅存放了一個極小的檔案 (3 KB)。

   * 用途推測: 根據 Bucket 名稱 run-sources-... 判斷,這應該是 Cloud Run 部署時自動產生的暫存

     Bucket,用於存放原始碼或建置映像檔的相關資訊。

   * 無活躍活動: 在過去這段時間內沒有任何新增或刪除檔案的動作。


  建議: 

  由於使用量極低且看起來像是系統自動生成的,目前不需要特別關注儲存成本或清理工作。如果您確定不再需要部署相關服務,可以考慮手動檢查並清空

  該 Bucket,但目前的 3KB 佔用對成本幾乎沒有影響。


> 請幫我分析 sakana-2024-gcp 專案最近 90 天 gce 的使用情形, 使用 Observability MCP 的 list_time_series 工具來讀取


✦ sakana-2024-gcp 專案 Compute Engine (GCE) 最近 90 天使用情形分析


  根據 list_time_series 的 90 天查詢結果,我們終於發現了該專案的運行活動紀錄。


  1. 實例資訊

   * 實例名稱 (Instance Name): test20251007-vscode

   * 實例 ID: 1128478565315759728

   * 地區 (Zone): asia-east1-c (台灣)


  2. 運行時間分析

   * 最後活躍時間: 2025-10-29 15:07 UTC。

   * 活動範圍: 數據顯示該實例在 2025-10-29 當天有密集的 CPU 數據,從 06:59 持續到 15:07。

   * CPU 使用率:

       * 大部分時間維持在 0.6% ~ 1.2% 之間(極低負載)。

       * 在最後一筆紀錄 (15:07) 有小幅上升至 4.4%。


  3. 結論與分析

   * 短暫運行: 雖然我們查詢了 90 天,但該專案僅在 10 月底 有短暫的運作紀錄。

   * 用途推測: 實例名稱含 vscode,推測這是一台用於開發或測試用的 VM (例如 Remote SSH 進行程式碼編輯)。

   * 目前狀態: 

       * 在 2025-10-29 15:07 之後就再也沒有任何數據回傳。

       * 這代表該實例自 10 月底以後就一直處於 停止 (Stopped) 或 已刪除 (Deleted) 的狀態。


> 請列出目前專案過去 30 天內所有不重複的 GCE 實例名稱及 ID。為了確保不遺漏任何實例,請在查詢時使用較大的聚合時間區間。



> 請分析目前專案 過去 30 天內 GCE 實例的生命週期。請幫我找出所有出現過的實例 ID,不需回傳每分鐘的詳細數據,只要確保所有 Series 都有被列出即可。


真是很方便的工具, 又前進一步


~ enjoy it



References


星期日, 12月 21, 2025

GCP VM Manager 小記

GCP VM Manager 小記



最近跟同事討論 CVE 檢查與升級, 就想說來寫這一篇

今天來實作 GCP VM Manager 

  • 以下方式是針對 無組織的單一專案進行設定


登入 GCP Console


首先要啟用 API 


點選 APIs & Services -- > 點選 Library


搜尋 VM Manager


這個時候可以看到 VM Manager ( OS Config API )



點選 VM Manager ( OS Config API) 的 Enable 啟用 API



接下來要設定 中繼資料 (Metadata)

前往 Compute Engine > 設定 (Settings) 下面的 中繼資料 (Metadata)

點選 Edit



點選 Add item



輸入以下 2 組 Key - Value

  • enable-osconfig: TRUE

  • enable-guest-attributes: TRUE


點選 Save 儲存


確認相關資訊


接下來可以建立 GCE Instance


建立後可以觀察 VM Manager 的 Patch



在 Dashboard 可以看到目前 VM 的數量 以及不同 OS 的分布狀況


點選 VM Instances 也可以同步看到 OS 目前的 Status



這邊可以觀察到目前 Ubuntu 24.04 是 Up-to-date, Oracle Linux 則是 Other updates available


點選 Oracle Linux instance 觀察資訊


這邊可以觀察到 有 267 套件可以升級, 然後也有 CVE 欄位



在 OS 內同步比對



接下來嘗試在VM instance details 的視窗 升級套件


勾選其中一個套件 (這邊以 at 套件為例) -- > 點選 Apply update


這個時候就會被轉到 Create patch job 視窗

然後是以手動選取 VM 的方式, 也已經選取剛剛的 VM

點選 Next


輸入 Patch Job 名稱

點選 Next



  • 這個時候可以觀察到 YUM 選項, 自動被選取到 Select update 欄位, 然後剛剛勾選的套件也被填入



接下來決定這個 Job 執行方式

點選 Next


  • 這邊預設是馬上指行, 也可以排定自訂的時間


接下來是 Rollout options

因爲是單台的實驗, 沒有單一 zone / 多 zone 的考量與置換百分比與 VM 數量設置需求

點選 Next


Advanced options 就按照預設

點選 Deploy



也可以同步觀察如果是指令的方式該如何



接下來會顯示 Job 執行畫面



執行的結果可以在 Jobs run 分頁觀察



  • 可以點進 Job 看詳細資訊與 log


這個時候再次觀察 VM instance details 視窗與 OS 內觀察




  • 這邊就會觀察到相關套件已經被更新


接下來嘗試在 Oracle Linux 進行套件更新

$sudo  dnf  update


在升級的過程, 也可以看到套件數是有同步的



升級完畢後, VM Manager 的 Patch 也會同步顯示狀態



寫一下目前的實作感想

  • VM Manager 可以反應目前的 OS patch 狀態

  • Patch 可透過 Job 定時/自訂時間去執行升級工作, 顯示上也可以看到 CVE 欄位



又前進一步


~ enjoy it