Hello Prometheus，這篇文章想聊聊對Metrics的理解，以及以Prometheus作為Solution的基礎介紹。Metrics作為可觀察指標之一，我們能透過對Metrics進行監聽，在達到警報閥值時告知工程師們，使工程師不需時時緊盯各項數據；更進階一點，也可以透過搜集不同層次的各項度量化資料聚合的成果，得到不同面向系統服務的狀態。

這篇文章會從什麼是Metrics、Indicator與Monitor，以及其之間的關聯開始說明，之後以CNCF畢業的項目Prometheus為例，簡單的演示如何透過Metrics觸發一個Alert的工作流程，可視化部分使用Grafana，這部分將在演示時做更多說明。那我們就開始這場Prometheus的冒險吧。Gogo!

大綱

• 度量(Metrics)、指標(Indicator)與監控(Monitor)
• Prometheus簡介
• 來點Coding壓壓驚：Web service與Prometheus的串接
• Grafana 可視化
• 結語

度量(Metrics)、指標(Indicator)與監控(Monitor)

度量(Metrics)

根據IEEE的定義，度量是對系統或軟體運行過程中某個特定屬性的定量測量或計數。從量身高體重的例子來看，度量可以是對單個資料的採集，也可以是對BMI超標的人的採集，端賴什麼對系統而言是重要的指標。假設對系統而言，重要的是觀察肥胖人口的比例，當超標時要發出警告，那BMI超標會是要採集的度量。

指標(Indicator)

指標是對度量結果的閾值，延續上一段的例子，就是要發出警報的時間點，當肥胖比例超過20%要發出警報，度量與指標的組合在生產過程中很常被用來作為報警(Alert)的觸發機制，透過自動化的報警機制，可以讓系統在不穩定的狀況出現時，通知開發人員。

監控(Monitor)

指標是對度量結果的判斷，而在軟體開發過程中，我們通常對異常狀況比較敏感，以網路服務來說，通常是對http status code 4XX的用戶端請求失敗，以及http status code 5XX的服務器異常錯誤特別敏感，但更好的做法是去判斷對用戶的影響程度，去做指標的設置，也就是說，不是每個500錯誤對客戶的影響都是等價的，更適切的指標是我們可以區分哪些是需要立即反應調整的，哪些是可以讓系統自己回復的。

在真實生產環境，為了對各個服務端點的可用性進行監控，服務指標不會是單一的或少量的，透過監控的可視化，聚合度量資訊，讓開發人員可以很容易地發現服務的狀況，並且透過日誌查詢與度量指標查詢定位問題，而解決問題。

小結

到此，我們聊到了度量與指標的定義，以及開發人員透過監控可視化可以達到的效果，本篇文章會從一個簡單的Web Service開始，透過CNCF孵化並且已經畢業的Prometheus採集度量指標，並搭配Grafana可視化。搭建一個簡易的模擬工作的場景，演示從度量到監控可視化的流程。

Prometheus簡介

上圖是Prometheus的架構圖，由數個組件構成，主要組件有Exporter、Prometheus Server、Alert Manager、WebUI。此外如果是生命週期較短的任務，可以部署Push Gateway，讓Prometheus Server可以拉取指定的Metrics，不會因為任務的消解造成資料遺漏。

• Exporter: 把Metrics的資料準備好在自己的一個server，Prometheus會定時scrape。
• Push Gateway: 這是Prometheus一個特殊的使用場景，如果我們在K8s建立Job或者Cronjob資源，他的LifeCycle可能等不到Retrieval來scrape metrics就被消滅了，Push Gateway可以想像是額外部署一個提供給Prometheus Retrieval拉取的節點，這樣就算Job消失還是可以等到拉取時間來拉資料。
• Prometheus Server: Prometheus的主要組件，有幾個小組件在這邊，包含Retrieval負責去抓取Exporter準備好的數據；TSDB Storage是Prometheus時序型的資料庫，就是Metrics資料持久化層；HTTP Server是提供給可視化端查詢Storage以及聚合的語句，透過promQL我們可以對metrics進行查詢以及聚合。
• Service Discovery: CNCF生態系的優勢，可以很好的跟K8s整合，簡單的配置便可以拉取K8s Pod跟資源的Metrics。
• Alert Manager: 可以針對metrics的聚合結果判斷是否達到Alert標準，並且通知指定的Alert下游，可以是Opsgenie或者Slack channel。
• WebUI: 可視化的部分可以透過Grafana或者Prometheus自己的前端，或者Thanos，透過PromQL對metrics資料進行搜索與聚合，並且將結果透過圖形可視化，讓開發者可以很快地發現問題或異常。
• Node Exporter: 搜集作業系統或Node相關的資料。
• cAdvisor: 搜集Container相關資料。

