DevOps

此為 2025 iThome 鐵人賽系列文《被稱作Server Restart Engineer的我，也想了解如何實踐可觀測性工程》系列 可觀測性與監控 在講述可觀測性是什麼之前，我想先和各位來談談監控(Monitoring)。在《可觀測性工程：達成卓越營運》書中提到，當我們將監控和可觀測性混為一談時，就難以展開有意義的討論。 市面上常見的監控工具大多是被動的，擅長偵測和應對已知問題。這讓我想到剛開始工作時，曾經苦惱於該如何設置系統的告警閾值。那時候前輩給我的建議是：「經驗」。 意思是說，這些設定將會因為時間推移和事件發生不斷迭代修正。監控主要協助判斷系統健康狀況；而可觀測性則協助找出問題如何發生、解決未知問題。 近年來因為雲原生、微服務的興起，使得系統的互動變得更為複雜、除錯更加困難。這時候，只發現系統何時出錯已經遠遠不夠，人們逐漸希望系統能提供更多的上下文(Context)線索來排除故障，這也是為什麼可觀測性在近幾年已然成為顯學。 基於上述脈絡，在深入探討可觀測性之前，讓我們先了解目前業界常討論的幾個監控方法論。這些方法論能幫助我們建立系統性的監控思維，從「何時發生錯誤」逐步進展到「為何發生錯誤」。 今天將會和各位介紹兩種結構化的監控方法論，分別是： USE Method RED Method 這些方法論各有其適用場景，也可以互相搭配使用。接下來讓我們逐一了解它們的核心概念和實際應用。 USE Method The Utilization Saturation and Errors (USE Method) 是由 Brendan Gregg 所提出的系統效能監控方法論。他的核心理念就是這個方法論的名稱，「針對每個資源，去檢查使用率、飽和度和錯誤」。 更近一步地說，USE Method 專注於系統效能層面的監控，針對每個資源進行三個維度的檢查： Utilization（使用率）：資源平均忙碌的時間百分比。例如 CPU 使用率 85% 表示該 CPU 有 85% 的時間在處理工作 Saturation（飽和度）：資源承擔超過其處理能力的工作量程度。例如佇列(Queue)中等待被處理的任務數量 Errors（錯誤）：錯誤事件的數量。例如網路封包丟失的次數 USE Method 所說的資源主要指硬體資源，例如： CPU：處理器核心、執行緒 Memory：實體記憶體容量 Network interfaces：網路介面卡 Storage devices：硬碟、SSD Controllers：磁碟控制器、網路控制器 Interconnects：CPU 互連、記憶體匯流排 USE Method就是透過逐一檢查每個資源的 U.S.E 三個指標，讓工程師能夠快速定位系統瓶頸。只不過，系統本身可能存在多個效能問題，我們所發現的問題可能只是其中一個。這時候，我們就需要輔以其他方法來做更深入的分析，但 USE Method 仍能夠協助我們不斷迭代所有資源、持續發現問題。 RED Method The RED Method 是由 Tom Wilkie 所提出。不同於 USE Method 針對硬體資源的效能，RED Method 主要針對微服務，並以 Rate、Errors、Duration 三種指標來評估其性能。...

