欢乐斗地主平稳运行的运维妙计
云
运营中的约 7 分钟
运营中的约 7 分钟涉及产品： 腾讯云 Prometheus 监控服务、Grafana 可视化服务、容器服务
客户介绍：实践背景： 云原生经历了7年多的发展，已经进入了大规模实践阶段，应用极其广泛，互联网、金融、电信、汽车等各大行业均有其身影。近年来，也 越来越多的腾讯业务走向云原生。腾讯 欢乐斗地主也深入参与其中。 欢乐斗地主业务全面上云后，服务全量部署于 腾讯云容器服务 TKE 之中。上云后，旧的监控方案已无法适用。众所周知， Prometheus 是容器场景的最佳监控工具。 但是 自建 Prometheus 对于目前项目运维人力，显得成本略高。同时也容易出现性能瓶颈。经过综合考虑，团队决定 采用 腾讯云Prometheus 监控服务（TMP） 作为监控系统， 抓取并存储指标。本文将分享监控体系实践的一些阶段性经验感悟。
实践效果：
1.1 指标上报 基于统一规范上报的考虑，在代码框架层面直接收拢了上报的 metric 名，仅通过 label 进行指标的区分。例如：counter 类指标，metric 名统一叫做 hlsvr_business_trigger_count，只是 label 取值不同。目前框架二次封装的接口，根据以往经验，仅需设置两个 label 参数就够用。
注2：对于一些需要更多 label 的业务场景，业务也可以上报，只是使用另外的接口，metric 名也可以自定义。
1.2 指标采集 通过 servicemonitor 配置采集的任务，根据业务需求，这里只配置一个涵盖所有服务的 servicemonitor。
1.3 指标展示 欢乐斗地主同时还使用云监控提供的Grafana 可视化服务展示监控数据，对于 Grafana Dashboard 的维护，我们有做过两种尝试：Grafana as code 的方式和直接页面维护的方式。 1.3.1 Dashboard 维护方式 Grafana as code 的维护方式，是通过 yaml 来做 Dashboard 的管理，将所有曲线和告警，都写到 yaml 中，然后使用 helm 去做部署。使用 yaml 可以和服务自身内容写在一起，部署服务 yaml 的时候一起部署 Dashboard，将 内聚 到服务本身的 yaml 之中。 但从功能角度来看，有时候仅仅想微调监控模块，还需要去变更服务的 yaml，加上 helm 仓库管理操作比较复杂，存在误带出去非监控 yaml 变更的可能。 所以综合考虑， 建议将告警都写到一个 Grafana as code 的 yaml 文件之中 ， Dashboard 拆分成多个 ，但是 yaml 文件只需一份。这样在变更 Dashboard yaml 的时候，只会影响到一个 Dashboard。 采用 Grafana as code 的配置方式，可以结合 git 和流水线，实现自动归档，也方便做一些基于 yaml 的批量修改。由于修改 yaml 来生成 Dashboard，调试期就比较不直观，无法所见即所得，因此还得同时支持页面手工调整，然后反向推送回 git 仓库，但这样一来操作就会显得有些繁琐（改 yaml -- 提交 git -- helm 部署 -- 页面观察 -- 手工调整到理想效果 -- 反向推送回仓库）。 相对地，直接在 Grafana 页面上进行维护的方式，显得十分直观，所见即所得，直接页面改完保存即可。但如果想做批量的修改，可以导出 Json model 批量处理 Json 。 由于我们使用了统一 Dashboard（见下文），不需要创建和维护过多的 Dashboard，因此对批量维护的诉求不高，考虑到操作的简便性，目前采用的是直接在 Grafana 页面上进行维护的方式。 1.3.2 统一 Dashboard 由于 metric 名已被固定，就可以制作一个统一的 Dashboard 来覆盖所有服务，将服务名做成一个下拉框即可选择要观测的目标服务。
1.4 告警面板 根据欢乐斗地主业务情况，我们做了一个统一监控 Dashboard，通过 Explore 目标曲线以获取到相关的 PromQL 语句，再基于 Panel Library 去创建监控用的 Panel。
1.5 总体概况 综上，通过欢乐斗地主项目实践总结： 1）使用统一的 metric 名来做上报，方便统一和维护 Dashboard。
2）使用一个全局 servicemonitor 来作为抓取任务。
3）直接通过 Grafana 页面手工维护 Dashboard。
4）对于指标查看，一个统一查看 Dashboard + 一些专属查看 Dashboard。
5）对于指标监控，一个统一监控 Dashboard + 一些专属监控 Dashboard。
2.1 核心亮点 2.1.1 维度聚合
2.1.2 查询接口强大 Prometheus 设计了 PromQL 语句作为查询接口，接口的表达能力非常强大。通过PromQL可以实现对监控数据的查询、聚合。同时 PromQL也被应用于数据可视化(如Grafana)以及告警当中。 上述两个 Prometheus 的亮点，再对比 SQL 类存储的典型能力，会发现有些神似的东西（索引 + group by -- label，sql语句 -- promQL 语句）。 2.2 时序数据库设计思想 小编参阅了 Prometheus 核心开发者 Fabian Reinartz 写的 《Write a time series database from scratch》，又简单看了一些其他时序数据库的资料，发现其中最核心的设计思想，其实不是什么新花招，都是些历久弥新的老方法。 下面就罗列部分关键思想： 1）缓存：通过缓存来做访问加速，可以有多级缓存。
2）顺序写盘 + 合并写入：提高磁盘吞吐。
3）SSD：提高 IO 性能。
4）索引：提高读性能，可以有多级索引、倒排索引。
5）mmap：使用操作系统自己的内存管理。
6）有序化处理：方便做交集、查找、索引。
7）压缩：降低磁盘空间开销。
8）备份：提高可用性。
9）sharding：提高伸缩性。
10）WAL：write ahead log，辅助内存数据的可靠落地、延迟落地。
2.3 为什么选择腾讯云 Prometheus 监控服务 对于欢乐斗地主项目而言，Prometheus 监控服务天然集成 Grafana，腾讯云容器服务（TKE）高度集成，符合项目构建环境，能基本满足欢乐斗地主项目需求。而且 TMP 又是基于开源 Prometheus 构建的高可用、全托管的服务，我们还要啥自行车呢？
欢乐斗地主使用腾讯云 Prometheus 监控服务作为主要的监控系统，还算能迎刃而解的，总体上没有遇到过太棘手的问题，小编在这里总结了几个小坑，让你可以在监控过程中少走弯路。
踩坑案例 1）为每个服务单独配置了一个 servicemonitor，导致 Prometheus CPU过高。
2）使用 Grafana 做 Dashboard，对上千取值的 label 做 repeated panel，查看对应项出现卡顿。
3）误用 url 作为 label，而 url 中包含了可变参数，导致高基数。
第 2 点和第 3 点其实比较显然，我们的解决办法是避开高基数问题，修改业务的 API 调用代码。
近年来，越来越多开发者选择大规模使用 腾讯云容器服务 TKE 来部署、管理服务。在用户购买 TKE 服务之后，监控其 K8s 环境 成为了必须，而 Prometheus 因其强大的指标采集能力、活跃的生态和灵活的 PromSQL 成为了不少研发和运维人员 监控 K8s 的第一选择 。
相关产品介绍