來點Coding壓壓驚

這個部分我們會創建三個組件，包含一個簡單的Web Service、Prometheus主體，以及Alert manager，讓我們在到達一定的Alert rule可以觸發自動通知。目錄結構如下～

Web Service

我們透過python flask準備一個簡單的Web Server，這個腳本有三個部分，第一個部分是Prometheus Metrics initialIze，這邊我們register了一個Counter Type的metrics，叫做request_count，顧名思義就是計數器，一旦觸發value就遞增；第二部分，Server有兩個Endpoints，包含測試的root endpoint，一旦有請求進來，就在Counter遞增一次。第二個端點是負責給Prometheus Retrieval scrape的endpoint，固定要叫做”/metrics”，每次Retrieval來要數據的時候，就會去generate最新的metrics的值。我在這邊透過兩個Metrics，讓我們更好看到request不同端點的metrics紀錄。

接著準備web service的Dockerfile，這邊我們很簡單的，內容主要是安裝相關依賴，並且把flask app啟動起來。

Prometheus

要部署prometheus，需要準備一個prometheus的config文件，文件會去定義要去哪裡抓資料，以及多久抓一次資料。這邊除了global的設定之外，我們針對每個job可以去scrape不同target的資料。這個案例中我們設定第一個會去”localhost:9090”，scrape prometheus的metrics，因為沒有設定抓取頻率，會套用全閾設定；第二個部分就是到剛剛我們準備的flask app中抓取metrics。

Alert manager

Alert manager讓我們可以在指定的metrics條件被觸發的時候，對指定的輸出端發出報警，讓開發人員可以及時處理系統的異常，這邊我們設定一個簡單的alert rule，當指定的metrics發生超過幾次之後，將錯誤噴到slack的指定頻道。

這裡我們準備一個alertmanager.yaml這邊設定通知相關的內容，因為我們要打到Slack，所以就是Slack channel的相關資訊。

此外，什麼時候會觸發alert機制，我們需要把相關設定寫在Prometheus下面的alert_rules.yaml文件，這邊為了等等方便測試，這邊Alert rule我們讓他出現兩個request count就觸發。

因為我們的觸發條件很低，所以只要手動去觸發就可以讓Alert Firing，這樣就成功發出一個alert啦～訪問http://localhost:9090/可看見Prometheus自帶的UI，透過PromQL查詢Metrics，以這邊的例子來說，透過api_called_counter_total{} 可以拿到api_called_counter的狀態，此外在Alert panel，可以觀察當前所有alert的狀態。

最後透過docker-compose把各個組件關聯在一起，我們可以得到以下的docker-compose文件，在local端跑起來只要透過docker-compose up，就可以把我們當前準備的測試案例跑起來啦～

到這邊我們基本上已經透過Prometheus蒐集application的Metrics，並且將這個Metrics加上alert rule，讓我們在系統異常時可以及時處理。但metrics不僅僅是如此，我們不僅可以被動地被通知問題，也可以透過Metrics的可視化，讓我們從更高層次發現問題。

Grafana監控可視化

這一段我選用Grafana作為Prometheus的可視化工具，但Grafana並非唯一選擇，Prometheus有自己提供的UI，在CNCF的生態中，Thanos也可以提供可視化的服務。而選擇Grafana的原因無他，他是開源的且對Cloud Native生態中是非常熱門且常用的選擇。

在docker-compose中加上Grafana的section，接著就可以直接在UI在綁定資料來源Prometheus，並且可以透過PromQL去查詢我們剛剛在測試案例中，製造出來的Metrics。

訪問localhost:3000，透admin/pass作為帳號密碼登入後可以到Grafana的默認頁面，這邊我們需要先加上一data source。

然後選取Prometheus~

如上述所說Grafana提供了可視化的支持，讓我們可以從不同角度觀察Metrics資料，並且可以更早的發現問題，可以依照需求在dashboard的部分自定義所需要的圖表，這個例子中我們僅僅import默認模板。

