Day28時提到, K6能與很多東西相互整合或轉換.
下圖就是一個官方有提供的一些工具,
能協助開發者來加入體驗K6, 透過Converter
的協助.
團隊有在寫OpenAPI的話, 也有提供Converter能轉成K6 Script
也能整合於CI流程之中
用來轉Postman的collecto成K6 script.
安裝 postman-to-k6
sudo npm install -g @apideck/postman-to-k6
到昨天git clone下來的K6資料夾的samples內
新增一個資料夾postman-to-k6
把這裡的Postman Collection的範例json file, 給複製到這folder下
如下圖
我們先來透過Postman看看這echo.json collection的結構
能看到左邊在該Collection下有幾個Folder, 裡面各自有request.
每個requests內又有Test cases.
像第一個Folder叫做Auth:Diget
裡面有兩個requests, 第一個叫做DigestAuth Request.
裡面又有兩個test cases,
大概都是這樣的結構!
我們就能來執行postman-to-k6了
執行postman-to-k6, 將k6 script檔案輸出命名成k6-echo-test.js
postman-to-k6 echo.json -o k6-echo-test.js
會在底下多產出libs資料夾與剛剛指定輸出的k6 script
來跑K6做一下smoke test
docker-compose run -v \
$PWD/samples/:/script \
k6 run /scripts/demo/postman-to-k6/k6-echo-test.js --vus 1 --duration 10s
這次畫面開頭有點點不一樣囉,
多了好多資訊, 能留意紅圈內的資訊, 是不是跟Collection與底下資料夾名稱一樣, 裡面的test cases也照樣有, 底下一樣是summary data.
Postman-to-K6, 也是想做到讓一個test scripts, 能重複使用.
為了吸引Postman用戶也能來使用K6, 團隊推出一些converter, 來便於開發與測試團隊使用.
Postman也不那麼適合做昨天提到的Spike test.
但k6 script可以透過Stage+VU+Duration來輕鬆做到.
回過頭來看產出來的k6-echo-test.js的內容,
有一個功能要跟各位介紹的group
該Group叫做Auth: Digest, 內有2個test cases, 各自內有2個checks
group("Auth: Digest", function() {
postman[Request]({
name: "DigestAuth Request",
},
post(response) {
tests["response code is 401"] = responseCode.code === 401;
tests[
"response has WWW-Authenticate header"
] = postman.getResponseHeader("WWW-Authenticate");
});
postman[Request]({
name: "DigestAuth Success",
},
post(response) {
tests["response code is 200"] = responseCode.code === 200;
tests["body contains authenticated"] = responseBody.has(
"authenticated"
);
},
auth(config, Var) {
}
});
});
group能分類test cases用, 甚至能搭配Tag做出更多變化.
但這部份未來有機會在展示.
當有分類groups時, 在summary上會出現group_duration
的指標
但這裡我覺得顯示的不夠細緻.
我想順道介紹K6 Cloud
登入後來到CLI選單
能看到有一組很長的account access token, 複製它
小改一下昨天clone下來的K6專案內的docker-compose.yaml內容
改K6_OUT到cloud, 並給予cloud token
environment:
- K6_OUT=cloud
- K6_CLOUD_TOKEN={{your k6 cloud account token}}
再執行一次
docker-compose run -v \
$PWD/samples/:/script \
k6 run /scripts/demo/postman-to-k6/k6-echo-test.js --vus 1 --duration 5s
來到K6 Cloud左側的My First Project, 會出現k6-echo-test.js
的panel, 點進去
選擇HTTP, 右邊選擇Tree View後
就能看到各Group與各test case自己的summary
我們總會希望能在CI階段, 能把寫那麼多的API test script給跑一次.
如果有錯誤, 至少有錯誤的程式碼不會流入到更多人能看到的Branch上.
那要串接也不難, 照著案例走
將我們程式碼推上Github, 且建立workflow
指定好檔名與VU和Duration等參數就好
馬上就...因為不滿足thresholds而CI整合失敗QQ
也能參考範例, 改成輸出到cloud, 給它token就好,
結果我們就也能在K6 Cloud上看到了,
這對於每天排程做負載測試很方便, 能隔天上班再來分析結果.
name: Main Workflow
on: [push]
jobs:
build:
name: Run k6 test
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Run k6 cloud test
uses: grafana/k6-action@v0.2.0
with:
filename: my-load-test.js
flags: --vus 50 --duration 10s
cloud: true
token: ${{ secrets.K6_CLOUD_API_TOKEN }}
雖然完賽了, 但我知道...
我還一堆沒看完沒整合沒分享.
我盡量最近寫QQ
首先是Observability與OpenTelemetry
Observability希望達到讓整個系統, 可以透過各種維度的資料來讓團隊進行假設, 並且從中獲得分析後的答案, 進而成為已知的指標.
OpenTelemetry則是給了統一的規範以及一些API, SDK, Collector等的組件,
讓三種Telemetry data彼此都有相關連的tag, 能相互參考到彼此.
進而方便聚合資料, 且便於分析問題.
Grafana則是個相當優秀的儀表板服務, 提供非常全面的可視化功能,
也理解管理上的麻煩, 很多設定都能寫到Provisioning內, 達成Configuration As Code.
Loki則是Grafana Labs近幾年新推出的Log服務, 還提供了一個與PromQL結構與api相仿的LogQL, 讓團隊成員只要學習一套就好, 方便很多.
且還能把Log資訊透過LogQL的metric query轉成對應的metrics, 也是便於我們分析計算用.
最後提到K6, 是因為光有上面, 還是很可能在上線時才能發現一些性能與可靠性問題.
上面提到的很多都是應用在Monitor上.
那能否在Build以及Test階段, 就能驗證Plan階段時的系統可靠性與性能設計與假設呢?
K6就是個很棒很容易上手的工具.
我們能在Git husky做簡單的smoke test
佈署到UAT/Stage時, 跑其他種類測試, 或者半夜排程去跑,
隔天看報告多棒~
且K6又能配合Grafana顯示, 一套儀表板, 就能滿足很多DevOps這八字環的許多需求.
以前我呆的團隊, Log要跑去ELK看, 主機與性能要去Grafana看.
找問題兩邊跑QQ 現在只要學一套就好!!
還不立刻弄起來(?)
再次感謝大家, 明年再見~~
ps. 有公司缺菜鳥SRE工程師嘛
(?), 但後端與系統整合9年以上的:)
或需要後端系統工程師
, 有系統規劃與SLO規劃設計等經驗
履歷在這(揮手)
安全完賽~~~恭喜
但是雷N大還要繼續寫,超厲害~~
我已經像是馬拉松跑過終點線,癱軟在地....
雷N大像是跑過馬拉松終點還不夠,還要再繼續跑到另一個山頭,直到看到美麗的風景....
想多了, 只是繼續寫完這天就好(我標題打兩個名詞, 我才寫一個)
哈哈哈哈~~~
恭喜完賽~~
恭喜完賽!
哎不對 怎麼還在跑~
莫非是要執行 IT超馬賽XDDD
沒錯(等等 我只是覺得還沒交代完)
結果等到我完賽後,雷N大大都還在跑QQ
小心不要運動傷害呀~哈哈
hahaha 我懂 一起加油~