透過 Kubernetes 安裝 Prometheus 跟 alert manager

-
環境
 - Ubuntu 16.04
 - Kubernetes 1.6
 - Prometheus 1.6

 前兩篇介紹完kubernetes的安裝，接下來，介紹一下monitor的工具 - Prometheus
嗯....其實沒有要介紹，是要直接講Prometheus中alert manager的安裝

 先簡單說明一下，要怎麼安裝Prometheus
首先，準備兩個yaml檔，一個是起Prometheus container，一個是設定檔
prometheus-deployment.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
  labels:
    name: prometheus
  name: prometheus
spec:
  selector:
    app: prometheus
  type: NodePort
  ports:
  - name: prometheus
    protocol: TCP
    port: 9090
    nodePort: 30900
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: prometheus
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      name: prometheus
      labels:
        app: prometheus
    spec:
      containers:
      - name: prometheus
        image: quay.io/prometheus/prometheus:v1.6.0
        args:
          - '-storage.local.retention=6h'
          - '-storage.local.memory-chunks=500000'
          - '-config.file=/etc/prometheus/prometheus.yml'
          # 這一段是alert manager設定給prometheus的位址
          - '-alertmanager.url=http://<master ip>:9093'
        ports:
        - name: web
          containerPort: 9090
        volumeMounts:
        - name: config-volume
          mountPath: /etc/prometheus

         # 這一段是 alert manager 要吃的rules
        - name: config-volume-alert-rules
          mountPath: /etc/prometheus-rules

      # 這一段是 alert manager用的
      - name: alertmanager
        image: quay.io/prometheus/alertmanager:v0.6.0
        args:
        -  '-config.file=/etc/prometheus/alertmanager.yml'
        volumeMounts:
        - name: config-volume-alertmanager
          mountPath: /etc/prometheus

      volumes:
      - name: config-volume
        configMap:
          name: prometheus
      
      # 這一段是 alert manager 要 mount 的路徑
      - name: config-volume-alertmanager
        configMap:
          name: prometheus-alertmanager
      - name: config-volume-alert-rules
        configMap:
          name: prometheus-alert-rules

如果只是要安裝Prometheus，上面註解的那四段可以不用
縮排不能亂縮，會出事，請小心
prometheus-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus
data:
  prometheus.yml: |-
    # my global config
    global:
      scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
      evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
      external_labels:
          monitor: 'codelab-monitor'

    # Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
    rule_files:
       # 這一段是讓Prometheus知道，alert的rule在哪
       - '/etc/prometheus-rules/alert.rules'

    scrape_configs:
        - job_name: 'prometheus'
          static_configs:
            - targets: ['localhost:9090']

        - job_name: etcd
          static_configs:
            - targets: ['<ETCD_IP>:2379']

        - job_name: 'kubernetes-apiservers'
          .
          . 
          .
. . .的部分請直接參照官方文件

 兩個yaml編輯好後，切到這兩個檔案的目錄下，執行
kubectl create -f prometheus-configmap.yaml
kubectl create -f prometheus-deployment.yaml
Prometheus雖然裝好了，但還需要搜集資訊的人，就是node-exporter
node-exporter-deployment.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
  labels:
    app: node-exporter
    name: node-exporter
  name: node-exporter
spec:
  clusterIP: None
  ports:
  - name: scrape
    port: 9100
    protocol: TCP
  selector:
    app: node-exporter
  type: ClusterIP
---
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  template:
    metadata:
      labels:
        app: node-exporter
      name: node-exporter
    spec:
      containers:
      - image: quay.io/prometheus/node-exporter:0.12.0
        name: node-exporter
        ports:
        - containerPort: 9100
          hostPort: 9100
          name: scrape
      hostNetwork: true
      hostPID: true

 再把exporter啟動，就大功告成！
kubectl create -f node-exporter-deployment.yaml
我們在啟動Prometheus時，也順便把alert manager啟起來了
接下來，就是alert manager程式本身的設定檔跟alert rules的設定檔
alert-manager-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-alertmanager
data:
  alertmanager.yml: |-
    global:
      # The smarthost and SMTP sender used for mail notifications.
      smtp_smarthost: 'localhost:25'
      smtp_from: 'serviceadmin@yyy.com.tw'

    # The root route on which each incoming alert enters.
    route:
      receiver: 'pager_duty'
      group_by: ['alertname', 'cluster']
      group_wait: 30s 
      group_interval: 5m
      repeat_interval: 3h

      routes:
      - match:
          service: backend
        receiver: pager_duty
        continue: true

    inhibit_rules:
    - source_match:
        severity: 'critical'
      target_match:
        severity: 'warning'
      # Apply inhibition if the alertname is the same.
      equal: ['alertname']

     receivers:
    - name: 'pager_duty'
      pagerduty_configs:
      - service_key: xxxxxxxxxxxxxxxxxx
