开源监控系统Prometheus最佳实践

蓄情

作者：jimmiehan(韩金明),腾讯PCG后台开发工程师,Prometheus/ThanoscontributorPrometheus是目前最流行的开源监控系统之一,这里以我在基于Prometheus构建天机阁2.0Metrics子系统的实践谈一谈Prometheus的一些最佳实践,最佳实践的理念是Prometheus系统简单稳定高效运行的关键。(注:天机阁2.0是新一代云原生可观测性系统)埋点思路最好将原始指标暴露给Prometheus,而不是在应用程序端进行计算.如不需要在应用程序端计算错误率,而应该埋点总量和错误量两个counter,查询时用PromQL处理原始数据,相除得到错误率。在线服务:RED方法,Requests(请求量),Errors(错误量),Duration(耗时)；离线服务:USE方法,Utilisation(使用率,如满载程度),Saturation(饱和度,如排队任务数),Errors错误量。开源项目例子:KubernetesETCDPrometheusGrafanaTIDBInfluxDBgrpc-ecosystem/go-grpc-middlewarePrometheusGoSDKprocess_collector内部代码例子:天机阁GoSDKtps-sdk-goOpentelemetryOteamGo生态SDKopentelemetry-go-ecosystem卡片服务we-feed-card指标名字指标命名的整体结构是name_unit_suffix,符合正则[a-zA-Z*][a-zA-Z0-9_]\*name:name要做到望文生义,类似变量名,应具有良好的可读性.如http_requests_total,process_resident_memory_bytes,queue_size,queue_limit.可参考k8s/etcd/prometheus/grafana/tidb等开源项目；指标名称是全局的,携带命名空间可以有效避免命名冲突.如process_xxx表示进程指标,rpc_xxx表示RPC指标,followsys_xxx表示关注系统业务指标；指标名称不要带环境名/应用名,这些元信息适合用label承载,Prometheus在抓取指标时自动附加,不需要在埋点代码中定义.在接入天机阁时会自动给指标附加app/server/env_name/container_name/namespace这些元信息；Prometheus自定义指标如果要携带中文指标名,我们约定放在名字为_name的label中。unit:指标名可以带上单位,如request_bytes_total,request_latency_seconds；值总是使用基本单位,如秒/米/字节,单位展示可读性的事情则交给Grafana等展示UI来处理。suffix:counter必须以_total为后缀，OpenMetrics规范定义；信息类指标以_info为后缀,类型为gauge，值为1；指标名称不要带_sum_count_bucket后缀，以免与histogram/summary类型生成的指标名混淆。指标labellabel对于多维监控非常有用，一个指标的基数是指标中所有label枚举值组合的笛卡尔乘积.一个进程中一个指标一千的基数是合理的上限。一个进程的总基数是所有指标的基数之和,一个进程一万总基数是合理的上限，因此:label中不适合放用户ID/设备ID/URL参数等高基数的值.单个label值不超过128个字符；避免一个指标过多的label组合,不必要的组合label可以拆解为多个指标,以便降低指标基数,提高该指标的查询性能.参考:https://www.robustperception.io/cardinality-is-ke；Metrics更关注系统级别的高效指标而不是单个请求级别,不要在Metrics中放过多的细节label,单独Metrics无法解决所有的可观测性问题,详细的信息应记录Logs和Traces中,或者在Exemplar带上traceID,充分利用三大信号Metrics/Logs/Traces关联一起来观测系统PromQL对于counter,要先rate后sum,因为rate/irate/increase函数才有counter跳变检测；聚合语句模式中