就可以到Explorer中透過PromQL查詢Metrics啦，使用體驗跟prometheus提供的UI非常相似，但是如前段描述的，Grafana還整合了Loki跟Tempo，讓我們可以在這個可視化介面上一次處理Log、Metrics，以及Tracing。

結語

本文到這邊已經告一段落，不過Prometheus的入門旅程才剛開始，這篇文章我們從度量與指標的定義開始，選了熱門的度量採集工具Prometheus以及可視化工具Grafana。並透過一個簡易的Web Service，演示了透過Prometheus搜集資料，最後到Grafana可視化的資料流程。

過去對工具的使用是很目的性的，透過撰寫文章的過程，我也對Metrics以及資料的流動與採集有更系統的理解，期待閱讀本文的你也有所收穫，如果文章中有錯漏歡迎留言告訴我，也歡迎跟我討論更多關於度量資料採集以及應用的有趣案例。

參考資料

• What are Software Metrics? Examples & Best Practices
• 什麼是 CNCF？及其帶來對 Cloud Native 社群的影響
• Overview | Prometheus

https://codertw.com/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/41476/

https://blog.techbridge.cc/2019/08/26/how-to-use-prometheus-grafana-in-flask-app/

Hello! Prometheus. was originally published in Starbugs Weekly 星巴哥技術專欄 on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS SAA是AWS推薦使用經驗約一年的運維工程師參與的認證，2020年7月C01版本走入歷史，現在的考生只能選考AWS SAA-C02，本文將分享本次準備三個月的讀書規劃，以及準備資源。

一、SAA C02考試介紹

關於證照的定位與背景，如果還不太清楚的小夥伴可以看上圖，或者讀讀這篇，非常易讀又清晰的介紹，本文將會針對改版後的差異說下。

(一) 考試比重調整：不容忽視的Design Cost-Optimized Architectures與Design High-Performing Architectures

最明顯就是Define Operationally Excellent Architecture被刪掉，比例分配到Design Cost-Optimized Architecture，其餘各項分配有稍許調整。調整後聚焦在Design Cost-Optimized Architectures與Design High-Performing Architectures兩個類別。

(二) 考試時間：130分鐘，65題

爬文發現過去C01分享，考試時間也是130分鐘，題數共65題，C02同樣是130分鐘，題數也同樣是65題(補充下，72%通過考試，比例計算大約要答對47題以上才會通過，但真實考試成績是100–1000分區間)。雖然提供其他語言的選項，但還是推薦考英文的，對非英語母語人士來說，可以在考試之前提前申請延長至多30分鐘。

(三) 考試內容

題型而言，就我個人感覺沒有太大差異，C02的考法仍然是提供情境，但在情境中指定客戶的期待(可能是成本節約或者效能優化)。但就選項而言，因為C02新增了更多服務，因此選項的排列組合更多了，需要對各個服務的使用場景有更多了解，不然很容易被帶偏。

方才有提到服務變多了，這邊列舉部分新增服務，因為服務變多了，選項的複雜度會相對提升，假設你不是每個服務都實際觸碰到，而且走AWS的BEST Practice，那需要花一些時間釐清以及了解新服務。

• AWS Global Accelerator
• Elastic Fabric Adapter (EFA)
• Elastic Network Adapter (ENA)
• AWS ParallelCluster
• Amazon FSx
• AWS DataSync
• AWS Directory Service
• High Performance Computing
• Aurora Serverless

二、考生背景介紹

半路出家的後端工程師，邊工作邊準備，加上考試準備時間有半年AWS服務使用經驗，有摸過EC2、ECS、RDS、ALB、NLB、Lambda、Elasticsearch、Elasticache、S3等服務，但工作上偏後端，對服務的了解程度自評中等，即使使用過的服務，在準備過程中仍然需要花時間去理解更細緻的設定。

三、準備資源跟規劃

(ㄧ) Udemy課程：第一個月掃過各個服務

我自己選了BackSpace在Udemy的證照課程，主要是當時Udemy有折扣，加上評價不錯就購入了，也很多人推CloudGuru的課程，課程的部分我感覺大家不用太糾結，因為對我來說這種長時間的課程不太可能看過一次就都記住，因此我在看的時候會針對各個服務做簡單的筆記，或者PPT截圖(這部分如果有想要的小夥伴可以私訊，我可以email給您交流下)。

