Pcion's Blog

什麼是 Jaeger？

Jaeger 是一套開源的分散式追蹤系統，常用於觀察微服務架構中請求在不同服務之間的流向、耗時與錯誤位置。透過 Jaeger，可以把分散在多個服務中的 trace 資料集中起來，協助開發者分析效能瓶頸與服務之間的呼叫關係。

本文會示範如何在 Ubuntu 環境中安裝 Jaeger Tracing，並透過 systemd 將 Jaeger 設定成系統服務。這裡使用 Jaeger 的 OpenTelemetry Native Backend 設定，讓服務可以接收 OTLP gRPC 與 HTTP 格式的 trace 資料，並透過 Jaeger Query UI 查詢追蹤結果。

Jaeger 的主要功能：

• 分散式追蹤：記錄請求在多個服務之間的完整流向
• 效能分析：查看每個 span 的耗時，協助找出延遲來源
• 錯誤排查：透過 trace 資料定位服務呼叫失敗或異常的位置
• 服務觀察：搭配 OpenTelemetry 收集 trace，建立基本的可觀測性基礎

為什麼使用 Jaeger？

相較於只依賴應用程式日誌，Jaeger 可以用更直觀的方式呈現跨服務請求的完整脈絡：

1. 請求脈絡清楚：可以追蹤一次請求經過哪些服務與操作
2. 問題定位更快：能從 trace 中看出延遲、錯誤與異常發生的位置
3. 支援 OpenTelemetry：可以接收 OTLP gRPC 與 HTTP 格式的 trace 資料

這篇文章記錄如何在 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 專案。

簡介

VS Code 搭配 Extension Pack for Java 後，已經可以完成 Java 專案開發中常見的編輯、導覽、重構、測試與除錯工作。不過，如果每個動作都依賴滑鼠點選，開發節奏很容易被打斷。熟悉幾組常用快捷鍵，可以讓你在閱讀程式碼、追蹤呼叫關係、修正錯誤與啟動 Debug 時更加順手。

這篇文章整理在 VS Code 上開發 Java 時最常用的快捷鍵，會以實際開發情境分類，方便你依照自己的使用頻率逐步記起來。

最近把一個放在腦中一陣子的小想法做出來了：幫自己的 blog 做一個可以聊天的 agent。

這個念頭其實是從很日常的困擾開始的。文章寫久了之後，自己有時候也會忘記以前到底寫過哪些東西。要找內容時，通常就是翻分類、看標籤、搜關鍵字；這些方式當然都能用，但總覺得少了一點「直接問它」的感覺。既然現在 AI 工具都已經這麼容易接了，那乾脆試試看，能不能讓自己的 blog 也變成一個可以對話的入口。

所以這次就用 LangChain4j 快速做了一個 Blog Agent。沒有一開始就想把它做成什麼很完整的產品，比較像是先把腦中的畫面做出來：後端有一個 server side 可以處理 agent 的互動，服務直接丟到 Cloud Run 上跑，然後再寫一個給 Hexo 用的聊天室窗插件，把它接回原本的 blog 頁面。

做的時候其實滿有那種「先讓它跑起來再說」的感覺。LangChain4j 這邊先把後端流程接起來，Cloud Run 負責讓服務可以被呼叫，Hexo 插件則處理畫面上的聊天入口。每一塊都不算特別巨大，但全部接在一起之後，看到自己的部落格右下角真的出現一個可以互動的聊天室，感覺還是滿微妙的。原本只是靜靜放文章的地方，突然多了一個可以被詢問的介面。

這一輪 Pixel Battle 的開發，主要集中在任務引導與前期體驗的整理。相較於前幾次紀錄裡還在搭建系統骨架，現在遊戲已經做出兩個章節的任務流程，也加入了對話系統。整體來看，玩家進入遊戲後應該會比以前更容易理解自己正在做什麼，也比較能感受到遊戲希望帶出的體驗方向。

最近 Pixel Battle 的基礎系統已經完成到一個可以繼續往內容層推進的程度。地圖探索、角色成長、戰鬥切換、怪物素材、技能與 build 的骨架都逐步搭起來之後，開發上遇到的問題也開始改變：以前比較常卡在「系統要怎麼做」，現在則更常卡在「玩家進來之後，到底要經歷什麼」。

所以這一輪我把重點放在世界觀設定，以及遊戲前 30 分鐘的體驗內容。也就是先讓遊戲從一個功能逐漸堆起來的原型，慢慢變成一個有背景、有起點、有任務節奏，也能讓玩家理解自己正在扮演什麼角色的作品。

最近和朋友聊了一下，也趁這個機會重新檢視了原本的設計方向。最早我想做的是結合世界地理位置的遊戲概念，讓玩家可以依照不同地區、座標或現實地圖上的位置展開探索與戰鬥；這個想法聽起來很有想像空間，但真的開始往下拆解之後，才發現範圍比一開始預期的還要龐大許多。光是要建立世界規模的地理資料集、整理不同區域的內容規則，甚至後續還要考慮資料維護、遊戲平衡與實際遊玩節奏，就已經不是目前這個原型階段能夠輕易承擔的規模。因此，接下來我打算先把內容收斂到限定區域，先從比較小、比較明確的範圍開始設計，讓核心玩法、戰鬥流程與角色成長可以更聚焦。這樣雖然暫時放棄了一些宏大的想像，但也讓整個專案更有機會真正做出可玩的版本，而不是停留在一個很大的概念上。