看日誌 log 除錯 的思路

作為軟體工程師,在 除錯 的時候,為確認系統發生的情況,會運用什麼思路?

我有這樣的思路:

1. 時間

依據事件發生的時間,盡可能縮小搜尋 log 的範圍

2. 事務 (Transaction)

看見 log 中的事務,相同事務通常有以下特徵:

  • 相同進程 or 線程 id (多線程系統)
  • 相同 trace_id or uuid (分散式系統)

就是找到事件中一到多個工作單元的開始與結束

3. 關鍵字

事務中有哪些關鍵字,足以代表系統當時進行的是何種行為、交易與異常?

4. 因果關係

  • 行為、交易與異常的上下文關係,結合時間順序,便可推測什麼行為開始有後續這異常的發生
  • 認識系統上下游:對整個系統架構的認識能幫助認清問題

5. 異常訊息的語義

有無異常代號,官方文件對此異常的說明是什麼?異常觸發的條件是什麼?

6. 異常訊息顯示在哪一行程式碼或套件源碼發生?

7. 這行程式碼或套件源碼上下文 (input、output、call tree) 與 log 上下文因果匹配

8. 找到什麼 input,會造成這行程式碼,或套件的源碼報錯

input 可能是動詞或名詞:

  • 如跟後台或 DB 取資料,就是動詞
  • 如前台傳遞參數為空,就是名詞

9. 重現問題

製造發生同樣異常的案例,視情況可規劃為測試案例,避免之後再出錯

10. 解決出現這個 input 的原因

常見原因通常有這幾種:

  • 本身系統程式 BUG (如忘記覆值…)
  • 上游系統的問題 (如資料格式不正確…)
  • 下游系統的問題 (如 DB、Server 無回應…)

11. 最後盡可能地發揮“通靈”的能力

私訊《畫家帽の龍》FB 粉絲專頁“666” 就送給你《轉職軟體工程師攻略圖》,助你朝想要的方向前進。

祝你職涯順利~Go~

跨領域 的我有哪些優勢?

關於”跨領域”底下這兩個問題你還會想到哪些答案呢?

(一) 哪些是可以帶過來的?
1. 問題解決能力
2. 與人溝通能力
3. 計劃組織能力
4. 時間管理能力
5. 批判分析能力
6. 領導統御能力

(二) 哪些是須要從 0 開始?
1. 領域專業知識
2. 環境文化適應
3. 人際關係建立

我問自己這兩個問題時,發現問題 (一) 還可以再想出許多舉例,
但問題 (二) 能想出來的就比較少了。

所以提升”軟”技能可以為自己的履歷加分許多呢~

此外還有一個也有”軟”字的技能,就是”軟體工程”啦!

數位轉型是行業趨勢,期望將流程自動化,
並持續整合 CI,持續發布 CD,
這是未來不可或缺的剛需。

因範疇不同,公司可能不會因此僱用一名工程師,
但若你自行開發出一個程式小工具,加快了你的工作效率,
想像一下…
在你的領域裏,你或許就是那一位問題解決能力最佳的人,
進而為自己加分!

跨領域學習,擴大思維廣度,提升了問題解決與分析的能力。
"持續學習"是 持續整合 的根本,那麼你就是那一位不被淘汰的人才!

私訊《畫家帽の龍》FB 粉絲專頁“666” 就送給你《轉職軟體工程師攻略圖》,助你朝想要的方向前進。

祝你職場順利~Go~

轉職 為 軟體工程師,我與本科系的差距在哪?

轉職 時你是否想過這個問題,因而卻步了呢?

差距在於他們一生中至少有 3 ~ 4 年和資訊工程領域相處,
看起來是很驚人的時間,但是一天 24 小時,有休閒娛樂,有週休二日,
與它相處的時間,扣一扣可能就沒那麼多了。

因此實際上的差距在於是否有與它頻繁相處,溫故知新

依據台大資工系 學士學程 大一到大三課程大綱,不含普生、普物、普化、專題,依序有這 13 門必修課:
〔一上〕
1. 計算機程式設計 (Computer Programming)
〔一下〕
2. 資料結構與演算法 (Data Structures and Algorithms)
〔二上〕
3. 線性代數 (Linear Algebra)
4. 演算法設計與分析 (Algorithm Design and Analysis)
5. 系統程式設計 (System Programming Design)
〔二下〕
6. 機率 (Probability)
7. 作業系統 (Operating Systems)
〔三上〕
8. 自動機與形式語言 (FORMAL LANGUAGES AND AUTOMATA THEORY)
9. 計算機網路 (Computer Networks)
10. 計算機結構 (Computer Architecture)
〔三下〕
11. 計算機網路實驗 (Computer Networks Laboratory)
12. 計算機系統實驗 (Computer Systems Laboratory)
13. 人工智慧導論 (Introduction to Artificial Intelligence)

想一想,為什麼從自學或短期培訓轉職的人可以轉職成功?因為他們有以上 13 門課的第一項,甚至第二項基本知識。

剩下的 11 項是基本知識廣度,面試時知道會很加分,至於深度,根據職業內容會需要更多複雜的知識。
而比別人厲害、不被淘汰的差距就在這基本的廣度與應有的深度,還有前面所提到的頻繁與它相處,並持續溫故知新。

