Prometheus监控Etcd集群

聊聊Etcd

Etcd是什么

Etcd是一个分布式的,一致的key-value存储,主要用于共享配置和服务发现。Etcd是由CoreOS开发并维护,通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个来自Stanford的新的一致性算法,适用于分布式系统的日志复制,Raft通过选举的方式来实现一致性,在Raft中,任何一个节点都可能成为leader

Etcd存储了k8s集群中所有的元数据(以key-value的方式), K8s中所有元数据的增删改查都是由kube-apiserver来执行的

Raft算法

raft是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议

参考:

leader选举

raft协议中,一个节点任一时刻处于以下三个状态之一:

  • leader #领导者
  • follower #追随者
  • candidate #候选人

所有节点启动时都是follower状态;在一段时间内如果没有收到来自leader的心跳,从follower切换到candidate,发起选举;如果收到多数的赞成票(含自己的一票)则切换到leader状态;如果发现其他节点比自己更新,则主动切换到follower。

总之,系统中最多只有一个leader,如果在一段时间里发现没有leader,则大家通过选举-投票选出leader。leader会不停的给follower发心跳消息,表明自己的存活状态。如果leader故障,那么follower会转换成candidate,重新选出leader。

选举过程详解

  • 状态由follower切换到candidate状态并投自己一票
  • 并行(RPC协议)给其他节点发送投票请求
  • 等待其他节点的回复,在这个过程中,根据来自其他节点的消息,可能出现三种结果:
    • 收到多数的投票(含自己的一票),则赢得选举,成为leader,成为新的leader会立刻给所有节点发消息,避免其余节点触发新的选举
    • 被告知别人已当选,那么自行切换到follower
    • 一段时间内没有收到多数投票,也没其他节点成为leader,则保持candidate状态,重新发出选举

日志复制(log replication)

  • 当有了leader,系统应该进入对外工作期了
  • 客户端的一切请求来发送到leader
  • leader来调度这些并发请求的顺序
  • 并且保证leader与followers状态的一致性
  • raft中的做法是,将这些请求以及执行顺序告知followers
  • leader和followers以相同的顺序来执行这些请求,保证状态一致。
  • leader只需要日志被复制到大多数节点即可向客户端返回,一旦向客户端返回成功消息,那么系统就必须保证log(其实是log所包含的command)在任何异常的情况下都不会发生回滚。这里有两个词:
    • commit(committed)是指日志被复制到了大多数节点后日志的状态;
    • apply(applied) 是节点将日志应用到状态机,真正影响到节点状态。

Prometheus监控Etcd集群

==前提Prometheus是用Prometheus Operator安装的==

安装方法:

创建secrets资源

