Tech

三大支柱:各答一個問題 Metrics(指標)→ Prometheus / Mimir 有沒有問題?多嚴重? 數字時序・可聚合便宜・可長期存但沒有細節 Traces(追蹤)→ Tempo 在哪個服務?哪一段慢? 一個請求的完整路徑跨服務串起來 Logs(日誌)→ Loki 那裡到底發生什麼? 事件的完整細節量大・貴・難聚合 排障黃金路徑:由粗到細,逐步收斂 metric:有沒有→trace:在哪→log:是什麼

可觀測性是什麼:三大支柱與 LGTM 全家桶

· tech · 約 5 分鐘 · 📚 Grafana LGTM 可觀測性 #1

一個系統可不可靠,先看你看不看得見它在幹嘛。這系列講 Grafana 的 LGTM 這套可觀測性工具怎麼把「看見」做到位。第一篇立好整個系列的框架:monitoring 和 observability…

#observability#grafana

時間驅動:cron 對時(脆弱) DAG A @ 02:00 賭 A 跑完了 DAG B @ 02:30(猜的) A 遲到 → B 照跑→ 吃到舊 / 空資料 ✗ 資料驅動:Dataset(精準) DAG A → 產出 sales Dataset: sales DAG B schedule=[sales] A 一更新 → B 立刻觸發,不早不晚 ✓

Airflow 進階:Datasets、deferrable operators 與 executor 選型

· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #9

這篇講三個進階功能。它們看似無關,其實有個共同點:都在解 Airflow 某個「死板」或「浪費」——排程只認時間、sensor 佔著 slot 空等、worker 一刀切。三個都是選配,但每個都能讓你…

#airflow#data-engineering

一個資料平台的分層 監控 LGTM:一塊玻璃看全平台Grafana · Loki(logs)· Tempo(traces)· Prometheus / Mimir(metrics) Stateful 核心 — StatefulSet + PV KafkaRedis RabbitMQMetadata DB 少動・保護狀態・HA 過半・傾向 managed Stateless 運算 — Deployment + autoscale Spark executor Airflow worker Kafka Connect worker 可拋・隨開隨關・借外部狀態・傾向 self-host Kubernetes 底座control plane + etcd —— 所有東西都跑在這上面 一條軸決定分層:有狀態的沉在核心層少動;無狀態的浮在運算層隨開隨關

把它們兜成一個資料平台

· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #9

前面八篇,一個一個工具看。這篇把它們兜成一個平台。而「兜」的方法,不是把七個工具的細節背起來——是抓住那條從第一篇就在講的軸:stateful ↔ stateless。這條軸一句話決定了每個工具在平台…

#infrastructure

worker 無狀態,狀態全存回 Kafka Connector(一份 config)→ 拆成 N 個 task Worker 1(無狀態・可拋) task-1task-2 Worker 2(無狀態・可拋) task-3task-4 狀態存回 Kafka Kafka 叢集(Connect 的 state store) configsoffsetsstatus worker 掛 → task rebalance 到別台,一則不丟(狀態在 Kafka);命門 = Kafka 本身

Kafka Connect:連接器的執行時

· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #8

收尾 stateless 這一批的最後一個:Kafka Connect。它是一套專門在 Kafka 與外部系統(資料庫、S3、Elasticsearch)之間搬資料的框架——你不用每次都手寫消費者/生…

#infrastructure#kafka

Pub/Sub:廣播,丟了就丟 PUBLISH news "…" channel: news(不留存) Sub 線上✓ 收到 Sub 線上✓ 收到 Sub 離線✗ 漏掉 沒人在聽 → 沒了・無持久・無重播・無 ack Stream:留著的 log,可重播 XADD stream * …(append) m1m2m3m4m5 舊 consumer另一個從這讀 訊息留著(可設 MAXLEN 上限) 可從任意位置重讀・離線再上線能補・有 group + ack

Pub/Sub vs Stream:Redis 版的訊息系統

· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #12

Redis 也能當訊息系統,但它有兩套截然不同的東西,用錯就會莫名其妙掉訊息、或殺雞用牛刀:Pub/Sub(廣播,丟了就丟)和 Stream(留著的 log,像一台縮小版 Kafka)。這是整個 Re…