根據 82 法則,大學每天上課 8 小時中,大約有 1.6 小時高效學習時間。
所以最少最少每天給自己 1.6 小時專心接觸資訊工程知識。

現在大學開放式線上課程許多,多半是基礎知識,課程影片可以快轉 2 倍,剛開始會很生澀,速度較慢,但保持每天接觸,或有人帶你伴讀,我相信只要肯做,會愈讀愈快,大學一學期 18 週,扣掉選修科目的時間,一個月完成半學期 (9 週) 的課程內容是沒問題的。

私訊《畫家帽の龍》FB 粉絲專頁“666” 就送給你《轉職軟體工程師攻略圖》,助你朝想要的方向前進。

祝你轉職順利~Go~

屬於你的 故事 User Story

嗨囉~今天想問大家,你的 故事 User Story 是什麼?

在軟體開發過程裏有一種開發模式,叫做敏捷軟體開發 Agile,
雖是從軟體發展中出現的模式,但因其快速應變市場,客戶價值導向的性質,所以也有應用於軟體以外的領域喔~

有三個屬於敏捷開發的流行框架,Scrum、Kanban 和 Extreme Programming (XP)。

其中常用到一種工具叫做 User Story (使用者故事),以用戶的視角出發,協助聚焦客戶的需求與期望價值。

故事描述的格式像這樣:

As a 〔〕, I want to 〔〕, so that 〔〕.
中文為:
作為〔誰〕,我想〔做什麼〕,以便〔為什麼目的〕。

這是我的故事:

作為一位〔光芒啟發教練〕,我想〔做出一套系統〕,以便〔讓人發揮潛能〕。

換你來說說故事囉~

如果你自己就是你的客戶,你要如何幫助自己達到一個目標或解決一個問題?

最後記得私訊《畫家帽の龍》FB 粉絲專頁“666” 就送給你《轉職軟體工程師攻略圖》,助你朝想要的方向前進。

祝你職場順利~Go~

生活中的 進程 與 線程

嗨囉~今天跟大家分享電腦裡的 進程 與 線程

— 私訊《畫家帽の龍》FB 粉絲專頁“666” 就送給你《轉職軟體工程師攻略圖》,裏頭有軟體業不同面向的程式語言分類及軟工知識圖譜,若想要比別人有競爭力,就把這些都學會吧~

進程顧名思義是“進行中的應用程序”,

線程是進程下的工作線,可以說是“進程的子程序”。

打開 Windows 的工作管理員可以看到好多條列的應用程序。

有的應用程式有箭頭符號 > 可以點擊展開,這表示它底下有正在運行多個相關的進程或服務。

可以發現瀏覽器的把它展開來,會發現比其它應用程式多很多項目。

Windows 的工作管理員

這是因為瀏覽器本身是多進程架構。進程間的空間資源是互相隔離的,此特性剛好可以有效防止跨站點的攻擊和數據洩露,所以每開一個分頁,我們就會為分頁分配一個進程,這是為了安全考量。

而線程是進程下的子任務,它不會在工作管理員看到,要在資源檢視器的執行緒欄位看喔~

Windows 資源檢視器

  • 一個進程下可以有多個線程
  • 線程自己也有自己獨立的空間
  • 線程間不可互相取用各自的資源
  • 在同進程下的多個線程可以共用進程的資源
你可以想像,你去公廁上大號,其中洗手台裝潢在內部
有分男廁 (進程 1) 和女廁 (進程 2)
每個人 (線程) 都只用一間馬桶 → 線程間不可互相取用各自的資源
男廁的洗手台給男生用,女廁洗手台給女生用 → 進程互相隔離,但線程共用進程裡的資源

以上希望能幫助大家理解進程與線程的關係。

最後記得私訊《畫家帽の龍》FB 粉絲專頁“666” 就送給你《轉職軟體工程師攻略圖》,助你朝想要的方向前進。

祝你職場順利~Go~

【哇~學程式有這麼多東西要學,我怎麼可能跟其他人比?】 轉職 軟體工程師攻略

嗨囉,今天來跟大家分享,我五年前面試到成為「軟體工程師」的經驗。希望可以幫助到想要“轉職”或準備要“跨領域”踏入這職位的人。

— 私訊《畫家帽の龍》FB 粉絲專頁“666” 就送給你《轉職軟體工程師攻略圖》,裏頭有軟體業不同面向的程式語言分類及軟工知識圖譜,若想要比別人有競爭力,就把這些都學會吧~

我在大學時,有修 C&C++,當時我幾乎聽不太懂在幹麻?所以後來有去學線下的電腦程式語言班,當時都很推薦 Java Web 網站開發班,因為有附贈 C&C++ 課程,於是就報名了。

後來 Android 開始紅了起來,我挺好奇的,因為又是另一門主修,且一樣有附贈其它課程,如:illustrator、PhotoShop、網路基礎知識、JavaScript 等等許多任選,當時還有一門跟著 Android 與 Swift 一起出現的 UI/UX 課程,哇~很多,可以滿足我好奇心,於是又報名了一個主修。

