背景: 对于初创企业来说,在很长一段时间一些基础的开源服务基本都是”裸奔”上线的,除了一些传统的主机级别的监控之外,很难有一些额外的性能指标来描述该服务的整体性能情况。因此,在我们的Minio对象存储服务上线到最近一直也是裸奔的,虽然暂时也没出现过故障,但是作为一名专业搞笑的SRE来讲,服务的可观测性一定得跟上,不然后期铁锅是妥妥的背定了,这篇文章就主要介绍下Minio的可观测性方案。

开源组件的可观测性现状

在开头提到了,初创企业的开源服务初期大多都是裸奔上线的,出现这种情况我认为一般分为内因和外因:

  • 内因是开源的基础中间件性能指标通常很多,不容易抽象,因此这些服务的性能指标数据通常可以通过内部的api或cli来获取,不太容易直接和开源的监控系统进行集成;

  • 外因是对于初创企业来说,人力有限并且对于众多开源组件的理解不够深入导致前面说的”裸奔”上线的现象。

不过随着以KubernetesPrometheus为代表的CloudNative理念不断发展,越来越多的开源中间件也支持了兼容Prometheus Metrics格式的性能指标,这对于初创企业的技术团队来说可谓是一个福音。

截止目前,我们所熟知的很多开源软件已经内置了兼容Prometheus Metrics的API接口,不再需要第三方的exporter来导出一些性能指标数据。