#查看etcd引用的证书文件
$ cat /usr/lib/systemd/system/etcd.service 
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
Documentation=https://github.com/coreos
[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
ExecStart=/usr/local/bin/etcd \
--name=11.0.64.5 \
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \
--peer-cert-file=/etc/kubernetes/ssl/kubernetes.pem \
--peer-key-file=/etc/kubernetes/ssl/kubernetes-key.pem \
--trusted-ca-file=/etc/kubernetes/ssl/k8s-root-ca.pem \
--peer-trusted-ca-file=/etc/kubernetes/ssl/k8s-root-ca.pem \
--initial-advertise-peer-urls=https://11.0.64.5:2380 \
--listen-peer-urls=https://11.0.64.5:2380 \
--listen-client-urls=https://11.0.64.5:2379 \
--advertise-client-urls=https://11.0.64.5:2379 \
--initial-cluster-token=etcd-cluster-0 \
--initial-cluster=11.0.64.5=https://11.0.64.5:2380,11.0.64.6=https://11.0.64.6:2380,11.0.64.7=https://11.0.64.7:2380 \
--initial-cluster-state=new \
--data-dir=/var/lib/etcd
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
#创建secret资源
$ kubectl -n monitoring create secret generic etcd-certs --from-file=/etc/kubernetes/ssl/kubernetes.pem --from-file=/etc/kubernetes/ssl/kubernetes-key.pem --from-file=/etc/kubernetes/ssl/k8s-root-ca.pem

apply Prometheus配置文件

#添加如下的 secrets 属性:
$ vim prometheus-prometheus.yaml 
  replicas: 2
  secrets:
    - etcd-certs

$ kubectl apply -f prometheus-prometheus.yaml
#等到pod重启后,进入pod查看是否可以看到证书
$ kubectl exec -it -n monitoring prometheus-k8s-0 -- /bin/sh
/prometheus $ ls -l /etc/prometheus/secrets/etcd-certs/
total 0
lrwxrwxrwx    1 root     root            22 Oct 24 07:20 k8s-root-ca.pem -> ..data/k8s-root-ca.pem
lrwxrwxrwx    1 root     root            25 Oct 24 07:20 kubernetes-key.pem -> ..data/kubernetes-key.pem
lrwxrwxrwx    1 root     root            21 Oct 24 07:20 kubernetes.pem -> ..data/kubernetes.pem

创建 ServiceMonitor

$ vim prometheus-serviceMonitorEtcd.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: etcd-k8s
  namespace: monitoring
  labels:
    k8s-app: etcd-k8s
spec:
  jobLabel: k8s-app
  endpoints:
  - port: port
    interval: 30s
    scheme: https
    tlsConfig:
      caFile: /etc/prometheus/secrets/etcd-certs/k8s-root-ca.pem
      certFile: /etc/prometheus/secrets/etcd-certs/kubernetes.pem
      keyFile: /etc/prometheus/secrets/etcd-certs/kubernetes-key.pem
      insecureSkipVerify: true
  selector:
    matchLabels:
      k8s-app: etcd
  namespaceSelector:
    matchNames:
    - kube-system

$ kubectl apply -f prometheus-serviceMonitorEtcd.yaml    

上面我们在 monitoring 命名空间下面创建了名为 etcd-k8s 的 ServiceMonitor 对象,基本属性和前面章节中的一致,匹配 kube-system 这个命名空间下面的具有 k8s-app=etcd 这个 label 标签的 Service,jobLabel 表示用于检索 job 任务名称的标签,和前面不太一样的地方是 endpoints 属性的写法,配置上访问 etcd 的相关证书,endpoints 属性下面可以配置很多抓取的参数,比如 relabel、proxyUrl,tlsConfig 表示用于配置抓取监控数据端点的 tls 认证,由于证书 serverName 和 etcd 中签发的可能不匹配,所以加上了 insecureSkipVerify=true

创建 Service

$ vim prometheus-etcdService.yaml
apiVersion: v1
kind: Service
metadata:
  name: etcd-k8s
  namespace: kube-system
  labels:
    k8s-app: etcd
spec:
  type: ClusterIP
  clusterIP: None
  ports:
  - name: port
    port: 2379
    protocol: TCP

---
apiVersion: v1
kind: Endpoints
metadata:
  name: etcd-k8s
  namespace: kube-system
  labels:
    k8s-app: etcd
subsets:
- addresses:
  - ip: 11.0.64.5
  - ip: 11.0.64.6
  - ip: 11.0.64.7    
  ports:
  - name: port
    port: 2379
    protocol: TCP

$ kubectl apply -f prometheus-etcdService.yaml

Prometheus 的 Dashboard 中查看 targets,便会有 etcd 的监控项


image
image

数据采集到后,可以在 grafana 中导入编号为3070的 dashboard,获取到 etcd 的监控图表。


image

Etcd监控指标

参考: https://github.com/coreos/etcd/blob/master/Documentation/metrics.md

领导者相关

  • etcd_server_has_leader etcd是否有leader
  • etcd_server_leader_changes_seen_total etcd的leader变换次数
  • etcd_debugging_mvcc_db_total_size_in_bytes 数据库的大小
  • process_resident_memory_bytes 进程驻留内存

网络相关

  • grpc_server_started_total grpc(高性能、开源的通用RPC(远程过程调用)框架)服务器启动总数
  • etcd_network_client_grpc_received_bytes_total 接收到grpc客户端的字节总数
  • etcd_network_client_grpc_sent_bytes_total 发送给grpc客户端的字节总数
  • etcd_network_peer_received_bytes_total etcd网络对等方接收的字节总数(对等网络,即对等计算机网络,是一种在对等者(Peer)之间分配任务和工作负载的分布式应用架构,是对等计算模型在应用层形成的一种组网或网络形式)
  • etcd_network_peer_sent_bytes_total etcd网络对等方发送的字节总数

提案相关

  • etcd_server_proposals_failed_total 目前正在处理的提案(提交会议讨论决定的建议。)数量
  • etcd_server_proposals_pending 失败提案总数
  • etcd_server_proposals_committed_total 已落实共识提案的总数。
  • etcd_server_proposals_applied_total 已应用的共识提案总数。

这些指标描述了磁盘操作的状态。

  • etcd_disk_backend_commit_duration_seconds_sum etcd磁盘后端提交持续时间秒数总和
  • etcd_disk_backend_commit_duration_seconds_bucket etcd磁盘后端提交持续时间

快照

  • etcd_debugging_snap_save_total_duration_seconds_sum etcd快照保存用时

文件

  • process_open_fds{service="etcd-k8s"} 打开文件描述符的数量
  • process_max_fds{service="etcd-k8s"} 打开文件描述符的最大数量
  • etcd_disk_wal_fsync_duration_seconds_sum Wal(预写日志系统)调用的fsync(将文件数据同步到硬盘)的延迟分布
  • etcd_disk_wal_fsync_duration_seconds_bucket 后端调用的提交的延迟分布

(轻易科技ops部)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,204评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,091评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,548评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,657评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,689评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,554评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,302评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,216评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,661评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,851评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,977评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,697评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,306评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,898评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,019评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,138评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,927评论 2 355