3個工具干掉Portainer全家桶

100MB內存換一套"瑞士軍刀"式管理后臺，這筆賬在樹莓派上算得過來。但當你的監控面板需要監控自己的監控面板時，事情就開始荒誕了。

這是作者用Docker托管工具的第180天。從Portainer+Prometheus+Grafana的"經典三件套"，到Dockhand+Beszel+Glance的"輕量組合"，他換掉的不僅是工具，還有對"功能堆疊"這件事的執念。

Portainer的100MB陷阱：省下的內存，花在哪兒了

Portainer的入門體驗堪稱完美。對于從Windows遷移過來的用戶，一個可視化界面能抵消80%的終端焦慮。100MB內存占用，換零命令行操作——這筆賬在賬面上很劃算。

但作者很快發現，這100MB買的是一把"瑞士軍刀"，而他只需要其中的螺絲刀功能。Portainer的UI把所有可能性都攤在桌面上：環境管理、用戶權限、堆棧編排、鏡像倉庫……

主儀表盤卻異常空曠：只顯示連接環境和幾個基礎指標。

這種"功能膨脹、信息收縮"的設計矛盾，在樹莓派Zero的屏幕上被放大到極致。作者形容自己的日常操作是"在菜單迷宮里找開關"——明明只想重啟一個容器，卻要經過三層導航。

更隱蔽的成本是認知負荷。Portainer的權限系統和多環境管理對企業用戶是剛需，對個人用戶則是需要刻意忽略的噪音。作者用了"extensively"（ extensively ）這個詞描述自己的使用時長，卻也在同一句話里承認：終端交互能免則免。

這種依賴是有代價的。當Prometheus和Grafana被引入以彌補Portainer的監控盲區時，整個棧的復雜度已經偏離了"輕量自托管"的初衷。

監控套娃：當Grafana需要被監控

Prometheus和Grafana的加入是順理成章的。Portainer不碰硬件指標，而樹莓派的CPU溫度和內存壓力是真實存在的焦慮。

但這套組合很快暴露了架構層面的尷尬。Prometheus負責抓取數據，Grafana負責可視化，兩者都需要獨立配置、獨立維護、獨立更新。作者沒有明說，但"after spending a good amount of time"（花了相當長時間）這個表述暗示了學習曲線的陡峭。

更荒誕的是資源循環：監控工具本身消耗的資源，也需要被納入監控。

在樹莓派Zero的512MB內存里，這套"監控監控者"的架構顯得奢侈。作者沒有給出具體數字，但Docker容器隔離的優勢——"one hiccup results in a total system halt"（一個故障導致整個系統停擺）——在這里成了反諷：任何一個組件的內存泄漏，都會觸發連鎖反應。

這種脆弱性在容器化之前更嚴重。作者提到早期"running self-hosted tools individually"（單獨運行自托管工具）的經歷，一個進程崩潰就能凍結整個系統。Docker的隔離機制解決了這個問題，卻引入了新問題：工具數量的膨脹。

到這個階段，作者的棧已經包含：Portainer（容器管理）+ Prometheus（數據采集）+ Grafana（可視化）。三個工具，三個界面，三套配置邏輯。

新三件套：Dockhand的"信息密度"實驗

轉向Dockhand的動機很具體：UI的信息密度。

作者對比了兩個儀表盤。Portainer的主頁是"connected environment with a few other details"（連接環境和少量其他細節）——一種典型的企業級設計，假設用戶會通過導航深入各功能模塊。Dockhand則選擇把關鍵信息鋪開在首屏：容器狀態、資源占用、快速操作入口。

這種設計哲學的差異，本質是"用戶路徑"的預設不同。

Portainer假設用戶會頻繁切換功能上下文，所以保留了完整的導航架構。Dockhand假設用戶的核心訴求是"看一眼，操作一下，離開"——這對個人用戶更接近真實場景。