[内置Metrics接口的开源软件](https://prometheus.io/docs/instrumenting/exporters/#software-exposing-prometheus-metrics)

Minio集群的可观测性

得益于Minio的云原生化,这款分布式的对象存储服务天然的支持了Prometheus Metrics格式的指标数据以及服务端点(API),因此,如果想要在已有的Minio集群中增加性能指标的监控,将是一件很容易的事情。

使用Prometheus监控Minio服务

Minio服务通过内置的服务端点暴露监控数据,用来监控服务整体的健康状态以及性能指标:

  • Healthcheck 探针: 提供两个服务探活接口,一个用于检测服务是否启动,另外一个用于检测服务是否可以正常对外提供服务(服务就绪)
  • - 探活接口: /minio/health/live
  • - 就绪接口: /minio/health/ready
  • Prometheus 探针: 提供了prometheus metrics格式的性能指标数据
  • - Metrics接口: /minio/prometheus/metrics

注意: Healthcheck相关的探针默认是非认证的接口,服务启动后可直接访问; Prometheus探针的接口默认是基于JWT认证的接口,需要额外设置来访问其Metrics数据。

Minio的Metrics数据暴露

管理员可通过下述方式获取Metrics端点的jwt token:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 获取token
$ mc admin prometheus generate  minio
scrape_configs:
- job_name: minio-job
  bearer_token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjQ3NDAwMzM4MjAsImlzcyI6InByb21ldGhldXMiLCJzdWIiOiJNaW5pb1NvdWwifQ.1QiANgXVCpAPWCdF9EejhH608rZbdCRcHe3RtalC2XnScWtYMk_OG0ih-Z3t4ADb1cnYREdTrQwWscFw6Xvk3Q
  metrics_path: /minio/prometheus/metrics
  scheme: http
  static_configs:
  - targets: [minio.bgbiao.top]

# 在配置prometheus的scrape时配置如上相关参数

通常对于内部系统间的调用来说,权限可能没那么重要,可以增加如下环境变量来开启metrics的非认证方式:

1
MINIO_PROMETHEUS_AUTH_TYPE="public"

此时,直接访问接口可以获取到如下的Metrics数据:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
$ curl -s  minio.bgbiao.top/minio/prometheus/metrics | head -10
# HELP disk_storage_available Total available space left on the disk
# TYPE disk_storage_available gauge
disk_storage_available{disk="/data/minio"} 2.78376280064e+11
# HELP disk_storage_total Total space on the disk
# TYPE disk_storage_total gauge
disk_storage_total{disk="/data/minio"} 3.00809048064e+11
# HELP disk_storage_used Total disk storage used on the disk
# TYPE disk_storage_used gauge
disk_storage_used{disk="/data/minio"} 2.2432768e+10
# HELP go_gc_duration_seconds A summary of the GC invocation durations.

minio-metrics相关定义

  • 标准的运行时指标使用以go_开头
  • 进程级别的指标以process_开头
  • prometheus暴露的指标promhttp_开头
  • disk_storage_used: 磁盘使用空间
  • disk_storage_available: 磁盘可用空间
  • disk_storage_total: 磁盘总空间
  • minio_disks_offline: 当前minio实例中处于下线状态的个数
  • minio_disks_total: 当前minio实例的磁盘总数
  • s3_requests_total: 当前minio实例中s3接口总请求数
  • s3_errors_total: s3接口错误请求数
  • s3_requests_current: 活动状态的s3请求数
  • internode_rx_bytes_total: 当前MinIO服务器实例接收的节点间字节的总数(bytes)
  • internode_tx_bytes_total: 当前MinIO服务器实例发送到其他节点的字节总数
  • s3_rx_bytes_total: 当前MinIO服务器实例接收的s3字节总数
  • s3_tx_bytes_total: 当前MinIO服务器实例发送的s3字节总数
  • s3_ttfb_seconds_: 统计s3请求的延迟信息
  • - bucket: bucket操作相关的延迟
  • - count: 延迟统计
  • - sum: 总延迟

注意: Minio不同的版本的Metrics数据有区别,需要查看具体暴露的数据指标

示例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# 打开文件数
process_open_fds{job="minio-metrics"}

# 启动时间(时间戳)
process_start_time_seconds{job="minio-metrics"}

# 虚拟内存使用
process_virtual_memory_bytes{job="minio-metrics"}

# cpu占用时间
process_cpu_seconds_total{job="minio-metrics"}

# minio对外的http接口状态
promhttp_metric_handler_requests_total{job="minio-metrics"}

# 链接中的http请求
promhttp_metric_handler_requests_in_flight{job="minio-metrics"}

配置prometheus数据抓取

注意: 我们的Prometheus是使用CRD方式部署在Kubernetes集群中的,因此抓取外部Metrics数据需要做如下的操作.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# 暴露minio服务
$ cat endpoint-minio.yaml
apiVersion: v1
kind: Endpoints
metadata:
  name: minio-metrics
  namespace: monitoring
  labels:
    app: minio-metrics
subsets:
- addresses:
  - ip: 192.168.0.148
  - ip: 192.168.0.149
  - ip: 192.168.0.150
  - ip: 192.168.0.151
  ports:
  - port: 9000
    name: http-metrics
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  namespace: monitoring
  name: minio-metrics
  labels:
    app: minio-metrics
spec:
  ports:
  - name: http-metrics
    port: 9000
    targetPort: 9000
    protocol: TCP

# prometheus servicemonitor
$ cat prometheus-minio.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app: minio-metrics
  name: minio-metrics
  namespace: monitoring
spec:
  # 对应的端点是上面创建的svc的ports
  endpoints:
  # 可以定义两个采集端点,一个是minio服务本身的监控,一个是minio节点的基础监控
  - interval: 30s
    port: http-metrics
    path: /minio/prometheus/metrics
  jobLabel: app
  # 匹配monitoring命名空间的app=minio-metrics的svc
  namespaceSelector:
    matchNames:
    - monitoring
  selector:
    matchLabels:
      app: minio-metrics

查看prometheus监控的minio相关数据

Prometheus成功抓取minio metrics数据后,即可在prometheus中查看到先关数据:

minio-prometheus-metrics

在Grafana中配置关心的指标以及相关图表:

minio-grafana监控

为了方便其他运维小伙伴们,我将Minio的Grafana模板开源出来,有需求的可以直接使用如下模板:

minio-grafana模板


知识星球

公众号