當時花了超多時間上課,學到後來還是決定以網站開發為主,原因有幾個:

一、大學實習時,我是做生理訊號傳送到手機的APP,設計出藍牙連接即時顯示數據在儀表板的功能,並可以滑動頁面切換腳踏速率表與心律圖,開發完後發現很卡頓。過程中覺得開發手機 APP 超麻煩,還有 Android Studio 開發工具不是很好用,因此捨棄手機 APP 的求職路線。

二、因為我是電機系,雖然 UI/UX 有簡單的邏輯,但頁面流程幾乎還是用手拉出來的,當時覺得好像是給美術設計的人去發展職業的附加技能,於是也捨棄跟設計有關的了。

三、至於 JavaScript,我上完課只知道它是另一種語言控制瀏覽器的元件,但是好像跟網頁設計有關,好像又是美術之類的,於是也把 JavaScript 開發捨去了。

因此最後就變成選 Java Web 的職缺了,不過就算上完課,我對網站開發還是不知道全貌到底在幹麻?也分不清楚什麼叫前端?什麼叫後端?只知道,喔~用 Java 寫一寫邏輯是不是就可以當 Java Web 工程師了,好像比較容易。當時我還看不出來我寫的程式有沒有效能問題,效能這個概念我都還沒有。

當完兵後,我開始找網站開發職缺時,在 104 找工作發現,工作說明裡頭有很多名詞在學校和當時報名的課程中都沒有教到,當時我對網站後端開發了解甚少,只有 Java 程式語言基礎,於是我開始上網找資源學習…

後來看到 Udemy 這個平台,我搜尋網站開發,發現怎麼有 PHP,這是什麼東西,哇~還可以做出購物網站,課程特價,於是買了上完課做出自己的網站,也放上家裡賣的熱炒照片到商品頁面。但是這個跟 Java Web 有什麼關係?為什麼課程中都沒有用到 Java?但我還是用這個當作作品集投遞履歷了。

面試過幾家公司,發現他們好像都要筆試,當時我還不知道 LeetCode 這東西,是面試後 HR 告訴我的,但還好大學有修演算法與資料結構,當時不知道學這個用途是什麼,原來是要面試用的…於是面試都沒有上。

— 後來才了解實際上演算法與資料結構不是應付面試用的,而是一部分與我一直沒有去思考到的效能瓶頸有關,雖然工作中有用場機會的演算法只有幾個重要觀念,但是它可以訓練程式開發思考角度與維度的面相,間接影響了程式開發品質。

於是我開始刷LeetCode 題了,後來就面試到做 Line Business Connect Server 的接案公司,公司職缺說明中有 Spring 框架,我在面試前又去 Udemy 搜尋 Spring,但搜到 Spring Boot 的課程 (當時我還分不清楚原來還有 Spring FrameworkSpring BootSpring Cloud 這幾個框架),因此買了上課,發現這怎麼這麼神奇,原來可以這樣就創建 API 了,好快,當時怎麼都沒有教這個。

順利地我進入了這家接案公司,小菜雞的我以為準備好了該有的技能來上班了,但是才發現還有超多不知道的東西,之前認為不會去使用的 JavaScript 竟然用上了,此時才開始知道這叫前端開發,而後端開發是 Java,還好我先前誤買的 PHP 購物車課程有提到一些 HTML 和 CSS 的知識,不然我可能會跟不上工作。我才知道,疑~原來可以用那麼多種語言做後端的事情,並了解 PHP 與 Java 都是後端語言,且有不同的語言特性,一個可以直接嵌入在 HTML 裡頭。算是誤中得福啦~多學還是有差。因此我在一個月內就上手基本的開發工作,許多 Spring 框架的知識也才正式開始累積,並不是只有 Udemy 課程裡提到的那樣而已,因為公司使用到 Spring Framework,跟 Spring Boot 還是有差異,對 Tomcat 的認識也才在工作中愈來愈知道。

這一份工作雖然面試後端,但是也有碰到前端開發的事情,做中學,學中做,下班學,磨練出開發前端的技能了,也在工作中更了解資料庫的特性。

因為我是電機系,所以學校關於軟體開發的內容比較無法涵蓋太多,但是許多課程內容還不足涵蓋所有基本技能與知識,通常要集合許多講師的知識,所以還要學很多,並自己探索。而且課程又昂貴 (前前後後因好奇心,花了近 20 萬學電腦程式相關)。但是實際上還有很多沒有教,這樣自學的狀態持續到了現在,五年了,我把畢生為止大概用到的知識圖譜紀錄到了《轉職軟體工程師攻略圖》。

最後記得私訊《畫家帽の龍》FB 粉絲專頁“666” 就送給你《轉職軟體工程師攻略圖》,助你朝想要的方向前進。

祝你職場順利~Go~

Claudia 頌缽

頌缽音流初體驗 – 身體細胞 SPA

活動時間 2023/11/26

今天 達真協會 邀請到量子信息場教練 Claudia,幫大家做頌缽音流,先前從未體驗過,過去有看過相關影片,並會去聽聽看,當時不知道這是頌缽,只覺得聽起來確實令人靜心,以為是和尚拜拜時才會敲的東西。

