iT邦幫忙

opentelemetry相關文章
共有 97 則文章
鐵人賽 AI Engineering DAY 30

技術 Final:把那本一直被引用的書,一次攤開,再溫習一次

這系列引用最多次的東西不是 spec,也不是哪個 repo是一本書的四個名詞今天把那四個名詞放回它們原本的位置 前一天在盤點「要盯 agent 哪些維度」的...

鐵人賽 AI Engineering DAY 30

技術 Day33:回到第一天那組題目

/healthz 說它活著/todo 裡躺著一筆信心 0.9 的答案而那個答案,我剛好知道是錯的 Day33 已經用「我們下個系列見」收尾了,這篇不算在三十...

鐵人賽 AI Engineering DAY 30

技術 Day32:一個對的診斷,配一個沒用的處置

它說對了原因然後提議了一個就算執行也不會有用的處置而報表上這叫做一次成功的調查 前面講校準那天說過,能填 correct 那個欄位的只有兩種來源,人或是在已...

鐵人賽 Kubernetes DAY 19

技術 Day 19:自動與手動 instrumentation:把 trace 埋進示範服務

今天是這 30 天唯一要認真寫程式的一天。 instrumentation(埋點)的意思是在程式裡加上產生遙測資料的程式碼。它分自動和手動兩種,我兩種都會用,因...

鐵人賽 Kubernetes DAY 18

技術 Day 18:OpenTelemetry 的設計理念與 Collector 架構

昨天講了 trace 的原理,今天講產生它的工具:OpenTelemetry,通常簡稱 OTel。 這篇要回答三個問題:它為什麼會出現、它包含哪些東西、還有那個...

鐵人賽 Kubernetes DAY 1

技術 Day00:把技術棧串起來

今天的工作 說明這個專案在做什麼 簡單介紹作者 為什麼要做這個專案 這個專案怎麼設計 這個專案在做什麼 這個專案的核心是一套系統,由多個技術棧組成,包含:A...

鐵人賽 AI Engineering DAY 30

技術 Day31:空結果不是證據,而這件事不能靠勸的

一句查不到東西的查詢跟一句查到東西的查詢在對話紀錄裡長得一模一樣而只有其中一句可以拿來下結論 昨天那篇的最後一句是「紅的理由沒有一句是模型不夠強」。我本來以...

鐵人賽 AI Engineering DAY 29

技術 Day30:量錯四次,時鐘、排練、一次錯的更正,跟那支查它們的探針

一個壞掉的量測不會像壞掉的服務那樣叫它會給你一個數字而且那個數字通常很好看 前面把整套東西都做完了:提案有狀態、演習分得開、五道門各自問自己的問題、案例記憶...

鐵人賽 AI Engineering DAY 28

技術 Day29:案例記憶與閉環,第八次發生時它記得什麼

「這個我們上次遇過」是一個資深值班的人最值錢的一句話而這套系統一開始連「上次」是什麼時候都認不出來 前面把五道門攤開之後,有一個東西一直在旁邊沒被處理:這隻...

鐵人賽 AI Engineering DAY 27

技術 Day28:五道門,那個 0.9 憑什麼算數

信心分數是推理平面自己講的治理平面沒有義務相信它這句話聽起來很酸但它是第一道門的全部內容 昨天那輪演習跑完,agent 對同一個事故給的信心是 0.65。前...

鐵人賽 AI Engineering DAY 26

技術 Day27:提案是一列會自己走完的狀態,而演習決定那列數不數

「建議回滾 payment-service」是一句話一句話沒有狀態、不會過期也沒有辦法在事後回答那天到底是誰按的 昨天把四個平面跟那條從建議到自主的光譜攤開...

鐵人賽 AI Engineering DAY 25

技術 Day26:建議之後呢,四個平面跟一條沒有人走完過的光譜

一個沒有人按過的開關跟一個不存在的開關平常看起來完全一樣只有在事故當下才分得出來 昨天用第一天那組題目重算了一次總分,把前面那條「治理 → 資料 → 判斷」...

鐵人賽 AI Engineering DAY 24

技術 Day25:整條鏈跑一次,然後用第一天那組題目算總帳

每一段單獨跑都是綠的這句話跟「整條鏈是通的」中間隔著一次真的把它們接起來 前面二十四天,每一天都在自己那一段裡驗證自己那一段。今天要把它們接起來跑一次:一個...

鐵人賽 AI Engineering DAY 23

技術 Day24:從使用者那一側看回來,四個角度各量一次

前面二十三天我一直在驗證那條沒有人在看的路徑而真正會被用的那一條缺假設樹、缺信心分數、缺一顆按鈕還缺一張帳單而我自己去用的時候拿到一個答得很漂亮的錯答案 昨...

鐵人賽 AI Engineering DAY 22

技術 Day23「建議回滾」不是建議,「回滾會換掉這兩個 pod」才是

一句「建議回滾」跟一句「回滾會換掉 demo 這兩個 pod,回到 revision 24」差的不是禮貌,是對方能不能決定 前面幾天都在處理「agent 講...