#redis#distributed-systems

逐條 N × RTT　vs　pipeline 1 × RTT ① 逐條:每條都等一個來回 clientserver 3 條 = 3 個來回 = 3 × RTT ② pipeline:打包成一個來回 clientserver cmd1 ; cmd2 ; cmd3 一次送 三個回應一起收 3 條 = 1 個來回 = 1 × RTT ✓

管線、交易與 Lua:省 RTT 與原子性

· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #11

有三個東西常被混在一起,其實各解完全不同的問題:pipeline 解「網路來回太多」、MULTI/EXEC(交易)解「一組命令要一起執行不被插隊」、Lua 解「要原子、又要帶邏輯」。搞混它們,你會拿 …

#redis#distributed-systems

Scheduler每隔幾秒 parse 一次所有 DAG 檔 parseparse ✗ top-level 放重活 df = query_db() # 模組層 cfg = requests.get(url) 每次 parse 都跑這些 → scheduler 被反覆拖垮、DAG 變慢 ✓ 檔案輕,重活進 task @task def load(): query_db() top-level 只有 DAG 結構 parse 秒過 重活只在 task 執行時跑一次

Airflow 測試與部署:別讓一個 typo 弄垮整包 DAG

· tech · 約 7 分鐘 · 📚 Airflow 學習筆記 #8