因為定位是對AWS各服務的初步了解，所以我花了一個月看了BackSpace課程的第一個Section(共16小時，每週4小時)，中途有時間會跟著做Lab，如果沒有就跳過Lab，針對各個服務做筆記。

(二) Tutorial dojo：開始刷題，會一路刷到考試前

第二個月開始刷題，我是買Tutorial dojo SAA course(14.99$)，策略主要是去檢視自己在哪個部分理解的比較差，針對弱點再補強，剛開始刷題分數大概落在45%-60%之間，會越刷越熟悉。

第一週，從Topic based去確認我對單一服務哪些內容不熟悉；第二週開始每週做1–2回Time mode(這個模式是模擬真實考試，可以培養自己的臨場感)，每一回結束之後，Dojo都有準備詳解跟圖表，比較有系統的規整觀念，這次會非常仔細看過詳解。(因為review mode跟section mode題目跟time mode重複，但是測驗方式不同，所以我最後是考前才把它通通complete)。

整體而言，我覺得dojo在模擬考題的部分算是非常精準的，跟真實考題的長度跟敘事方式都非常相近，而且詳解跟圖表說明可以讓我省下大筆時間去歸納資訊。

(三) AWS FAQs

第二個月第二週開始，會加入AWS SAA考試指南提到的六個FAQ(EC2、S3、VPC、Route53、RDS、SQS)，每週1–2個，邊看會邊用自己的話解讀下每個問題，做筆記(這邊有需要的話也可以交流，主要是還沒整理好，所以還沒有放到github)。我花了一個月看過這些FAQs，然後持續做題，找題目練習到考試之前。

(四) DigitalCloud

這裡有免費的20題練習題可以做，他們也有提供課程，但我自己沒有購入，所以無法評價。

(五) Youtube

• 圖解程式教學 Sam Tsai：VPC跟network講得超級清楚，非常推薦。
• Digital Cloud Training：題目講解，剛剛上面有說有免費練習，這邊有講解的影片。
• freeCodeCamp.org：蠻認真的影片，坐車或睡前會聽下，對C02新服務的說明比較沒聽到，但還是不錯。
• Bart Castle：雲端服務講師提點C02更新的部分，整體來說就是上面提到的差異。

(六) Simulate exam

我有另外花20美金買模擬考試20題，整體而言我覺得跟實際考試題型相似度很低，但是如果覺得準備好的小夥伴可以嘗試下，難度比真實考試難。不過介面跟考試一模一樣，這點算是覺得比較值得的地方。測驗結束約半小時會收到答對比例，我自己做完拿到65%(13/20)。

四、考證照的好處

• 了解服務以及優化既有服務：準備過程會了解AWS官方推薦的做法，以及各個服務如何搭配組合，以滿足業務場景的需要。可以重新檢視下自己團隊服務，並期待在下次設計的時候可以做得更安全、更高效。
• SAA：證照本身也代表你對服務的了解程度，雖然因為現在不少人有，而且也很多厲害的人不用透過考試去證明自己，但對我來說算是這段時間學習的肯定。
• 架構設計：準備過程重新看了下系統設計的基礎知識，CAP、ACID，跟分散式系統設計，從AWS在設計時候的取捨，可以對應到過去比較生硬的知識，算是意外的收穫。

五、結論

首先曬下證照～ 最後考試以786分低空飛過，算是給自己從2021年一月初準備到2021年三月底的努力一個完美的頓號，畢竟學習之路漫漫，實非一紙可一概而論。一路走來要感謝我的同事，也是學習夥伴Ricki，跟我一起準備！

若本文有缺漏或錯誤可以留言跟我說～此外，如果需要不才筆記的小夥伴，我們可以email交流下。

• THE NEW 2020 AWS CERTIFIED SOLUTIONS ARCHITECT ASSOCIATE EXAM (SAA-C02)
• AWS Certified Solutions Architect — Associate (SAA)介紹以及準備心得
• 15 Top Paying IT Certifications In 2016: AWS Certified Solutions Architect Leads At $125K
• AWS Certified Solutions Architect - Associate SAA-C02 Exam Questions and Answers (3)
• AWS Certified Solutions Architect Associate Exam - SAA-C02 Study Path

AWS Certified Solutions Architect — Associate (SAA) C02 簡介與準備規劃分享 was originally published in 我想要變強 on Medium, where people are continuing the conversation by highlighting and responding to this story.