集群频繁触发 etcdDatabaseHighFragmentationRatio 告警, PrometheusRule 内容如下
1 | - alert: etcdDatabaseHighFragmentationRatio |
相关指标:
- etcd_server_quota_backend_bytes：当前后端存储配额大小（字节），默认为 2GB
- etcd_mvcc_db_total_size_in_bytes：物理分配的底层数据库总大小（字节），包含了数据（如 keyspace）和碎片，即 DB SIZE
- etcd_mvcc_db_total_size_in_use_in_bytes：逻辑上正在使用的底层数据库的总大小（以字节为单位），不包含碎片
也就是说 quota-backend-bytes 配置后，etcd_mvcc_db_total_size_in_bytes 的大小并不会根据这个值而变化，会变的是 etcd_server_quota_backend_bytes，etcd_mvcc_db_total_size_in_bytes 的值指的是 DB SIZE，可以通过以下方式获取 DB SIZE
1 | ls -lrth ${etcd-data-dir}/member/snap |
为什么会产生碎片?
- ETCD 支持多版本并发控制(MVCC)，同时会精确记录其 keyspace 的历史
- 压缩操作是清除历史记录的唯一方法，通常用 –auto-compaction-mode 和 –auto-compaction-retention 来实现自动压缩
- 但压缩操作后的空闲空间并不会真正在文件系统中释放，而是会被 ETCD 标记为可使用的空闲空间，也就是说压缩操作后仍然会占用磁盘空间
- 要真正释放，就需要进行碎片整理，即 etcdctl defrag
1 | etcdctl defrag |
那么针对 etcdDatabaseHighFragmentationRatio 告警的触发，要怎么判断需不需要进行碎片清理?
- 通过 etcd_server_quota_backend_bytes 指标查看实际配额
- 通过指标 etcd_mvcc_db_total_size_in_bytes 或者命令检查 DB SIZE，看是否真的很大且接近于 quota-backend-bytes，如果不是则无需担心
- 如果是，获取每种资源的数量，查看是什么资源导致 DB Size 这么大，然后通过碎片清理尝试释放空间，如果释放后仍接近于 quota-backend-bytes，那么需要考虑增加配额
1
2etcdctl get /registry --prefix --keys-only | grep -v ^$ | awk -F '/' '{ h[$3]++ } END {for (k in h) print h[k], k}' | sort -nr
etcdctl defrag
