透過 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

留言

張貼留言

這個網誌中的熱門文章

What's New in Ethereum Serenity (2.0)

-
圖片
Ethereum 2.0 已經正式改名為Ethereum Serenity 原本預計在今年(2018)上線的Hybrid POS(Casper FFG)跟sharding，因為遇到一些技術上的困難，所以把Hybrid POS改成單純POS，然後因為sharding跟POS有部份技術是重疊的，所以把POS跟sharding併在一起做（本來是分成兩個team作開發） Beacon Chain 在Ethereum Serenity的規劃中，在原本的POW chain之外多一個鏈叫做 Beacon chain ，是一個POS chain。在Beacon chain中有兩種角色 proposer 跟 attester ，proposer就是產塊的人，attester是驗證的人。而在POW chain上存入32 ETH，可以成為Beacon chain上的 validator ，而validator有權利產塊(proposer)，也會有機會被選attester。此外，延續了Casper FFG finality這個概念，也就是在finality之後的狀態就是正確的狀態（不可回復），不像POW一般需要6個塊的時間才能確認交易是不會被更改的（POW的狀態確認是機率，六個塊之後有"很高的機率"是無法被改變的，而finality就像是0跟1一樣，沒有中間）。 聽到這，好像覺得很簡單，但是在實作上會遇到幾個問題，首先，怎麼決定誰是proposer誰是attester，如果亂數的隨機性不夠，就很容易被遭到操控。接下來是，每次驗證都需要做一次簽名，因為32個ETH就可以當validator/attester，每次驗證可能會有10~20幾萬的簽章（ 簽章數量的預估方法 ），驗完簽章天都黑了 ＸＤ。 ＲＮＧ 針對亂數產生（ RNG , Random Number Generator），使用 RANDAO 跟 VDF ，RANDAO是個利用經濟獎勵的機制來產生亂數，原始的設計是在smart contract上，而在Beacin chain會直接實作這個邏輯。而VDF是一個delay function，因為速度的關係，基金會打算自己開發ASIC晶片。關於這RNG之後會再寫一篇 詳細解釋 。 Signature Aggregatio
閱讀完整內容

瑞士滑雪分享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
閱讀完整內容

動手實做零知識 - circom

-
圖片
零知識證明在過去一年越來越廣為人知，去年(2019)也有越來越多的專案是基於零知識證明。前年底提出的 zk rollup，目前由  Matter Labs  在開發，Matter Labs更在上個月（2019/12）發表了  ZK Sync ，解決了因為產生證明（proof）而延伸的延遲問題。此外  Iden3  跟 ConsenSys  也有 zk rollup 的專案。在以太坊研究論壇有基於 zk rollup 所衍生的 匿名 zk rollup 。 Semaphore 是一個基於零知識證明的一個訊號系統，發送者可以不揭露身份的狀況下廣播任何訊息(an arbitrary string)。 Semaphorejs 延續 Semaphore 的核心概念，並將整個概念更加完整化，從前端網頁到後端服務。這兩年才發表的 zk-STARKs，也在去年年初跟 0x 合作，推出基於 zk-STARKs 的 去中心化交易所 。 在技術上，去年下半年有新的論文，使用 DARK compiler 可以讓 SNARKs 達到公開性（Transparent）。還有 MARLIN, SONIC, PLONK 等可通用且可更新的可信設定（trusted setup）。STARKs 的 FRI 驗證方式也默默地跟 SNARKs 做結合。（東西越來越多，根本看不完 QQ） 這篇文章沒有要談高深的技術，只會介紹實做所需的知識。這篇會使用到 Iden3 所開發語言  circom  來幫助寫算數迴路 。藉由 circom，可以更輕鬆地實做零知識證明的程式。但在開始之前，先介紹一些基本觀念。 算數迴路 在實做零知識程式跟一般撰寫程式不同，需要先把問題轉成迴路，才去執行（實際上是把 問題 轉成 多項式 再轉成 迴路 ）。舉例來說，一個多項式 $x^3 + x +5$，會轉成像這樣的迴路 sym_1 = x * x // sym_1 = x^2 sym_2 = sym_1 * x // sym_2 = x^3 y = sym_2 + x // y = x^3 + x ~out = y + 5 而 circom 就是一個將我們寫的邏輯（程式）轉成迴路的工具，不需要自己處理迴路。若你證明的內容需要雜湊或是簽章， circomlib  已經有實
閱讀完整內容