也可以參考官方的設定

 再來，最重要的alert 的 rules
alert-rules-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-alert-rules
data:
  alert.rules: |-
    ## alert.rules ##
    #
    # CPU Alerts
    #
    ALERT HighCPU
      IF (100 - (avg(irate(node_cpu{job="kubernetes-service-endpoints",mode="idle"}[1m])) BY (instance) * 100)) > 80
      FOR 10m
      ANNOTATIONS {
        summary = "High CPU Usage",
        description = "This machine  has really high CPU usage for over 10m",
      }
    #
    # DNS Lookup failures
    #
    ALERT DNSLookupFailureFromPrometheus
      IF prometheus_dns_sd_lookup_failures_total > 5
      FOR 1m
      LABELS { service = "frontend" }
      ANNOTATIONS {
        summary = "Prometheus reported over 5 DNS lookup failure",
        description = "The prometheus unit reported that it failed to query the DNS.  Look at the kube-dns to see if it is having any problems",
      }

這邊有兩個規則的例子，至於語法及細節，需要參考官方文件



至於這兩個設定檔要怎麼讓alert manager吃到，必須在alert manager啟動前，就先建立好，因此最終的順序為
kubectl create -f prometheus-configmap.yaml
kubectl create -f alert-manager-configmap.yaml
kubectl create -f alert-rules-configmap.yaml
   
kubectl create -f prometheus-deployment.yaml
kubectl create -f node-exporter-deployment.yaml

但是，這樣是不是很麻煩，每次改條件，就要重新設定alert-rules-configmap.yaml，而且還需要去了解rule的語法，事情都做不完了，還有空去學這個...@@
所以，下一篇要介紹Grafana，把Prometheus的資料導到Grafana裡，利用Grafana的UI來建立alert rules跟notification
參考文件: http://blog.wercker.com/how-to-setup-alerts-on-prometheus

留言

張貼留言

這個網誌中的熱門文章

瑞士滑雪分享2 - 策馬特

-
圖片
本篇同 上一篇 ，只介紹滑雪資訊，關於觀光資訊，就不在這裡詳述 一樣，我們先來介紹策馬特/馬特洪峰，這裡一樣是分兩區，Zermatt跟International，如下圖，左邊紅色框是 Zermatt ，而 International 是Zermatt+Italy，也就是 全山卷 ，在Zermatt賣的就這兩種票 在這我一樣只有滑兩天，就只買了Zermatt的票，所以不要再問我買International需要不要護照之類的問題，我不知道阿~~ XD 我住在Zermatt，這個鎮還滿大的，所以在挑住宿的時候需要注意一下，Zermatt的住宿非常的貴，比Grindelwald貴上許多，所以也有人選擇住下面的小鎮，再坐火車到Zermatt，至於住哪個小鎮或是便宜多少，我沒有研究，就不知道了。Zermatt火車站一出來，就有往山上的小火車，所以住下面的小鎮要上山滑雪，也算滿方便的。 Zermatt雪場分三區，最左邊Rothorn，中間Gornergrat，最右邊Matterhorn Glacier Paradise。 Rothorn ：要搭小火車上山，滿特別的，詳細介紹可參考 這篇網誌 ，離Zermatt火車站約10分鐘的路程。 Gornergrat ：一出火車站，對面就是車站了，小火車直接拉到山頂，相當方便 Gornergrat車站 Matterhorn Glacier Paradise ：上山纜車離市區相當遠，走路大約要20-25分鐘（有接駁巴士），需要轉2次纜車才能到山頂，要花不少時間，山頂非常冷，滑道很平緩，又冷又不好玩 三座山基本上可以互通，不需要回到小鎮再上山。這裡高度大都在2000-3000公尺，所以雪況比少女峰好很多，不過相當多的平路，對snowborders相當不友善....。 完整的地圖可參考： Zermatt ski map 雪票價格如下，這裡的雪票是用磁卡，所以會有5CHF的押金，最後記得去退（像我就忘了...@@） Zermatt/International ski pass (2014/15) ： Zermatt International (Zermatt - Cervinia) Days Adults You...
閱讀完整內容

東京藍帶 - 料理中文密集班Q＆A