作者用"presentable manner that's easy on my eyes"（賞心悅目的呈現方式）描述這種體驗。這個評價里藏著對前者的疲憊：不是功能不夠，是獲取信息的摩擦太大。

Dockhand的替代不是功能對等的替換，而是需求的重聚焦。作者坦承自己"want to keep terminal interaction to a minimum"（希望盡量減少終端交互），但Dockhand的GUI滿足這個需求的方式更克制——它不假裝自己是一個企業級平臺。

Beszel和Glance：監控的"去中臺化"

替換Prometheus+Grafana的組合，作者選擇了Beszel和Glance。原文沒有展開這兩個工具的具體分工，但從"fulfills all of my container management, monitoring, and dashboard needs"（滿足我所有的容器管理、監控和儀表盤需求）這句話可以推斷：Beszel承接了監控職能，Glance負責儀表盤聚合。

這種分工本身就有趣。Prometheus+Grafana的模式是"采集-存儲-可視化"的垂直整合，Beszel+Glance則可能是更扁平的協作。

關鍵差異可能是部署復雜度。

Prometheus的配置涉及抓取目標、存儲策略、告警規則，Grafana則需要數據源對接和面板設計。對于只想看"CPU是不是又飆了"的個人用戶，這套流程像用Photoshop修自拍。

作者用"fills huge gaps existing in the previous stack"（填補了之前棧的巨大空白）描述這次遷移的收益。這些"gap"沒有被具體列舉，但結合上下文可以推測：配置負擔、界面割裂、資源開銷是主要痛點。

新三件套的總資源占用沒有明確數字，但Dockhand+Beszel+Glance的組合暗示了輕量化的方向。在樹莓派Zero的約束下，每一個MB的節省都是實質性的。

從"能用"到"剛好夠用"：自托管的工具理性

整個遷移敘事的核心，不是技術優劣的評判，而是需求校準的過程。

Portainer+Prometheus+Grafana是社區驗證的"標準答案"，但這個答案假設用戶需要企業級功能的子集。作者的經歷證明，個人用戶的真實需求可能更窄：容器管理要直觀，監控要即時，儀表盤要聚合。

新三件套的價值，在于每個工具都拒絕過度承諾。

這種"剛好夠用"的哲學，與樹莓派Zero的硬件約束形成呼應。512MB內存和單核CPU是一面鏡子，照出每個工具的真實體積。作者沒有明說，但"shift"（遷移）這個動作的反復出現——從裸機到Docker，從Portainer到Dockhand——本身就是持續優化的證據。

一個值得注意的細節是作者的身份背景："As a Windows user, I've always been a GUI-inclined person"（作為Windows用戶，我一直偏好圖形界面）。這個自我定位解釋了為什么終端命令的減免如此重要，也解釋了為什么UI設計會成為決策的關鍵因素。

在Linux主導的自托管社區，這種偏好有時被視為"不夠硬核"。但作者的數據點提供了另一種視角：工具鏈的復雜度應該與用戶的技術背景匹配，而不是反向要求用戶適應工具。

180天后的棧：輕量是一種持續的選擇

作者沒有聲稱這是"最佳實踐"。原文的標題是"I replaced..."（我替換了……），一個個人陳述，而非教程或評測。

但這種個人化的敘事恰恰有價值。它記錄了真實決策的上下文：硬件約束、使用習慣、審美偏好。這些變量在標準化評測中通常被抹平，卻是實際選擇中的權重項。

Dockhand+Beszel+Glance的組合會維持多久？作者沒有預測。

但遷移本身的經驗已經被內化：從"功能最全"到"摩擦最小"，從"社區推薦"到"個人適配"。這種思維模式的轉變，可能比任何具體工具的選擇都更持久。

樹莓派Zero仍在運行。作者的最后一句是開放的："This trio fulfills all of my... needs"（這個 trio 滿足了我的所有需求）——一個現在時態的陳述，預留了未來的修正空間。

你的自托管棧里，有沒有一個"明明很好用，但就是用得累"的工具？