今天的體驗過程是躺著的,與身體掃描很像,所以我當時就順勢地以身體掃描的方式去體驗音流。 有了頌缽的身體掃描,我覺得比較能去體驗自己,是會有感覺到東西在流動的,聽大家分享後才知道原來可以稱那是電流的感覺。若用科學的方式說,應該就是聲音共振出的泛音,當與自己身體頻率對到的時候,便有波動傳過的感覺。

體驗後我猜想,當感覺到電流時,低頻與高頻是否有不同的意義呢?就跟可見光波長不同會呈現不同顏色一般, 於是我用關鍵字頌缽光譜 Google 了一下,奇蹟,真的有不同顏色耶! 原來這就是脈輪顏色,先前也有聽過派輪,也知道有顏色,但是不知道原來脈輪顏色是因為身體頻率發出的顏色,經過這次體驗後恍然大悟原來頌缽與脈輪頻率有關係。

這次的體驗我在快速敲打不同頌缽與聽到風鈴的時候特別有感覺到電流,真的很奇妙 ~ Claudia 說頌缽是在清理身體細胞,這樣我全身是不是都做了音波 SPA 都被清理了呢 ~ 哈哈 ~ 把阻礙都清理乾淨吧!嘿嘿 ~

謝謝 Claudia,我想我會開始研究這個東東了☺

在 K8s 上實現全棧監控

DevOpsDays Taipei 2023 Workshop

環境準備

使用包管理工具安裝 kubectl 與 Helm

  1. 以 Powershell 指令安裝 Scoop
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Get-ExecutionPolicy
$env:SCOOP='D:\Applications\Scoop'
# SetEnvironmentVariable 須要用 administrator 執行
[Environment]::SetEnvironmentVariable('SCOOP', $env:SCOOP, 'Machine')
Invoke-Expression (New-Object System.Net.WebClient).DownloadString('https://get.scoop.sh')
scoop -v
scoop bucket add extras
scoop update
  1. 安裝 kubectl
scoop install kubectl@1.27.2
  1. 安裝 Helm
scoop install helm
  1. 安裝 gcloud CLI

  2. git clone Workshop GitHub Repository

導言 (2分鐘)

在當前的微服務架構和容器化部署中,Kubernetes 已成為一個不可或缺的工具。

今天,我們將探討如何在 Kubernetes 環境中集成 OpenTelemetry、FluentBit、Prometheus 和 Grafana,以實現全面的集群監控。將一步步展示如何部署並配置這些工具,以實現對集群運行狀態的全方位監控,包括收集應用和基礎設施的指標,設置數據源,並在 Grafana 中視覺化這些數據。

arch.png

Kubernetes 和 GKE 簡介 (3分鐘)

  • Kubernetes (K8s) 是一個開源容器編排工具,專為自動部署、擴展和管理容器化應用而設計。
  • GKE (Google Kubernetes Engine) 則是 Google Cloud 平台上的管理型 Kubernetes 服務。

GKE 上建立集群 (10分鐘)

此 Lab 雖使用 GKE 進行,但在其它 Kubernetes 平台依然可以照著文章步驟完成全棧監控的實做。

首先在瀏覽器用 Google 帳戶登入 GCP Console 控制台新建 Project,紀錄 Project ID。

gcloud auth login

檢查是否登入成功

gcloud auth list

接著,安裝認證組件

gcloud components install gke-gcloud-auth-plugin

查看建立專案清單,複製剛剛建立好的專案 PROJECT_ID

gcloud projects list

設定接下來執行工作所需的專案環境

PROJECT_ID="貼上複製的PROJECT_ID"
gcloud config set project ${PROJECT_ID}

檢查專案環境是否配置正確

gcloud config list

啟用 Kubernetes Engine API

gcloud services enable container.googleapis.com \
    --project ${PROJECT_ID}

在 GKE 上建立集群其實就是建立一組運行 Kubernetes 的虛擬機。

gcloud container clusters create "devopsdays-cluster" \
    --region asia-northeast1 \
    --node-locations asia-northeast1-a,asia-northeast1-b \
    --num-nodes=1 \
    --machine-type=e2-medium
  • --region:選擇集群的地理位置。
  • --node-locations:選擇集群的可用區域 (將節點分佈在不同可用區域可以以提高可用性)
  • --num-node:每個可用區域的節點數量。
  • --machine-type:虛擬機的規格。

接著,取得 kubeconfig 認證

gcloud container clusters get-credentials devopsdays-cluster --region asia-northeast1 --project devopsdays-2023

f90ffffdb8c65709925fde999f175bd0.png

086c6f338665b807861c1fff060d8729.png

安裝 Kubernetes Dashboard (Optional 5分鐘)

Kubernetes Dashboard 是 Kubernetes 的官方 Web UI。

  • 可視化資源的使用情況
  • 進行應用程式的疑難排解
  • 用於管理 K8s 集群

因為我們使用 GKE 服務,已經有 UI 管理介面,所以這個步驟可以不用做。

kubernetes-dashboard 7.0.0-alpha1 · helm/k8s-dashboard (artifacthub.io)

