Prometheus+k8s——HyperLedger Fabric的监控运维实战

       Fabric1.4版本是一个里程碑式的版本，是首个LTS的版本（Long Term Support的版本）。我们认为1.4版本发布的节点数据指标收集接口，极大的提升了fabric的可维护性和可监控性，意味着更利于生产环境的稳定运行。下面详述我们针对fabric 1.4版本的数据指标如何进行采集、展示和预警。

       首先看fabric 1.4中关于Operation Services数据指标文档的描述：

Configuring Metrics

Fabric provides two ways to expose metrics: a pull model based on Prometheus and a pushmodel based on StatsD.

fabric提供了基于Prometheus这种拉式模型和基于StatsD这种推式模型的两种方式来获取指标数据。这里我们以Prometheus这种拉式模型来展开介绍。

一. Prometheus Operator

       我们fabric是部署在k8s环境上的，coreos有一个开源项目 Prometheus Operator，可以在k8s上部署、管理prometheus。其优势体现在基于k8s的CustomResourceDefinition，该项目中定义了prometheus/serviceMonitor等resource type，可以通过k8s的matchLabel标签匹配动态按需为特定的容器组分配prometheus节点；以及prometheusRule、alertmanager等resource type，实现快速配置告警服务。使用户可以通过简单创建k8s的对应resource，来动态管理prometheus节点、监控服务和告警服务。具体介绍可以参考 the prometheus operator。

        我们在readme 可以了解到，prometheus-operator项目是支持prometheus 配置在k8s原生平台上，并且可以在k8s上管理prometheus和alertmanager。其中kube-prometheus目录下提供了prometheus监控k8s和运行在k8s上应用的资源定义，也就是说当你同时需要用prometheus监控k8s集群，或者要用prometheus监控部署在k8s集群上的应用时，就可以直接用kube-prometheus了。可以直接在kube-prometheus目录下运行kubectl apply -f manifests/   。

注意：

• 需要多次运行此命令，直到所有资源创建完毕。
• 如果需要将镜像转存到docker私有镜像仓库，需要手动修改yaml文件中image标签对应的镜像地址，yaml文件中可以增加imagePullSecrets，其他支持的属性可以查看对应资源类型的definition文件。   

        运行成功了可直接访问grafana和prometheus 的web页面：

• 访问prometheus主页/targets，显示各指标监控状态，若无异常，state应该都是UP状态。
• 访问grafana主页，将数据源正确配置为prometheus即可查看已经预定义好的k8s监控dashboard。

二.fabric监控指标收集&配置

         在0prometheus-operator-0prometheusCustomResourceDefinition.yaml中发现，我们可以通过定义prometheus资源部署并指定prometheus节点拉取某些范围内的service指标，如通过serviceMonitorNamespaceSelector可以指定namespace范围，通过serviceMonitorSelector可以指定serviceMonitor范围。github源码中prometheus-prometheus.yaml定义的两个属性都是{}，即anywhere。所以理论上是可以作用于任意serviceMonitor的。

         serviceMonitor是特定的资源用于匹配k8s的原生service资源，在serviceMonitor中我们可以定义想要监控的metric service范围（labelMatch）以及拉取metrics的endpoint的interval（时间间隔）、port（service中定义的端口）等属性。

       需要提前按照文档说明配置好需要监控的fabric peer和orderer节点，并在k8s中定义好8443端口对应的service。接下来定义serviceMonitor，以orderer为例：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  namespace: fabric
  name: fabric-orderer
  labels:
    application: fabric-orderer
spec:
  selector:
    matchLabels:
      application: fabric-orderer
  endpoints:
  - port: orderer-metrics         # works for different port numbers as long as the name matches
    interval: 10s        # scrape the endpoint every 10 seconds
  namespaceSelector:
    any: true

        运行后发现在prometheus UI中并没有fabric-orderer。原因是prometheus节点部署在monitoring namespace，如果想要访问其他namespace是在权限上不被允许的。需要结合k8s的rbac给prometheus serviceMonitor对应的访问策略。

        修改prometheus-clusterRole.yaml：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-k8s
rules:
- apiGroups: [""]
  resources:
  - nodes
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  verbs: ["get"]
- apiGroups:
  - ""
  resources:
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get

       重新部署ClusterRole资源，prometheus成功拉取到fabric-orderer的metric。

三.fabric监控指标远端存储

       prometheus的存储默认是有有效期限的，数据将先保存到Promtheus基于本地磁盘实现的时间序列数据库中。为了后续的持续运维监控，企业一般会将prometheus收集的指标数据转存到专门的时序数据库中。携程监控系统hickwall，支持influxdb作为时序数据库，可以用于保存prometheus收集的指标。

       这里，我们使用了prometheus项目中的remote-storage-adapter作为远端存储中继，将代码打包生成镜像部署到了k8s中，配置远端存储数据库为influxdb，并修改prometheus-prometheus.yaml增加：

  remoteWrite:
  - url: "http://prom-remote-s.monitoring:9201/write"

       至此，完成fabric指标数据的收集、归档。

 

四.fabric监控指标监控&告警

       携程使用的是携程自研的hickwall进行指标的监控和告警，大家其实可以使用kube-prometheus提供的alertmanagers作为告警服务。

       kube-prometheus提供了k8s的监控dashboard，对于fabric的监控dashboard参考了https://github.com/xuchenhao001/hyperlook项目的dashboard。