這篇文章記錄如何在 Linux 環境中安裝 Prometheus、Grafana 與 Node Exporter，並透過 Grafana 匯入 Node Exporter Dashboard，建立一套基本的主機監控環境。
整體流程會先完成 Prometheus 的服務安裝，再安裝 Grafana 作為視覺化介面，接著部署 Node Exporter 讓 Prometheus 能夠收集主機 Metrics，最後在 Grafana 中設定資料來源並匯入 Dashboard。
在開發 Java 應用程式時，很多問題只有在特定環境才會出現。例如應用程式部署在遠端 Linux 主機、Docker container、Kubernetes Pod，或是某個測試環境中，單靠本機重現不一定能完整模擬實際狀況。這時候，遠端 Debug 就會變得很有用。
Java 本身提供 JDWP（Java Debug Wire Protocol）作為除錯器與 JVM 之間的溝通協議。只要啟動 Java 應用程式時開啟 JDWP debug port，VS Code 就可以透過 Debugger for Java 連線到該 JVM，像在本機除錯一樣設定中斷點、查看變數、逐步執行程式碼。
這篇文章會介紹如何使用 VS Code 連線到遠端 Java 應用程式進行 Debug，並說明 JDWP 啟動參數、VS Code launch.json 設定，以及常見連線問題的排查方式。
在 Spring Boot 應用程式中，Log 通常會先輸出到 Console 或檔案，方便開發與單機排查問題。不過當服務數量變多、部署環境變複雜後，單靠各主機上的 Log 檔案會讓查詢與追蹤變得不方便。這時可以透過 Logstash 接收 Spring Boot 輸出的結構化 Log，再寫入 Elasticsearch，讓後續查詢、分析與視覺化更加集中。
本文會記錄如何在 Linux 環境安裝 Logstash，設定 Logstash 將 TCP 收到的 JSON Log 寫入 Elasticsearch，最後再於 Spring Boot 的 logback 設定中加入 Logstash Appender，讓應用程式 Log 可以送進 Elasticsearch。
Jaeger 是一套開源的分散式追蹤系統，常用於觀察微服務架構中請求在不同服務之間的流向、耗時與錯誤位置。透過 Jaeger，可以把分散在多個服務中的 trace 資料集中起來，協助開發者分析效能瓶頸與服務之間的呼叫關係。
本文會示範如何在 Ubuntu 環境中安裝 Jaeger Tracing，並透過 systemd 將 Jaeger 設定成系統服務。這裡使用 Jaeger 的 OpenTelemetry Native Backend 設定，讓服務可以接收 OTLP gRPC 與 HTTP 格式的 trace 資料，並透過 Jaeger Query UI 查詢追蹤結果。
相較於只依賴應用程式日誌，Jaeger 可以用更直觀的方式呈現跨服務請求的完整脈絡：
這篇文章記錄如何在 Ubuntu 26.04 環境中安裝 Elasticsearch 與 Kibana，並完成基本的服務啟動、記憶體限制、設定檔調整，以及後續登入 Kibana 所需的密碼與 enrollment token 取得流程。
本文使用 Elastic 官方 APT 儲存庫安裝套件，版本來源為 packages/9.x/apt。安裝完成後，Elasticsearch 會啟用內建安全功能，因此後續需要透過重設密碼與建立 enrollment token 來完成 Kibana 的連線設定。
Chrome Extension 最迷人的地方，是它可以在不改動網站原始碼的情況下，替既有網頁補上一層新的操作體驗。這篇文章會以 coolpc-plus 這個專案為範例，拆解一個 Chrome Extension 如何在原價屋估價頁注入側邊欄、讀取頁面零件清單、呼叫 AI Provider，最後把推薦零件反映回原本的頁面。
這個專案不需要打包流程，也沒有複雜的前端框架。整體使用 Chrome Extension Manifest V3、原生 JavaScript、HTML 與 CSS 完成，因此很適合拿來理解 Chrome 插件的基本架構。
Docker 是容器化技術的核心工具，掌握其常用指令對於日常開發和運維工作至關重要。本指南將介紹最實用的 Docker 指令，並提供詳細的使用說明和範例。
平常在測試新的開發工具、VS Code 版本、JDK 或終端機設定時，最麻煩的地方通常不是安裝本身，而是安裝後會不會改到主機環境。像是 PATH、右鍵選單、登錄檔、使用者設定與工具版本，只要多試幾次，就可能讓原本穩定的開發機變得難以追蹤。
而這篇文章的起因，則是近期各種套件竊取資訊、惡意更新與供應鏈攻擊事件越來越頻繁。當我們只是想快速驗證某個工具、套件或 extension 是否可用時，其實不一定適合直接在主要開發機上執行。即使來源看起來可信，也可能因為相依套件、安裝腳本或更新流程帶來額外風險。
Windows Sandbox 很適合用來處理這類需求。它可以建立一個一次性的 Windows 環境，關閉後所有變更都會被丟棄；只要把啟動設定與安裝腳本整理好，每次都能快速還原出乾淨且一致的 VS Code 開發驗證環境。
這篇文章會以 C:\Sandbox 底下的設定為例，說明如何透過 Windows Sandbox 自動掛載資料夾、套用基本系統設定，並離線安裝 VS Code、PowerShell 7、Windows Terminal、7-Zip 與 Zulu JDK，讓 Sandbox 啟動後就能直接進行開發驗證。完整範例可參考 java-sandbox 專案。
最近把一個放在腦中一陣子的小想法做出來了：幫自己的 blog 做一個可以聊天的 agent。
這個念頭其實是從很日常的困擾開始的。文章寫久了之後，自己有時候也會忘記以前到底寫過哪些東西。要找內容時，通常就是翻分類、看標籤、搜關鍵字；這些方式當然都能用，但總覺得少了一點「直接問它」的感覺。既然現在 AI 工具都已經這麼容易接了，那乾脆試試看，能不能讓自己的 blog 也變成一個可以對話的入口。
所以這次就用 LangChain4j 快速做了一個 Blog Agent。沒有一開始就想把它做成什麼很完整的產品，比較像是先把腦中的畫面做出來：後端有一個 server side 可以處理 agent 的互動，服務直接丟到 Cloud Run 上跑，然後再寫一個給 Hexo 用的聊天室窗插件，把它接回原本的 blog 頁面。
做的時候其實滿有那種「先讓它跑起來再說」的感覺。LangChain4j 這邊先把後端流程接起來，Cloud Run 負責讓服務可以被呼叫，Hexo 插件則處理畫面上的聊天入口。每一塊都不算特別巨大，但全部接在一起之後，看到自己的部落格右下角真的出現一個可以互動的聊天室，感覺還是滿微妙的。原本只是靜靜放文章的地方，突然多了一個可以被詢問的介面。