安裝及存取 Dashboard

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
#
helm repo update
#
helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard
# Get the Kubernetes Dashboard URL by running:
export POD_NAME=$(kubectl get pods -n kubernetes-dashboard -l "app.kubernetes.io/name=kubernetes-dashboard,app.kubernetes.io/instance=kubernetes-dashboard" -o jsonpath="{.items[0].metadata.name}")
#
echo https://127.0.0.1:8443/
#
kubectl -n kubernetes-dashboard port-forward $POD_NAME 8443:8443

安裝 Ingress Controller (5分鐘)

Ingress Controller 讓我們可以設定外部訪問進入 K8s 集群的路由,在 Kubernetes 中是類型為 LoadBalancer 的 Service。

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
#
helm repo update
#
helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

ec9eb57d8afe693ccc4866fae8196907.png

在 GKE 中安裝 Ingress Controller 會創建一個負載平衡器(Load Balancer),GCP 會分配一個暫時性(Ephemeral)的外部 IP 地址(INGRESS_IP)給負載平衡器,但不會自動為它分配一個域名。

因此我們要獲取 INGRESS_IP 並設定為保留 IP(Static IP)。

MY_INGRESS_IP=""
#
MY_INGRESS_IP=$(kubectl get svc ingress-nginx-controller -n ingress-nginx -ojson | jq -j '.status.loadBalancer.ingress[].ip')
#
echo 'MY_INGRESS_IP: '$MY_INGRESS_IP
#
gcloud compute addresses create "devopsdays-cluster-ingress-ip" --addresses=${MY_INGRESS_IP} --region=asia-northeast1

在 GCP Console 可以看到 External IP 變成 Static 類型。

7154668d16c79de7acbed20b0ddfae43.png

如前述 GCP 不會自動為負載平衡器分配一個域名,所以接著我們要自己配置域名。

因為我們在測試階段,不用真的去購買一個域名,只需要在本機的 hosts 文件中配置將 INGRESS_IP 指向到域名 gke-cluster-demo 即可。

在 Windows 系統中,hosts 文件的位置在:

C:\Windows\System32\drivers\etc

在 Apple 的 macOS 和大多數 Linux 系統中,hosts 文件的位置在:

/etc/hosts

使用 root 權限用文本編輯器打開和並修改它,在文檔最下方加入這一行:

MY.INGRESS.IP gke-cluster-demo

請記住,在進行任何修改之前,總是先備份原始的 hosts 文件。

監控工具 Prometheus (10分鐘)

Prometheus 是一個開源系統監控和警報工具。

在 Kubernetes 中,每個節點、Pod 都是資源。Prometheus 可以幫助我們獲取這些資源的度量指標。

kube-prometheus-stack-ingress.yaml

此文件配置了 Prometheus、Alertmanager 和 Grafana 的 Ingress 設定。

  1. Prometheus
  • 啟用 ingress。
  • 使用 nginx 作為 ingress 的類型。
  • 定義了外部路徑 /prometheus
  1. Alert Manager
  • 警報如何與 Gmail 整合。
  • 啟用 ingress。
  • 使用 nginx 作為 ingress 的類型。
  • 定義了外部路徑 /alertmanager
  1. Grafana
  • 服務運行於 3000 端口。
  • 環境變數設定了 Grafana 的根 URL 和子路徑。
  • 啟用 ingress,路徑設定為 /grafana
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
#
helm repo update
#
helm install prometheus prometheus-community/kube-prometheus-stack --set grafana.sidecar.dashboards.enabled=true -f kube-prometheus-stack-ingress.yaml -f kube-prometheus-stack-values.yaml -n prometheus --create-namespace

其中 prometheus-community/kube-prometheus-stack 整合了 Prometheus、Alert Manager 和 Grafana。

我們在 yaml 中配置了 ingress 資源,就可以於瀏覽器輸入以下網址即可看到監控服務的後台介面:

或是用 port-forward 的方式到監控服務的後台介面:

kubectl -n prometheus port-forward prometheus-grafana-75d58479bb-8kth6 3000:3000

其中 prometheus-grafana-75d58479bb-8kth6 依據當時所產生的 pod name 更換。

kubectl -n prometheus port-forward alertmanager-prometheus-kube-prometheus-alertmanager-0 9093:9093

kube-prometheus-stack-values.yaml

此文件定義了 Prometheus 和 Alertmanager 的一些核心參數。

  • Prometheus:
    • 定義 scrape 和評估的間隔時間。
    • 定義了一個自定義的警報規則,如果某實例停止運行超過1分鐘,將觸發警報。
  • Alertmanager:
    • 設定全局的 SMTP 參數以使用 Gmail 發送警報。
    • 定義了路由和接收者的設定。

佈署服務與 Prometheus 監控 (10分鐘)

這裡我們會佈署一個以 Java Spring Boot Web 框架撰寫的示範服務,並對它進行監控。

authorization-server-service-deployment.yaml

此文件定義了授權伺服器的部署、服務和入口。

  • 使用 Deployment 來管理 pod。
  • Service 定義了如何訪問這些 pod。
  • Ingress 定義了如何從外部訪問此服務。
kubectl create namespace demo
kubectl apply -f authorization-server-service-deployment.yaml -n demo