此為 2025 iThome 鐵人賽系列文《被稱作Server Restart Engineer的我，也想了解如何實踐可觀測性工程》系列 作為一名半路出家的工程師，去年因為工作需要，開始關注業界在實踐可觀測性工程的方法以及心得。從 observability 1.0、2.0 到現在 3.0 問世，再到許多工具的使用，例如 Metrics 的監控工具 Prometheus、使用 Elastic stack 收集 logs，最後因應微服務的興起，Traces 的監控也變成不可或缺的一部分。 本身有幸在擔任 SRE 的第一份工作中，就有從零到一建構一套監控系統的機會。但是，當時的我專注於學習工具的使用，認為把工具架設好、告警能成功發出，就算是實踐可觀測性工程了。一年過去，有了一個機會進入到新團隊，非常巧合地第一份任務就是建構一套適合團隊的監控系統。這次導入系統的心情，和一年前卻有很大的不同。 一年前的我，專注於工具的使用，卻忽略了可觀測性對於團隊的意義是什麼？它能怎麼幫助團隊快速定位問題？可觀測性之於 SRE 這個角色又是什麼？導入可觀測性將會有不小的成本花費，那麼它能為商業產品面帶來哪些好處與貢獻？一年後的我，在動手架構系統之前，開始思考這些問題。 近幾年不管是在研討會上或者社群中，也看到許多關於可觀測性工程的分享與討論，而我也從中吸收了許多的知識以及前輩的經驗。所以，今年想透過鐵人賽，來記錄我作為一名 SRE，重新學習可觀測性工程的點點滴滴。同時，也希望能透過這篇系列文與這個領域的前輩們互相交流，持續學習進步。 系列文架構 本系列將圍繞三大主題展開，希望能為正在思考如何為團隊建立可觀測性能力的工程師，以及想了解現代監控系統設計思維的 SRE，提供一些實用的思考框架和實踐經驗。 Observability 的概念與演進 從監控到可觀測性的演進脈絡 Observability 2.0 的資料觀點與技術需求 OpenTelemetry 設計理念與四大 signal 深度解析 Data Lakehouse 技術棧 從 Data Lake 到 Data Lakehouse 的技術演進 Apache Iceberg 架構設計與 Schema Evolution 欄式儲存、OLAP 引擎與查詢優化 雲端 Data Lakehouse 的實際部署 實踐與整合 OpenTelemetry Collector 的匯出與 ETL Pipeline 成本控制、效能優化與分層儲存 eBPF 與下世代可觀測性技術 每個主題都會結合實際案例和工具操作，避免純理論的討論。希望透過這三十天的分享，能與大家一起探索可觀測性工程的精髓，持續地討論與交流。