DAG 寫好了、也可靠了,最後一哩是工程紀律:怎麼確定我的改動不會弄壞它,又怎麼把它安全送上 Production。 這篇講測試(把壞 DAG 擋在 merge 前)、部署(DAG 檔怎麼上環境、se…

#airflow#data-engineering#testing

非冪等:INSERT 附加 第 1 次:INSERT 6/18 → 中途失敗 重試:又 INSERT 6/18 一次 6/18 資料重複兩份 ✗重試把一次故障放大成資料污染 冪等:覆寫分區 第 1 次:覆寫 6/18 分區 → 失敗 重試:再覆寫 6/18 分區一次 6/18 分區一致 ✓跑幾次結果都一樣,重試安全

Airflow 可靠性實戰:冪等、重試、SLA 與告警

· tech · 約 5 分鐘 · 📚 Airflow 學習筆記 #7

前面幾篇教你把 DAG 寫出來、排對區間。但 Production 的 DAG 是會在半夜出事的——來源系統延遲、網路抖一下、下游資料庫重啟。這篇講怎麼讓 DAG 扛得住失敗、能自己救、真救不了會大聲…

#airflow#data-engineering#reliability

key 落哪台:CRC16 → 16384 slot → node key:「user:1000」 CRC16(key) % 16384= slot 5798 Node Aslot 0 – 5460(+ 一個 replica) Node B ✓slot 5461 – 109225798 在這 → 由 B 保管 Node Cslot 10923 – 16383(+ 一個 replica) 16384 個固定 slot 是「中間層」,node 只是認領一段 slot 所以搬資料 = 搬 slot;擴縮容乾淨可控,不必重算全部 key 的位置

Redis Cluster:16384 個 slot 怎麼分片與擴縮

· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #10

單執行緒那篇說過,一台 Redis 的瓶頸是記憶體與網路。當一台裝不下、或流量頂到單機上限,就要把資料分片(sharding)到多台——這就是 Redis Cluster。但它的分片方式很有個性:不用…

#redis#distributed-systems

Sentinel 自動故障轉移的五步 ① 監控一直 ping master與 replica ② 主觀下線某個 Sentinel覺得沒回應(SDOWN) ③ 客觀下線過半同意「真掛了」(ODOWN) ④ 選出 Sentinel leader → 挑 replica 升主選一個最完整的 replica 升為新 master其餘 replica 改指向新 master ⑤ 通知客戶端新 master 位址 客戶端向Sentinel 問「現在誰是master?」

高可用:Sentinel 怎麼自動故障轉移

· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #9

上一篇的主從複製給了你副本,但留了一個大洞:master 掛了,不會自動有人接手。 你得半夜爬起來,手動把某個 replica 升成 master、把其他 replica 改指向它、再叫所有客戶端換位…

#redis#high-availability

一個 master 寫,多個 replica 讀 應用程式寫走 master、讀走 replica Master讀寫・單一寫入點只有一個 寫 Replica 1只讀 Replica 2只讀 非同步複製 讀讀流量分散到各 replica → 水平擴展讀

主從複製:讀寫分離與複製延遲的怪現象

· tech · 約 4 分鐘 · 📚 Redis 學習筆記 #8

一台 Redis 再快也有記憶體與流量的上限,而且它一掛,資料就懸在半空。走向高可用的第一塊地基,就是主從複製(replication):一個 master 負責寫、若干 replica 各複製一份、…

#redis#distributed-systems

看似無狀態的組件,真狀態藏在一顆 metadata DB Scheduler解析 DAG、排 task無狀態・可重啟 Webserver那個 UI無狀態 Worker × N執行 task可多開・可重啟 Metadata DB(Postgres)真狀態・命門 組件掛了都能換;DB 掉了 = 整個系統的記憶歸零(哪些跑過、誰在跑、誰失敗) 連多個 scheduler 的 HA,都靠對這顆 DB 上鎖(row lock)來協調

Airflow:排程器、worker 與那個藏起來的狀態

· tech · 約 6 分鐘 · 📚 從 Infra 角度看資料工具 #7

上一篇埋了個伏筆:每個系統都有一塊逃不掉的狀態,認出它就掌握了命門。 Airflow 是這句話最好的示範。它表面上全是看似無狀態、可重啟的組件——scheduler、webserver、worker,…

#infrastructure#airflow

取得鎖:一行原子命令 SET lock:res <token> NX PX 30000 NX只有 key 不存在才設→ 互斥 PX 30000自帶 30 秒 TTL→ 持有者掛了也自動釋放,不死鎖 <token>隨機值→ 標記「這把鎖是我的」 釋放鎖:要驗 owner(Lua,原子) if GET(key)==token then DEL(key)GET 與 DEL 必須原子 → 只刪自己的鎖 直接 DEL 不驗 token→ 誤刪別人續租的鎖 ✗

分散式鎖:從 SETNX 到 Redlock,與那場著名的爭議

· tech · 約 5 分鐘 · 📚 Redis 學習筆記 #7

多個行程、多台機器要搶同一個資源(同一時間只准一個人扣庫存、跑一個排程),就需要一把分散式鎖。Redis 因為快又原子,常被拿來當這把鎖。但這是個「看起來三行就能寫完、其實坑深到見底」的題目——一路踩…

#redis#distributed-systems

無狀態運算:算在叢集內,狀態在叢集外 資料源S3/DB/Kafka 輸出 sink寫回結果 Spark app(叢集內) Driver 協調 · 單點命門 Executor短命可拋 Executor短命可拋 Executor短命可拋 讀 寫 executor 掛 → 靠 lineage 重算那一塊,不丟資料;真正 durable 的資料全在叢集外 對比前三篇:狀態 = 服務本體;Spark:狀態借外部,自己近乎無狀態

Spark:短命 executor 的彈性運算

· tech · 約 5 分鐘 · 📚 從 Infra 角度看資料工具 #6

前三篇(Kafka、Redis、RabbitMQ)都在光譜的 stateful 那一端——狀態綁在自己的磁碟或記憶體,擴縮要搬資料、故障要救資料。這篇翻到光譜的另一端:Spark,系列第一個 stat…

#infrastructure#spark

同一個 app 一堆 YAML 九成內容共用 Developmentreplicas:1 · image:app:dev · 資源小 · host:dev.local Stagingreplicas:2 · image:app:rc · host:stg.example.com Productionreplicas:10 · image:app:1.4 · 資源大 · host:example.com

打包與部署:Helm 與 Kustomize

· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #14

前面每一篇都在教你寫 YAML,但實務有個逃不掉的痛:同一個 app 要上 Development、Staging、Production,而三個環境九成的 YAML 一模一樣,只有幾個地方不同——副本…

#kubernetes#operations

① 排程到 nodeScheduler 挑一台 ② 拉映像檔kubelet 去 registry 拉 ③ 起容器・活著跑起來且不崩 ④ Ready・進 Endpoints通過 readiness 才收流量 ✓ 正常收流量 Pending資源不足 / taint 沒 toleration / PVC 綁不到 ImagePullBackOff · ErrImagePull映像名打錯 / 私有 registry 少 imagePullSecret CrashLoopBackOff · OOMKilled起來就掛一直重啟 / 超過記憶體 limit 被砍 Running 卻 not Ready · 連不到readiness 失敗 / Endpoints 空(selector 錯)/ DNS 解不到 / NetworkPolicy 擋掉

故障排除:Pod、Node、Control Plane 怎麼查

· tech · 約 7 分鐘 · 📚 Kubernetes 學習筆記 #13

CKA 佔比最高的一塊是故障排除(30%),但它其實不是新知識——它是把前面整個系列串起來的能力。排障最忌諱用猜的、亂試一通。真正的心法只有一句:沿著 Pod 的生命週期,一關一關問「它卡在哪」——因…

#kubernetes#troubleshooting

Control Plane node · kubeadm init api-server scheduler controller-mgr etcd 都是 static pod:kubelet 讀 /etc/kubernetes/manifests 拉起來就自動維持 吐出 join token + 指令 kubeadm join <token> Worker node只跑 kubelet + 你的 Pod Worker node要幾台加幾台 再加 CP node(join)→ HA control plane

叢集管理:kubeadm、etcd 備份、升級

· tech · 約 5 分鐘 · 📚 Kubernetes 學習筆記 #12

前面十一篇都站在「用叢集」的位置。這篇換到「建與養叢集」的位置——CKA 佔 25% 的 Cluster Architecture 裡最硬的 ops 活。三件事貫穿一個管理員的一生:怎麼把一堆機器變成…

#kubernetes#operations

kubectl / Pod 發一個請求 ① 認證 authn 你是誰? 憑證 · token · OIDC ② 授權 authz 你能做這動作嗎? ← 這就是 RBAC 執行 API Server 驗不出身分 → 401 沒權限 → 403 兩道門各管一件事:先確認「你是誰」,再判斷「你能不能」

RBAC:誰能對叢集做什麼

· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #11

前面十篇都在讓東西「跑起來、連得到」。這篇換一個維度:誰有權對叢集下命令? 一個 kubectl delete 打進 API Server,它憑什麼知道你是誰、又憑什麼准你刪?這是 RBAC(Role…

#kubernetes#security

預設:任兩顆 Pod 都通 web api db 全通 = 沒有隔離 web 也連得到 db 套一條只保護 db 的 policy web api db預設拒絕 ✓ ✗ web 被擋 db 只放行 api;web↔api 沒被選中,照舊全通

NetworkPolicy 與 CNI:Pod 之間的防火牆

· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #10

Service 與 Ingress 講的是「流量怎麼找到服務」,但底下有個更基本、也更容易被忽略的問題:Pod 跟 Pod 之間,預設能不能互通? 答案會嚇到很多人——預設全通,任何一顆 Pod 都連…

#kubernetes#networking

使用者 一個網域 一個對外 IP GET shop.com/api Ingress L7:讀 HTTP 的 Host + path shop.com/ shop.com/api img.shop.com 順便在這裡卸 TLS(https → http) web-svc ClusterIP → web Pod api-svc ClusterIP → api Pod img-svc ClusterIP → img Pod 一個 IP、一個入口,按網址分流到多個內部 Service —— 這是 L4 的 Service 做不到的

Ingress 與叢集 DNS:一個入口進來、一個名字相認

· tech · 約 6 分鐘 · 📚 Kubernetes 學習筆記 #9

第四篇給了短命 Pod 一個固定門牌 Service,但留了兩個尾巴:一是「外面怎麼用一個入口進來、再按網址分流到不同服務?」——那張對外類型圖裡最上面的 Ingress;二是叢集內服務彼此互打時,那…

#kubernetes#networking