部署完成後,這是一個授權服務器,在這個網址可以看到它的資訊

https://gke-cluster-demo/.well-known/oauth-authorization-server

authorization-server-service-monitor.yaml

這是 ServiceMonitor 的配置,用於告訴 Prometheus 如何發現和抓取授權伺服器的指標。

  • 定義了匹配標籤和抓取的端點。

部署 Prometheus 監控

kubectl apply -f authorization-server-service-monitor.yaml -n demo

查看監控是否部署完成

kubectl get ServiceMonitor --all-namespaces

37bda38df1b47f89f412334211fc115d.png

Grafana Dashboard 監控數據可視化 (10分鐘)

Grafana 是一個開源平台,可以整合 Prometheus、OpenTelemetry、Tempo、Loki 等數據源,提供一個統一的資料可視化界面。

我們新增 Dashboard 將剛剛 Prometheus 監控的數據可視化。

Spring Boot 2.1 System Monitor | Grafana Labs

e56ae447d8972b5b7c8c3e4f992c0aff.png 37780d2492dc3755f4713b9a9b2002b5.png

09a40eb4ef4c38e0ae96c38fbb936009.png

b519611ed7613b1fcf7a4125c2b7b5b5.png

Log(Tempo) to Trace(OpenTelemetry) and Trace to Log (25分鐘)

安裝 OpenTelemetry

OpenTelemetry 是一個開源專案,用於收集應用程式的追踪、指標和日誌數據。

  • OpenTelemetry 提供了一系列的 API、庫、代理和儀器,使開發者能夠添加觀察性到他們的應用程式。
  • 被視為 OpenTracing 和 OpenCensus 兩個專案的後繼者,並結合了它們的最佳實踐。
  • 允許開發者自動收集和導出性能指標和追踪資料,使其更容易診斷問題和了解應用程式的運行狀況。

otel-collector-sidecar.yaml

這是 OpenTelemetry Collector 的配置。

  • 運行在 sidecar 模式。
  • 定義了接收、處理和導出跡象數據的流程。
kubectl apply -f cert-manager.yaml

這裡要等一下 cert-manager 與 cert-manager-webhook 兩個 pod 是否已經啟動完成,再裝 opentelemetry-operator。

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
#
helm repo update
#
helm install opentelemetry-operator open-telemetry/opentelemetry-operator -n tracing --create-namespace
kubectl apply -f otel-collector-sidecar.yaml -n demo

安裝 Tempo

Tempo 是 Grafana Labs 出品的一個高度可擴展的、多租戶的、低成本的追踪系統。

  • 旨在與其它 Grafana Labs 產品如 Loki、Cortex 等緊密集成。
  • Tempo 可以存儲大量的追踪數據。
  • 不需要進行進一步的處理或索引,因此存儲成本相對較低。
  • 提供分佈式追踪視覺化,幫助開發者分析和優化他們的應用程式。

tempo-values.yaml

這是 Tempo 的簡單配置,用於 Trace 數據。

  • 啟用了 gateway 和 queryFrontend。
helm repo add grafana https://grafana.github.io/helm-charts
#
helm repo update
#
helm install tempo grafana/tempo -f tempo-values.yaml -n tracing

安裝 Loki

Loki 是一個水平可擴展的、高可用的、多租戶的日誌聚合系統。

  • 由 Grafana Labs 開發,與 Grafana 的監控軟件緊密集成。
  • Loki 的設計目標是簡單而有效,它不為日誌數據建立索引,而是為每個日誌流建立索引。
  • 提供了一個類似 PromQL 的查詢語言 LogQL,使查詢和整合變得更加簡單。

loki-values.yaml

這是 Loki 的配置,用於日誌數據。

  • 禁用了 fluent-bit 和 Prometheus。
  • 啟用了 promtail 來收集日誌。
helm repo add grafana https://github.com/grafana/helm-charts
#
helm repo update
#
helm install loki grafana/loki-stack -f loki-values.yaml -n tracing

安裝 FluentBit

FluentBit 是一個輕量級的日誌處理器和轉發器,適用於容器、伺服器、IoT 和邊緣設備。

  • 設計用於在低記憶體和CPU消耗下高效運行。
  • 提供了豐富的輸入、過濾器和輸出插件。
  • FluentBit 常被用作日誌收集器。

fluentbit-configmap.yaml

此文件定義了 FluentBit 的配置。

  • 定義了輸入、過濾和輸出的流程。
  • 使用正則表達式解析器解析 Spring 應用程序的日誌格式。
helm repo add fluent https://fluent.github.io/helm-charts
#
helm repo update
#
helm install fluent-bit fluent/fluent-bit -n fluentbit --create-namespace
#
kubectl apply -f fluentbit-configmap.yaml -n fluentbit
#
kubectl rollout restart ds fluent-bit -n fluentbit

若要看 fluent-bit 其它可以設定的 values 可以用此指令:

helm show values fluent/fluent-bit > fluentbit-all-values.yaml

再佈署一次服務

因為先前無部署 OpenTelemetryCollector,因此服務都尚未被注入 OTel Collector sidecar,所以要再部署一次。