因為剛換了一份具有挑戰性的新工作，有好一陣子沒有發文了，雖然手上有幾個在進行的學習或者project，但進度都還沒到可以發表文章的程度。剛好最近工作上有一個之前沒碰過的問題，花了一些時間做處理，因此在這邊簡單地記錄一下。 問題敘述 在某個上班日的下午，筆者突然收到來自前端工程師的訊息，在跑CI process時GitLab Runner好像出了問題，導致pipeline fail了。經查詢後，發現是該Runner所在的VM disk 容量已達99.9%，已經不能夠再pull任何的image下來了。 GitLab Runner在執行CICD job時，會pull許多暫時的image來完成任務。在敝公司的每一台Runner中，都有一個固定於每日凌晨執行的cronjob來清除這些job產生出來的image、volume以及build cache等。因此在一開始，筆者懷疑cronjob是否根本沒有如期執行，從而往system log去查看，想確認cronjob執行的狀況。 不料，cronjob的確有在指定的時間執行。但僅從system log並沒有辦法得知更詳細的資訊——例如執行前的硬體容量多少？執行後多少？如果cronjob確實有做容量的清除，那麼硬碟滿載的情況下大都在一天中的何時發生？SRE該如何即時得知這些訊息？ 可以從以上資訊得知，Gitlab Runner所在的虛擬機缺乏監控設施，導致我們沒有辦法即時、有效地獲得系統狀況，進而做出適合的判斷與解決方案。因此，建立系統的可觀測性便是開始解決問題的第一步。 建立系統可觀測性：收集系統指標 敝公司的其他專案使用Prometheus + Grafana作為主要監控工具之一，又筆者只需要監控Linux中的系統指標，Prometheus已有現成的exporter可以做使用。綜合考量下，筆者在每一台Runner起了node_exporter的container以收集host-level的metrics，再使用Grafana去收集這些指標，繪製成可視化圖表。 在這邊提一個小題外話，筆者先前也有自己實作過host-level的metrics exporter，只不過當時單純地認為，如果使用container部署這個服務，那麼觀察的指標不就只限於container裡面了嗎？事實上，在萬物皆檔案(Everything is a file)的Linux當中，我們可以在/proc、/sys等目錄找到CPU、Memory、Disk相關的資訊，因此如果想觀察host的指標，就只需要把host的檔案目錄掛載到container中就可以了！ node_exporter的官方GitHub中就給了docker-compose.yaml的最佳範例： --- version: '3.8' services: node_exporter: image: quay.io/prometheus/node-exporter:latest container_name: node_exporter command: - '--path.rootfs=/host' network_mode: host pid: host restart: unless-stopped volumes: - '/:/host:ro,rslave' 在監控與告警皆架設完成後（這部分其實還有一些細碎的小東西可以談，例如告警的閾值怎麼設？要監控哪些指標？因為怕偏離重點，先暫且不提），筆者發現，在上班時間，每一台Runner的硬碟佔用量已達全部容量的70~80%，約是400多GB左右，那自然是撐不到在半夜執行的cronjob。此外，即便筆者手動執行完docker system prune -a -f這個可以清除unused container、image以及building cache的指令，也只清除了80G左右的容量。 基本上，每一台Runner所在的虛擬機就只有裝Runner這個應用程式，而且部署方式還是container，怎麼會佔用快要400GB的容量呢？ 最後，透過資深同事的幫助，以下列指令發現這龐大的體積來源來自於Docker下面的overlay2資料夾。光是這個資料夾就佔用了300多GB。 du -ch --max-depth=1 /datadrive/docker/ Docker v25後才修復的bug 難道是連docker system prune都沒有辦法清理overlay嗎？錯了，docker system prune這個指令就是拿來清除任何暫停的container、沒有在使用的network, images, build cache。之所以會沒辦法完全清除，是因為這是Docker v25以前的一個bug（剛好敝公司使用的版本是v24…）...

接下來即將進入的新公司與職位，會需要大量與GitLab CI接觸，為了做好準備，這幾天花了些時間自己跑了一遍CI流程。 GitLab CI Process 根據GitLab官方文件所述，所有CI/CD任務的執行都必須仰賴gitlab-ci.yml這個文件： To use GitLab CI/CD, you start with a .gitlab-ci.yml file at the root of your project. This file specifies the stages, jobs, and scripts to be executed during your CI/CD pipeline. 當定義好gitlab-ci.yml後，整個GitLab執行CI/CD的流程就會變成： 當指定分支的程式碼更新(commit or push or pull request) GitLab根據gitlab-ci.yml的定義，同步平行地觸發job (編按：在沒有任何其他設定之下，job都是平行執行的，除非另外在yml設定stage或者needs參數) GitLab server會去檢查每個job所指名的Runner，並把job分配給適當的Runner執行 Runner執行後的結果(CI Logs)會回傳到GitLab server，顯示於Pipeline上 在本篇文章中，會逐一介紹GitLab中Runner的種類，並且嘗試自定義Runner，並在上面運行單元測試。 GitLab Runner 當GitLab在運行gitlab-ci.yml中定義的Jobs時，實際上是在GitLab Runner上運作的。在這裡，Runner又能根據作用範圍分作三種類型，分別是： Shared Runner: 在該GitLab server下的所有group或者project都能夠使用。當我們建立project時，系統會自動產生Shared Runner，可以用來處理無標籤(tag)的任務。 Group Runner: 只有在該group下的所有project可以使用。 Specific Runner: 只有在特定的project下可以被使用。本次會使用Specific Runner作為實驗範例。 Executor 這時，Runner會根據我們選擇的Executor決定要採用何種方式與工作環境來完成CI Job。換言之，一個Runner可以被允許擁有多個executor，讓一個Job能運行在多種環境之中。...