鐵人賽 AI Engineering DAY 21

技術 Day22:一個查得到東西的介面,跟一個真的在看的守門

一個回空表格的查詢跟一個看不到三成輸入的守門在紀錄上都是一切正常 昨天新加的那個 fixture 兩次都失敗,兩次都是同一個動作:一句查詢回空的,然後它換一...

鐵人賽 AI Engineering DAY 20

技術 Day21 把量尺修好,然後讓 fixture 去讀逐字稿

一份漂亮的結論跟一場漂亮的調查在報告上長得一模一樣 昨天那場 RCA 跑得很好看,四次工具呼叫、假設樹有列、工具報錯自己救回來,最後結論指名 v2.5.0...

鐵人賽 AI Engineering DAY 19

技術 Day20:決策鏈實際跑起來長什麼樣

我本來想量的是這隻 agent 表現如何先量到的是自己那把尺上面刻著答案 昨天畫了 agent.py 那張四個 node 的圖,但沒有拆它。今天把它跟實際的...

鐵人賽 AI Engineering DAY 18

技術 Day19:從一問一答,到一隻會自己查東西的 agent

選一個框架而不是自己寫迴圈換到的往往不是功能是有一天要跟別人解釋的時候講得出來 前面七天都在處理同一件事:讓資料本身帶著足夠的上下文。昨天把 CEL(Con...

鐵人賽 AI Engineering DAY 17

技術 Day18:這一階段做到哪裡,沒做到哪裡

蓋完一層之後最誠實的動作是把它還不是什麼一格一格數出來 昨天把 CEL(Context Enrichment Layer,情境豐富層)的三個職責跟溯源攤開來...

鐵人賽 AI Engineering DAY 16

技術 Day17:訊號跟情境的差別,僅是 JSON 欄位的差別?

一個裸值加上一個時間戳撐得起「發生了什麼」撐不起「該不該做什麼」 前兩天在補「圖走不走得到」「契約有沒有名字對得上」,這篇往下再挖一層,問一個更底層的問題:...

鐵人賽 AI Engineering DAY 15

技術 Day16 順著圖走:221 條 series 裡,只有兩條能判生死

順著圖走的前提是圖上每個節點都判得動而這個前提在真實環境裡不成立 昨天把契約這件事情管好了,等於把注入的 context 降噪,⚠ 從兩個變一個而且帶著證據...

鐵人賽 AI Engineering DAY 14

技術 Day15 兩條平行線接起來:讓 registry 管得到 agent 讀的東西

一個回傳空集合的檢查可能是在說「沒有問題」也可能是在說「我根本沒讀到」而這兩句話印出來一模一樣 昨天把那張宣告的拓撲跟 Tempo 裡真的看得到的呼叫關係對...

鐵人賽 AI Engineering DAY 13

技術 Day14 那張架構圖準不準? 跟一份 100% 的報告為什麼是壞的

一張沒有人驗過的架構圖跟一張畫錯的架構圖在會議室的投影幕上長得一模一樣 昨天那張九宮格,中間「對帳」那一欄三格全是空的,而其中一格的具體長相是這樣: $ u...

鐵人賽 AI Engineering DAY 11

技術 【Day12】驗證檢查還在擋,跟一份會自己跑的上線 checklist

你要驗證的不是它會不會通過是它還會不會擋而一份檢查只會在壞掉的東西上顯現自己的 bug 前面做出了一堆會擋人的東西:三條命名規則、一道 CI gate、li...

鐵人賽 AI Engineering DAY 10

技術 Day11:機器可讀的意圖,讓 registry 說得出「為什麼」

這個欄位有哪些值,registry 答得出來哪一種值代表「這個服務是好的」目前只寫在 dashboard 標題跟幾個人的腦子裡 昨天把 registry 開...

鐵人賽 AI Engineering DAY 9

技術 Day10:來把 registry 交到 AIOps agent 手上

前面做的治理讀者一直只有兩種,人跟 CI今天加第三種 這個階段前面做的每一件事,都是為了讓 registry 裡的東西可信:命名有規則、PR 有 gate、...

鐵人賽 AI Engineering DAY 8

技術 Day9:breaking change,diff 看得到的跟它看不到的

改名字會被看見改名字底下的內容物不會而後者才是會把下游打死的那一種 昨天把 registry 疊成兩層,也留了一個問題:平台團隊改了 base 裡的一個定義...

鐵人賽 AI Engineering DAY 7

技術 Day8:分層與所有權,哪一層統一哪一層放手

治理的難處從來不是「要不要統一」是「哪一層統一,哪一層放手」前者是立場,後者才是設計 昨天 live-check 對著 service.name 說「這個屬...

鐵人賽 AI Engineering DAY 6

技術 Day7:治理成為大門,CI gate 與 live-check 守在兩個時間點

規則存在跟規則會被執行中間差的東西比想像中多 昨天那三條 Rego 規則跑出 9 個違規、離開碼 1,把 userId 跟 user_id 並存這件事抓了出...