kubectl delete -f authorization-server-service-deployment.yaml -n demo
kubectl apply -f authorization-server-service-deployment.yaml -n demo

Grafana UI 配置 DataSources (10分鐘)

1c15eb108f07fefda0c33521e594c465.png

http://loki.tracing:3100

c72354e8589a3344eda3d9ae079dec9e.png

http://tempo.tracing:3100

6f27e16aec0f313b86166f9007bb0ae9.png

Finished (5分鐘)

Workshop 結束囉,記得將 Cluster 刪除,避免產生額外費用。

gcloud container clusters delete devopsdays-cluster --region=asia-northeast1

這些工具提供了一個完整的監控和觀察性解決方案,幫助了解、診斷和優化其應用程式的性能。

希望透過今天的分享,讓各位有在 Kubernetes 實現全棧監控的基石,其中還有很多能夠補強及完善的地方,我們可以著手持續跌代演進,謝謝大家的參與。

參考資料

  1. https://github.com/cert-manager/cert-manager/releases/download/v1.10.0/cert-manager.yaml
  2. https://github.com/open-telemetry/opentelemetry-collector/blob/main/examples/k8s/otel-config.yaml
  3. https://github.com/grafana/helm-charts/tree/main/charts/tempo
  4. https://artifacthub.io/packages/helm/grafana/tempo
  5. https://artifacthub.io/packages/helm/grafana/tempo-distributed
  6. https://artifacthub.io/packages/helm/loki/loki-stack
  7. https://github.com/isItObservable/fluentbitv2/tree/master
  8. https://opentelemetry.io/docs/kubernetes/helm/operator/
  9. https://medium.com/cloud-native-daily/level-up-your-tracing-platform-opentelemetry-grafana-tempo-8db66d7462e2
  10. https://blog.cloudtechner.com/log-management-and-distributed-tracing-using-grafana-loki-and-tempo-b9c56392bae7
  11. https://grafana.com/blog/2020/02/25/step-by-step-guide-to-setting-up-prometheus-alertmanager-with-slack-pagerduty-and-gmail/

Agile Summit 2023 心得

在 06/16 我參與了 Agile Summit 2023,經過了一個禮拜思考,終於今日發表這篇文章。

一個公司的價值是什麼?
「滿足什麼需要,產出什麼價值。」
滿足客戶的需要;滿足老闆的需要;滿足員工的需要……

這太廣泛了,所以我們要找到源頭
「公司價值始於核心價值 ─ 客戶的需要。」

在很久很久很久以前,一群人為了一起吃飯而一起打拼,
一起做出決策,每個人都很清楚產品價值如何產生的。
隨著客戶愈來愈多,同伴也必須愈來愈多才可以應付日益增長的業務,
但是人多很難一一交代誰要去做什麼事,於是開始分工分群,出現了不同的專業部門與管理階層,
也造成現今企業遇到的問題,絕大多數員工不知道業務知識上下文、市場現況與產品價值。

於是專業員工不知道其工作行動背後的原因,無法獨立思考,失去了許多能夠一起提供想法的人。

專業技術與業務上下文沒有對齊,資深專業員工必須靠著好幾年的過往經歷才可以逐漸知道具體業務。
員工有新有舊,若知識沒有傳遞,新進員工又必須重新再做一樣的事。

「將專業知識與業務知識配合才可以充分展現產品價值。」

KEYNOTE《Leaders at All Levels》

Esther 將公司員工分成兩個三角形集合
∇. CONTEXT(Domain Knowledge)
Δ. DAY2DAY(Developers)
將兩個三角形重疊,交集的部分便會形成”鑽石”。

將"鑽石"擴大,讓核心價值變得閃耀

Esther 建議將”鑽石”擴大。

採用 DDD 剛好是可以讓”鑽石”擴大的方法,
因為 DDD 強調與領域專家密切合作以瞭解業務領域,
可以使用的工具有 Event Storming、Domain Storytelling 與 Example Mapping。

那要如何在敏捷中實踐擴大”鑽石”呢?
以 Scrum 為例,在 Sprint Planning 開始前,
用戶代表、領域專家、PO、Developers 與 Scrum Master 等可以一同參與以上工具的工作坊,
工作坊中討論出的 User Story 可以銜接後續的 Sprint Planning 進行 Sprint Backlog 的規劃。

工作坊中 User Story 的產出因有 Developers 的參與,所以強化了專業知識與業務知識的整合度。

此外,環境是否有足夠的安全感,讓每個成員得以在平等的情況下表達出自己的想法,也非常重要!
工作坊中 Scrum Master 要確保在沒有階級、資歷或刻板印象的氛圍進行討論,以促進每個人提出想法。

Esther 分享了他的故事,故事告訴我們:
「新人有時能夠看到我們忽略的事物,並提出新的洞察。」

每個人的想法,甚至是直覺 ─ I(Incomprehensible)都可能是未來工作沒看到的盲點。

及早發現問題可選擇的方案數量,往往比問題發生後可選擇的方案數量還多。

Esther也強調中階主管應該
「明確地界定團隊自主做出決策的範圍與邊界。」