-
圖片
前言 ： 關於一些東京藍帶基本的問題，這裏有前輩整理的網誌- 【東京藍帶】ＦＡＱ常見問題總整理 ，可以先參考 巴黎校藍帶可參考 安東尼 的網誌，裡面也有不少食譜，喜歡做菜的人也可以看看 這裡是 東京校區 的網頁，裡面有課程簡介, 上課時間還有學費等相關資訊，關於報名及有相關的問題都可以直接寫信問學校，學校懂中文的處理人員，所以寫中文即可 本文 ： 網路上關於東京校的料理中文班，資訊頗少的，所以在這裡分享一下，上面兩篇網誌所沒有，而且當初也困擾我的疑問。 東京校料理中文班（以下簡稱料理班或東京校），分成基礎,初級,中級跟高級四期，國外似乎只有三期，沒有基礎（但每一期課程的堂數也比較多），在東京校每一期是22堂課，每一期是六週，所以每週3-5堂課，每一期的排課狀況不一樣，每週確切堂數就要看當時的安排了。 在報名的時候分成「文憑課程」跟「證書課程」，兩種課程基本上是一樣的，唯一的差別是「文憑課程」是一次報四期，而「證書課程」不是，只是名稱上的差別而已，但是在報名的優先權上，「文憑課程」會比「證書課程」優先權高，也就是「文憑」沒滿，才輪得到「證書」報 上課方式，前三個小時是老師示範，大家坐在下面抄筆記，有需要時老師也會叫大家到台前近距離觀看。老師不時地會請大家拍照，拍食材,拍烹煮的狀態，拍最後的擺盤等等，所以相機很重要。後三個小時是實作，到目前為止（我目前還在基礎課程），都是獨自一人完成料理，然後每堂實作課最後成品都要打分數，佔總成績的45%。 料理班主廚是日本人，前幾期都是以兩位日本老師為主，到後期總監（法國人）才會為主。不過狀況每年可能都會變，參考看看就好 上課狀況，來這裡有八成的人都是要投身餐飲業的，所以老師會以在餐廳的水準來要求大家（跟老師風格也有關），因此實作課還滿緊繃的，尤其是對於比較沒經驗的同學。 有不少人好奇，沒經驗可以來上嗎?? 基本上是沒問題的，老師也說過，課程的編排就是針對沒經驗的人，但是實際進廚房，沒經驗的人壓力會大很多，建議來之前，最好在家多熟悉一下刀跟熟悉做菜程序的編排（簡單來講，就是同時煮兩道菜，一邊備料，一邊煮，要同時能夠兼顧兩邊）。 置物櫃，每個人有兩個，一個固定的，上面會有你的名字，東西可以放在裡面過夜（不過很小...）。另一個是放衣物的，下了課就要清空 最後，分享一下我住的民宿 Tokyo Hou...
閱讀完整內容

簡單聊聊ECDSA與Ethereum的sign message

-
圖片
    本篇不會牽涉到數學公式或是算法，只是簡單解釋格式上的差異     在我們應用中，會有兩個場景需要對訊息做簽章的動作，一個是簽章完送到smart contract裡用ecrecover做身份確認，另一個是單純把訊息（例如：個人資料）做簽章，確保訊息確實是本人的（就像簽名一樣）。     我們產品中會有iOS, Android或是後端的C#或JAVA，每種語言對ECDSA的使用方式都有所不同，有原生也有third party library，加上Web3也有提供sign message的功能，一開始大家一知半解，不太知道差異，所以在開發的時候，搞得人仰馬翻。 本篇就是針對標準ECDSA跟Web3提供的sign message做一點“ 簡單” 的解釋 。     首先，你要先知道 r s v，不用知道他背後的意義（因為我也不清楚 ＸＤ），但是你需要知道sign（本篇的sign都是指ECDSA）過的message可以被分解為 r s，咦？！ 說好的 v 勒？？ 先破題， 這就是標準ECDSA跟Ethereum用來可以recover signed message的差異 （其實Ethereum是沿用Bitcoin的）。     在ECDSA sign完的訊息可以分解成 r 跟 s ，不過只靠rs所反解的public key會有四組，不過實際上大家都只看兩組，因為另外兩組出現機率很低， 這篇解答 中的推文有解釋。 27 = lower X even Y. 28 = lower X odd Y. 29 = higher X even Y. 30 = higher X odd Y. Note that 29 and 30 are exceedingly rarely, and will in practice only ever be seen in specifically generated examples. There are only two possible X values if r is between 1 and (p mod n), which has a chance of about 0.0000000000000000000000...
閱讀完整內容