因為中階主管與執行人員最接近,要能夠觀察(Reverse Shadowing)周圍發生的事情,關注:

  • 如何增強人們完成工作的能力?
  • 如何發展人才?
  • 如何改進系統的運作方式?
  • 如何下放合適的權限給團隊?

這有助於「敏捷團隊自治。」

Esther 想要告訴我們的是
每個人都可以選擇去作為一個領導者:
「因為有了你的意見,團隊的決策發生改變,此時你便是一位領導。」

於是我開始想~

我們可以如何促進團隊中每位成員發聲呢?

《敏捷吔接龍 – 以團隊共創凝聚團隊共識並激發新想法》

這是一個工作坊,我從中學習到,每個人其實都有產生新想法的潛力,只要你去做,或是推他一把。

身為 Scrum Master,我想要促進團隊中每位成員發聲,我就可以幫助所有人更有效地貢獻並成為領導者。

你可以這麼做:

  1. 透過過往經驗,設計合適的會議
  2. 邀請領域專家與開發人員參與會議
  3. 將遊戲般的流程加入會議流程裡,如腦力激盪來營造容易溝通的環境

進而將”鑽石”擴大,讓團隊產出最大價值。

但在 VUCA 時代,價值要如何即時反應市場呢?

活動尾聲我參與了這一場議程,剛好為今天主題做了完美的總結。

《Value Flywheel Effect》

議程講述
企業如何發揮核心價值,並加以量化,以持續強化核心價值循環。

「核心價值是自己的產品與服務,在市場上所能看見的差異及優勢」

要衡量核心價值可以用 “North Star Metric”,且指標類型要是 Leading Metric,以即時反應市場需求。

有了指標我們可以擬定策略,策略行動可以透過 “Impact Mapping” 可視化出來。

但這些行動有辦法靈活地做調整,以符合用戶反饋嗎?
這取決於員工職能、工作流程、組織文化與環境,這些因子影響了敏捷性,
並決定了公司交付價值的能力。

所以「持續架構 Continuous Architecture」 ─ N(Nonlinear)變得很重要,
在每次Sprint週期,我們都應該審視這次產品交付過程中,
硬體、網絡、數據、安全性、性能與業務目標是否對齊;
開發人員在集成、測試與部署中是否遇到阻礙或技術瓶頸,
這兩項關心分別可以透過建置 Platform EngineeringDevOps 作為解決方案。

Kim提到持續更新架構的過程中,要提高開發人員的能見度,開發人員要能夠:

  • 參與決策
  • 將架構知識在代碼實現
  • 擁有新技術
  • 解決技術債

這邊我要再次提到“鑽石”

因為持續架構中,

架構師與開發人員之間的”鑽石”
─ 就是開發人員能見度

架構知識與業務知識之間的”鑽石”
─ 就是硬體、網絡、數據、安全性、性能與用戶需求的匹配度

如此一來就有三顆”鑽石”必須要擴大了!!!

  1. The Diamond of Domain Knowledge and Developers
  2. The Diamond of Developers and Architect
  3. The Diamond of Architect and Domain Knowledge

因此人與人之間的協作非常重要。

持續更新架構的過程,“Architectural Decisions”的紀錄很重要,因為它可以幫助了解系統的來歷,
可以輔助全盤考量,並做出更好的決策。

公司可以看作一個小型的社會,
簡報中提到 “Sociotechnical Systems”,我的解釋是
產品的品質與公司所擁有的工法、技藝和質量有關外,
也與客戶關係、員工幸福 ─ A(Anxious)、知識與文化傳承、組織管理、工作流程等
人、事、物之社會元素息息相關。

「社會元素影響技術,技術影響社會模式。」

有人便會形成社會,有了社會,產品才有地方賣,
所以「以人為本」很重要,人才就不會流失。

社會元素與技術元素的持續集成,會形成生態循環。

「一個穩健的生態是公司的護城河與地基,它影響著產品的品質。」

可藉由畫出 “Value Stream Mapping” 幫助找到系統的浪費以創建穩健的生態,
並可讓公司在發生重大災難時,擁有自我修復的能力。

最後Kim提到「長期價值」
他介紹了很棒的工具 “Wardley Mapping Canvas”
這工具可以很棒地可視化價值鏈,從用戶需求為起點出發,
鏈上滿足需求所產生的任何關鍵步驟都是價值元素。

這協助企業在產品生命週期裡,定位用戶可見與不可見的價值元素。
可見元素反映了產品在市場的優勢,是企業要持續創新並深耕的價值
對幫助企業擬定策略和紀錄決策非常有幫助。

長期價值還需要有擁抱失敗的勇氣,因系統完全可靠是不可達的 ─ B(Brittle)
重要的是建立預防文化,並可在失敗發生後快速復原並學習

以上希望對大家有幫助,期待建立長遠的眼光,保持低炭足跡,把握新興價值
能夠讓價值飛輪充滿動力地持續轉動,取之於社會,回饋於社會,讓下一代可以預見美好的未來

Thank you to Coach Esther Derby, AWS Senior Solution Architect Kim, Titansoft Scrum Master Irene, ONElab Scrum Master 大B, ONElab Scrum Master Steve, Appier Sr. Software Engineer Fong, and Cathay United Bank Scrum Master Esther.