Grafana Polystat面板与腾讯云可观测平台的深度融合实践做运维这么多年手头管着的服务器从几十台涨到几百台监控看板也从最初几张凌乱的图表慢慢收敛成一套稍微像样的体系。Grafana一直是我这边的主力可视化工具Prometheus、Loki、告警规则全往里面塞看板数量多了以后反而暴露出一个新问题——信息密度不够。传统的时间序列图适合看趋势但如果你是早上一睁眼就想知道“线上几十台机器里有没有哪台CPU爆了、哪台云数据库连接数快满了”一张折线图根本看不过来。这时候特别需要一种“一屏扫完所有状态”的面板。我最早是在开源社区看到有人在用Polystat第一反应是这玩意儿有点意思把一堆指标变成一个个动态色块绿就是正常红就是异常不用逐台点开详情。后来配合腾讯云可观测平台的数据源把云上资源的状态也接进来才真正跑起来一套“混合视角”的运维看板。这篇文章重点记录我自己的整合过程和踩坑记录包括腾讯云可观测平台的数据怎么进Grafana、Polystat面板的JSON配置到底怎么折腾、阈值状态怎么设计才不误报以及后面做模板变量、做告警联动时遇到的一些细节。想直接在Grafana里把云上资源“做成色块墙”的朋友可以按这篇的步骤从头走一遍。1. 为什么要把Polystat面板和腾讯云可观测平台放在一起1.1 从一块看板说起的运维痛点先说个真实场景。我们有套业务部署在腾讯云上资源倒不算特别多但种类杂云服务器CVM、云数据库MySQL、负载均衡CLB、对象存储COS还有少量容器服务TKE。过去排查问题的方式是先打开Grafana里按照资源类型拆出来的好几个dashboard一个个切下拉框选实例再看CPU、内存、延迟、错误码。这套流程最大的问题就一个字——慢。线上告警响了以后你根本来不及把每个资源都点一遍。有一次线上交易量下跌我花了十分钟才发现是某一台CVM的磁盘IO被打满了而那台机器在整张看板里只是一个不起眼的尖刺。那次之后我就下定决心一定要有一张“打开就能扫一眼”的总览看板把关键资源的关键指标全部平铺在一个屏幕上状态一眼可见。Grafana的默认面板体系里其实没有特别好的“多状态总览”方案。表格面板能做但不直观看数字和看颜色完全是两种体验singlestat又太老功能有限后来社区里有人重度使用Polystat我发现它正好解决了这个问题。Polystat的核心逻辑是在一张面板里用N乘M的网格展示多个指标每个格子显示一个值并根据阈值动态变化颜色。整个看板的结构就像一面“状态灯墙”绿、黄、红一目了然。1.2 Polystat面板的独到之处Polystat这个面板插件的全名是“Polystat Panel”作者是Grafana社区里一位长期活跃的开发者。它最常见的用途是数据中心机房监控把一台台服务器的状态做成一个个小方块但我把它用在云资源监控上也完全成立。它的优势我总结下来有三点。第一信息密度极高。传统的时间序列面板一屏最多看四五个指标再多就糊了。Polystat面板可以同时展示几十个甚至上百个独立“状态格子”每个格子独立配置查询和阈值这对总览场景是质变式的体验。第二状态表达非常直接。格子颜色可以绑定阈值范围比如CPU使用率低于60%是绿色、60%到85%是黄色、超过85%是红色。值班的人不需要看具体数字只看颜色就能定位异常范围。而且面板支持自定义显示文本可以在格子里显示“实例名 当前值”或者“实例名 状态”比纯数字直观得多。第三支持超链接下钻。我实际使用中最喜欢的一个功能是格子可以绑定点击事件跳转到另一个dashboard并且自动带上当前实例的过滤条件。也就是说你可以在总览页看到一个红色格子点击它就直接跳转到这台实例的详细监控页马上看曲线、查日志。这比在多个面板之间手动切换高效太多。1.3 腾讯云可观测平台在里面扮演什么角色聊完了面板再聊数据。腾讯云可观测平台是腾讯云官方的一站式监控产品体系里面包含了云产品监控、Prometheus托管服务、应用性能监控APM、日志服务等多个模块。对我来说最核心的一个能力是云上所有资源的监控指标全部可以通过API批量拉取而且大多数指标在控制台上能看到什么在API里就能拿到什么。它和Grafana之间的关系其实取决于你走哪条路接入。腾讯云官方提供了Grafana数据源插件安装之后你用云API密钥认证就能在Grafana里直接查询云监控的指标数据不需要自己在中间搭建采集器。另一种方式是使用腾讯云Prometheus托管服务它自带了指标采集能力Grafana配置这个Prometheus数据源之后就能用PromQL查询云原生组件的指标。这两种方式我都在生产环境里跑过各有各的适用场景后面第2部分我会展开讲。简单说如果只是想把云资源的CPU、内存、网络流量这类基础监控接到Grafana官方云监控数据源插件最省事如果你在TKE里跑容器化应用同时需要自定义指标那走托管Prometheus更合适。2. 数据接入让腾讯云指标流入Grafana2.1 数据接入的两种主流路径对比在动手配置之前一定要先想清楚数据接入的路径。这个选型决定了后面所有面板怎么写查询语句也决定了指标粒度、历史数据保留和告警能力。我把自己踩过的两种方案整理成一张对比表方便你根据自己手头的资源情况做选择。对比维度腾讯云云监控数据源插件腾讯云Prometheus托管服务接入复杂度低安装插件后配置密钥即可中需要开通托管实例并配置采集规则数据范围云产品监控指标CPU、内存、流量等开箱即用云原生指标 自定义指标可采集容器和业务侧数据查询语言类SQL/点选式官方插件封装好维度过滤PromQL历史数据依赖云监控侧的数据保留策略依赖Prometheus自身存储配置告警方式可在Grafana做告警也可以在云监控控制台配置推荐用Prometheus告警规则也可接Grafana告警适合场景以云产品资源为主快速出图有容器、K8s、自定义业务指标需要更灵活的查询我自己这边的选择是“两条腿走路”。基础云产品监控CVM、CLB、云数据库等走官方数据源插件因为这类指标开箱即用、维度清晰插件里封装好了按实例ID过滤的逻辑查询写起来快。TKE里容器和业务侧的自定义指标走Prometheus托管服务因为PromQL在复杂聚合场景下的表达能力更强。2.2 配置腾讯云云监控数据源插件的完整步骤如果你决定先用官方云监控数据源插件把数据接进来那操作步骤大概是这样的。先说明一下我以Grafana 10版本为例不同版本的菜单层级可能会略微有差异但总体思路是一样的。第一步是安装插件。如果你的Grafana运行在Linux服务器上可以直接在Grafana的bin目录下执行grafana cli命令grafana cli plugins install grafana-tencentcloud-monitor-app安装完成之后重启Grafana服务然后在Grafana的“Configuration - Plugins”页面找到腾讯云监控插件点击“Enable”启用。如果是在容器环境部署的Grafana可以通过环境变量ENABLE_PLUGINS或在Docker启动命令里加载插件目录方式稍有不同但核心都是把插件文件放到Grafana的plugins目录下。第二步是在Grafana里新增数据源。进入“Configuration - Data sources”点击“Add data source”找到腾讯云监控相关的数据源类型。这里需要填三个关键信息SecretId、SecretKey和Region。SecretId和SecretKey是你在腾讯云访问管理CAM里创建的API密钥建议单独创建一个只读权限的子账号密钥权限范围限制在DescribeMetricData等监控查询接口避免主账号密钥泄露造成大范围风险。Region可以填写你资源主要所在的地域如果资源分布多地可以在查询时再调整。第三步是验证连通性。在数据源配置页的底部点击“Save Test”如果提示连接成功就说明密钥和网络都没问题。如果失败优先检查密钥是否正确、该子账号是否具备云监控只读权限。2.3 通过Prometheus托管服务接入容器指标再补充一下走Prometheus托管服务的情况。这种方式适合你已经在用TKE或者对自定义指标有强需求。腾讯云的Prometheus托管服务简称TPS开通之后会提供一个远程写入和查询的Endpoint你可以把Grafana的“Prometheus”类型数据源指向这个Endpoint。配置时要注意认证信息需要开一个Prometheus HTTP API的访问凭证通常是Token或者Basic Auth形式。你在TPS控制台创建实例后能看到对应的API地址和凭据填到Grafana数据源配置里即可。这类数据源的查询语言就是PromQLPolystat面板里的Query类型选择“Prometheus”然后写PromQL查询表达式。举个例子如果你想在Polystat面板里展示每个TKE工作负载的Pod重启次数可以写成这样的PromQLsum(kube_pod_container_status_restarts_total) by (namespace, pod)这类指标在原生Kubernetes监控里是现成的Prometheus托管服务会自动采集kube-state-metrics不需要额外写采集器。聚合维度根据你的场景灵活调整比如想按Node汇总、按Deployment汇总都是改一下by后面的label即可。3. Polystat面板核心配置与状态编排实战3.1 安装Polystat插件并创建第一个面板数据源准备好之后下一步就是让Polystat面板上场。安装同样是命令行操作grafana cli plugins install yesoreyeram-boomtheme-panel你可能注意到插件ID不大一样Polystat面板在Grafana插件仓库里的ID是yesoreyeram-boomtheme-panel作者是yesoreyeram。装完之后重启Grafana然后在新建面板时就能在可视化类型里找到“Polystat”选项。这里有个小技巧在创建面板时先选择Polystat类型再配置查询这样查询出的列和面板字段之间的映射关系会更直观。Polystat面板最核心的交互方式是通过JSON配置来控制显示逻辑和状态逻辑。第一次打开面板配置时你可能有点懵因为它左侧是标准的查询区右侧却是一大堆JSON选项。但搞清楚几个核心概念之后其实很好上手。3.2 理解面板的查询列与字段映射Polystat面板不像Graph面板那样自动把查询结果按序列画成曲线它是把查询结果“当作表格”来处理。每一行代表一个独立的格子每一列代表这个格子的某个属性。面板里用到的最核心字段是这三个metric格子的名称显示在格子内部通常用实例名或标签拼接value格子的当前数值决定格子显示什么也决定阈值判断取哪个数字status可选字段如果你希望状态和数值分离可以单独给一个状态列举个例子你想展示5台CVM的CPU使用率那么查询结果应该返回五行数据一列叫metric存放实例名一列叫value存放CPU使用率数值。在Polystat面板的JSON里你需要通过“metrics”配置告诉面板“metric列对应哪个字段value列对应哪个字段”。这个映射关系是Polystat配置里最重要的环节映射错了面板就显示不出来。我在实际使用中经常用Grafana的Transform来处理查询结果。比如默认的查询结果列名是“Value #A”不好识别我就在Transform里用“Organize”或者“Rename by regex”把列名改成value再用“Labels to fields”把Prometheus的标签变成独立的列。这样Polystat面板的JSON配置就会很干净。3.3 阈值规则与颜色状态设计Polystat面板的阈值配置通过“thresholds”字段控制这是整个面板的灵魂。阈值不是简单写一个数字而是一个数组每个数组元素包含一个值和这个值以上/以下对应的颜色和状态文案。我在生产环境里用的阈值规则一般是这样的结构thresholds: [ { value: 0, state: ok, color: green, text: 正常 }, { value: 60, state: warning, color: yellow, text: 预警 }, { value: 85, state: critical, color: red, text: 告警 } ]这里有个容易踩的坑Polystat的阈值判断逻辑是从高到低匹配的如果某个格子的值是50它不会命中第一段“0”而是会命中“60”这一档不对实际上它是先匹配最大的value如果当前值大于等于某个value就用这个value对应的状态如果小于最小value就用第一段的默认状态。所以上面这个配置的语义是85红色60黄色其他绿色。如果你想做小于某个值告警的指标比如内存可用量可以单独设计一套递减阈值或者把查询结果取负值反过来判断。颜色语义上也建议制定一个自己的规范。运维看板最重要的是快速识别风险所以颜色的含义必须全局统一。我的规范是绿色代表完全正常黄色代表性能劣化或容量接近临界红色代表需要立即介入的故障灰色则用于无数据或实例已下线。这样的好处是新来的同学看任何一张看板不需要额外解释就能明白。3.4 通过模板变量实现多环境复用Polystat面板真正强大起来是在配合模板变量之后。模板变量是Grafana里的一种动态过滤机制可以通过下拉框切换环境、地域、业务分组等维度让同一张看板在不同范围内复用。我这边默认配置了几个变量env环境维度可选值生产、预发、测试region地域维度app业务应用维度。变量的查询来源可以是另一个数据源也可以是Prometheus里的标签值。比如app变量可以通过PromQL查出来label_values(kube_pod_info, app)然后在Polystat面板的查询语句里引用变量SELECT instance_id, cpu_usage FROM metric WHERE region $region AND app $app面板的标题也可以带上变量这样切换下拉框时看板标题会同步变化方便截图留档。Polystat格子数量比较敏感如果查询结果显示的数据行数非常多比如几百个Pod一屏塞满会非常拥挤。我的经验是控制在50个格子以内超过50个就拆分成多个面板或者用变量分组先看一组再看另一组。格子太多以后字号会变小颜色区分度也会下降反而失去总览的意义。4. 完整落地案例某在线业务系统全景监控看板4.1 场景设定与监控目标为了让你更直观地理解整个配置流程我用一个具体的案例把流程串起来。假设我们有一个在线预订系统部署在腾讯云上组件包括4台CVM承载Nginx和业务进程2台云数据库MySQL承载订单数据2个CLB负载均衡对外提供入口另外还有若干COS bucket存放静态资源。监控目标是在一张总览看板上用不超过5秒的时间判断整个系统是否健康。我把指标核心圈定为四类CVM的CPU使用率、内存使用率、磁盘IO云数据库MySQL的连接数使用率、慢查询数CLB的QPS、后端异常率COS的存储量和请求错误率。所有这些指标全部来自腾讯云可观测平台通过官方数据源插件查询。4.2 指标选择与查询编写我通常会在Grafana里先用Explore功能验证查询确认数据源返回的字段名和值没问题再复制到Polystat面板里。这一步很关键可以避免在面板配置里来回调试。以CVM CPU使用率为例腾讯云监控数据源插件通常支持这样的查询方式选择命名空间Namespace为QCE/CVM指标名为CPUUsage然后按实例ID过滤。有些插件版本还支持直接用Region过滤。返回结果里会带instanceId和instanceName标签这两个正好可以映射到Polystat的metric字段。SQL类的查询可能是这样SELECT instanceId, instanceName, CPUUsage FROM QCE/CVM WHERE region ap-guangzhou如果你的数据源插件不支持这种SQL语法而是用“Metric Find”之类的下拉选择同样能实现只是写法上按UI选项来。另外需要特别说明的是腾讯云监控类指标大部分是有采集周期的默认可能是60秒一次。如果你创建面板后发现数值更新不够实时可以在查询里加一个周期参数“period”或者接受默认值。总览型看板不需要秒级刷新每分钟或者每两分钟刷新一次就足够太频繁反而容易被云监控API限流。4.3 Polystat面板JSON配置实例当所有查询都准备好了下面是我用的一套核心JSON配置你可以对照着改。这是Polystat面板的Settings部分不是整个dashboard的JSON面板级的JSON配置在编辑面板时切到“JSON”页签就能看到。{ metrics: [ { name: metric, label: 资源名, type: string }, { name: value, label: 当前值, type: number } ], display: { unit: percent, decimals: 0, showName: true, showValue: true, size: 30, textMode: value-and-name, background: solid }, thresholds: [ { value: 0, state: ok, color: green, text: 正常 }, { value: 60, state: warning, color: yellow, text: 预警 }, { value: 85, state: critical, color: red, text: 告警 } ], global: { decimals: 0, unit: percent }, enableContextMenu: true, enableNewStatus: true, enableNewLayout: true, clickThrough: { url: /d/xxxxx/instance-detail?var-instance${metric}, openInNewTab: true }, layout: { horizontal: 8, vertical: 4 } }这个配置里几个字段稍微解释一下。display.size控制格子内字体大小一般30到35比较合适textMode选择value-and-name这样格子里既能显示实例名又能显示当前数值信息量最大。background设置为solid颜色填充整个格子比只改变文字颜色醒目很多。clickThrough这个字段是点击下钻跳转的配置我这里的url是一个示例实际使用时把/d/xxxxx/instance-detail替换成你自己的实例详情看板ID${metric}会被替换成当前格子的metric值从而实现点击格子跳转到对应实例详情。这个功能在一次线上故障排查时帮我省了大量时间强烈建议设置好。4.4 从数据接入到看板上线的完整操作流说完了JSON再把整个操作流从头到尾过一遍方便你按步骤复现。第一步确认数据源。无论你是用云监控数据源插件还是Prometheus托管服务都要确保Grafana里的Datasource配置正常Test通过。第二步创建文件夹和Dashboard。建议单独建一个“总览看板”的文件夹别和生产环境的其他临时看板混在一起。Dashboard创建好之后添加一个Panel选择Polystat类型。第三步配置查询。在Query区选择你的腾讯云数据源添加多个查询每个查询对应一类资源指标。比如Query A查CVM CPUQuery B查MySQL连接数Query C查CLB异常率。Polystat面板支持多条查询结果自动合并显示在同一个网格里这是我特别看重的一个能力。第四步配置JSON和阈值。把上面那段JSON配置粘贴到面板JSON里注意修改阈值范围和颜色匹配你的业务需求。如果你的查询结果列名不是metric和value记得同步修改metrics映射关系。第五步调整布局。在编辑面板时你可以在可视化区域手动拖拽网格也可以直接通过layout字段指定横向和纵向格子数量。假设你有10个资源需要展示横向5格、纵向2格就挺协调。格子大小保持正方形视觉上最舒服。第六步设置刷新周期和告警。面板右上角设置Dashboard刷新周期建议1分钟或2分钟。如果你还需要告警通知可以在Polystat面板的Alert页签里把某个查询值的阈值条件转成Grafana告警规则关联到企业微信或邮件通知。不过我更推荐告警单独用云监控控制台配置毕竟是云厂商官方通道稳定性和通知渠道集成都更靠谱。5. 常见问题与排查技巧实录5.1 常见问题速查表把我在实际使用中碰到的高频问题整理成一个表遇到类似情况可以直接按着排查。问题现象常见原因解决办法面板显示“No data”查询条件里地域、实例ID不对或者数据源权限不足先在Explore里跑同样的查询确认返回数据格子全是灰色查询返回的value字段为null或字段映射不匹配检查JSON配置metrics字段里的name是否和查询列名一致阈值颜色不生效阈值顺序或判断逻辑没搞对或者阈值字段没对应到value把thresholds配置改成从高到低的数组确认state字段正确格子特别多显示特别拥挤查询结果行数太多超出了面板设计容量用模板变量缩小范围或拆分成多个面板点击格子不跳转clickThrough.url配置错误或变量名不匹配检查URL里是否使用了${metric}确保它和metric列名称一致刷新时API被限流单数据源查询次数过于频繁调大Dashboard刷新周期减少仪表盘同时刷新的面板数量5.2 数据源权限与限流处理腾讯云监控数据源API是有频控的这一点官方文档里写得不明显但在实际使用中非常容易触发。我记得有一次在调试阶段为了测试不同查询效果把刷新周期改成了5秒结果没几分钟就报了一堆“API rate limit exceeded”错误。后来我总结了一套规避限流的策略。第一总览类看板的刷新周期控制在1分钟以上别想着实时刷新总览看板的意义在于快速定位不在于秒级精度。第二把多个查询合并成一个查询尽量避免一个面板里挂8个以上的查询减少API调用次数。第三如果资源真的很多可以按腾讯云控制台里的“实例分组”维度来查询将多个实例聚合到一个返回值里而不是每台实例单独查询。比如CPU使用率可以查询平均值GroupBy设置在region维度返回值减少限流风险大大降低。权限方面也要注意。腾讯云API密钥建议到期轮换子账号只授予“云监控只读”策略具体操作是在CAM里新建策略选择“QcloudMonitorReadOnlyAccess”。这样做的好处不只是安全还能避免手滑在Grafana里误操作云资源比如运行某些高风险API。5.3 面板性能与告警联动优化Polystat面板在数据量大的时候渲染性能会有明显波动。我的经验是如果单面板的格子数超过100个浏览器渲染就会出现卡顿尤其在切换模板变量时会出现白屏或延迟。这个问题的优化路径有三个方向。第一减少数据量。查询时用更多过滤条件只保留真正需要关注的资源。比如只展示“运行中”状态的实例把已销毁的过滤掉。第二简化配置。JSON配置越复杂面板渲染时做的工作越多不必要的link、style尽量别加。第三硬件层面给Grafana实例分配更多内存但这只是兜底方案治标不治本。关于告警联动我建议不要把所有告警都压在Grafana上。Polystat面板适合做可视化状态展示但告警通知最好交给腾讯云可观测平台通过云监控控制台配置告警策略通知渠道可以选择企业微信、短信、电话稳定性远高于Grafana自身告警。两者分工是Grafana负责“看清楚”云监控负责“喊出来”。面板显示异常是一回事通知到人又是另一回事整个体系里两个环节缺一不可。6. 生产环境落地的几点额外建议6.1 看板命名与目录规范规模稍微上来之后看板数量一多命名不统一就会很痛苦。我的建议是建立一套自己的导演规则比如“层级-业务-资源-用途”命名的模式。“总览-CoreOrder-CVM-CPU”这样的名称存活期绝对比“最终版看板”长得多。目录结构也可以按业务域划分比如“线上核心链路”“离线加工链路”“基础设施公共组件”把总览看板放在每个目录最显眼的位置双击就能打开。另外Grafana的看板可以通过JSON导入导出团队协作时把写好的Polystat看板JSON导出发给同事对方只需调整数据源UID就能复用。这一步我用的频率很高新环境起监控看板基本都是从旧环境导出几个典型看板然后改配置。6.2 备份与版本管理Polystat面板的JSON配置比较长稍微改错一个符号就会导致面板失效所以我习惯把看板JSON纳入Git管理。Grafana有Provisioning机制可以直接把dashboard的JSON文件放在指定目录下Grafana启动时自动加载。这样配置变更可追溯回滚也方便。具体配置是在grafana.ini里指定provisoning的路径[dashboards] provisoning /var/lib/grafana/dashboards把看板JSON文件放到这个目录后重启Grafana就会自动导入。如果团队还在用旧版的“导出/导入”方式建议尽早切换到Provisioning体验差距很大。6.3 多人协作和权限控制最后说说权限。Grafana默认情况下所有看板对登录用户可见可操作如果团队成员不具备但能误改配置风险不小。建议在Grafana里创建“Viewer”“Editor”“Admin”三类账号日常值班同学只给Viewer权限可以看但无法修改面板。需要调整面板的同学给Editor权限管理员保留少数。这样即使有人误操作也能通过权限限制把影响范围降到最小。腾讯云可观测平台那边同样也要做好子账号隔离监控查询和告警配置的权限分开避免无意的配置变更。我自己在使用这套体系的过程中最深的体会是监控看板不是做得越复杂越好而是越“好读”越好。Polystat面板最打动我的地方就是把一张看板变成了一个极简的指挥中心告警信息、资源状态、容量风险都能在同一屏里传达出来。找一个周末把腾讯云上的资源按这个思路接进来搭一面属于你自己的“状态灯墙”日常运维会轻松不少。 Grafana Polystat面板与腾讯云可观测平台融合的云监控看板实践
Grafana Polystat面板与腾讯云可观测平台的深度融合实践做运维这么多年手头管着的服务器从几十台涨到几百台监控看板也从最初几张凌乱的图表慢慢收敛成一套稍微像样的体系。Grafana一直是我这边的主力可视化工具Prometheus、Loki、告警规则全往里面塞看板数量多了以后反而暴露出一个新问题——信息密度不够。传统的时间序列图适合看趋势但如果你是早上一睁眼就想知道“线上几十台机器里有没有哪台CPU爆了、哪台云数据库连接数快满了”一张折线图根本看不过来。这时候特别需要一种“一屏扫完所有状态”的面板。我最早是在开源社区看到有人在用Polystat第一反应是这玩意儿有点意思把一堆指标变成一个个动态色块绿就是正常红就是异常不用逐台点开详情。后来配合腾讯云可观测平台的数据源把云上资源的状态也接进来才真正跑起来一套“混合视角”的运维看板。这篇文章重点记录我自己的整合过程和踩坑记录包括腾讯云可观测平台的数据怎么进Grafana、Polystat面板的JSON配置到底怎么折腾、阈值状态怎么设计才不误报以及后面做模板变量、做告警联动时遇到的一些细节。想直接在Grafana里把云上资源“做成色块墙”的朋友可以按这篇的步骤从头走一遍。1. 为什么要把Polystat面板和腾讯云可观测平台放在一起1.1 从一块看板说起的运维痛点先说个真实场景。我们有套业务部署在腾讯云上资源倒不算特别多但种类杂云服务器CVM、云数据库MySQL、负载均衡CLB、对象存储COS还有少量容器服务TKE。过去排查问题的方式是先打开Grafana里按照资源类型拆出来的好几个dashboard一个个切下拉框选实例再看CPU、内存、延迟、错误码。这套流程最大的问题就一个字——慢。线上告警响了以后你根本来不及把每个资源都点一遍。有一次线上交易量下跌我花了十分钟才发现是某一台CVM的磁盘IO被打满了而那台机器在整张看板里只是一个不起眼的尖刺。那次之后我就下定决心一定要有一张“打开就能扫一眼”的总览看板把关键资源的关键指标全部平铺在一个屏幕上状态一眼可见。Grafana的默认面板体系里其实没有特别好的“多状态总览”方案。表格面板能做但不直观看数字和看颜色完全是两种体验singlestat又太老功能有限后来社区里有人重度使用Polystat我发现它正好解决了这个问题。Polystat的核心逻辑是在一张面板里用N乘M的网格展示多个指标每个格子显示一个值并根据阈值动态变化颜色。整个看板的结构就像一面“状态灯墙”绿、黄、红一目了然。1.2 Polystat面板的独到之处Polystat这个面板插件的全名是“Polystat Panel”作者是Grafana社区里一位长期活跃的开发者。它最常见的用途是数据中心机房监控把一台台服务器的状态做成一个个小方块但我把它用在云资源监控上也完全成立。它的优势我总结下来有三点。第一信息密度极高。传统的时间序列面板一屏最多看四五个指标再多就糊了。Polystat面板可以同时展示几十个甚至上百个独立“状态格子”每个格子独立配置查询和阈值这对总览场景是质变式的体验。第二状态表达非常直接。格子颜色可以绑定阈值范围比如CPU使用率低于60%是绿色、60%到85%是黄色、超过85%是红色。值班的人不需要看具体数字只看颜色就能定位异常范围。而且面板支持自定义显示文本可以在格子里显示“实例名 当前值”或者“实例名 状态”比纯数字直观得多。第三支持超链接下钻。我实际使用中最喜欢的一个功能是格子可以绑定点击事件跳转到另一个dashboard并且自动带上当前实例的过滤条件。也就是说你可以在总览页看到一个红色格子点击它就直接跳转到这台实例的详细监控页马上看曲线、查日志。这比在多个面板之间手动切换高效太多。1.3 腾讯云可观测平台在里面扮演什么角色聊完了面板再聊数据。腾讯云可观测平台是腾讯云官方的一站式监控产品体系里面包含了云产品监控、Prometheus托管服务、应用性能监控APM、日志服务等多个模块。对我来说最核心的一个能力是云上所有资源的监控指标全部可以通过API批量拉取而且大多数指标在控制台上能看到什么在API里就能拿到什么。它和Grafana之间的关系其实取决于你走哪条路接入。腾讯云官方提供了Grafana数据源插件安装之后你用云API密钥认证就能在Grafana里直接查询云监控的指标数据不需要自己在中间搭建采集器。另一种方式是使用腾讯云Prometheus托管服务它自带了指标采集能力Grafana配置这个Prometheus数据源之后就能用PromQL查询云原生组件的指标。这两种方式我都在生产环境里跑过各有各的适用场景后面第2部分我会展开讲。简单说如果只是想把云资源的CPU、内存、网络流量这类基础监控接到Grafana官方云监控数据源插件最省事如果你在TKE里跑容器化应用同时需要自定义指标那走托管Prometheus更合适。2. 数据接入让腾讯云指标流入Grafana2.1 数据接入的两种主流路径对比在动手配置之前一定要先想清楚数据接入的路径。这个选型决定了后面所有面板怎么写查询语句也决定了指标粒度、历史数据保留和告警能力。我把自己踩过的两种方案整理成一张对比表方便你根据自己手头的资源情况做选择。对比维度腾讯云云监控数据源插件腾讯云Prometheus托管服务接入复杂度低安装插件后配置密钥即可中需要开通托管实例并配置采集规则数据范围云产品监控指标CPU、内存、流量等开箱即用云原生指标 自定义指标可采集容器和业务侧数据查询语言类SQL/点选式官方插件封装好维度过滤PromQL历史数据依赖云监控侧的数据保留策略依赖Prometheus自身存储配置告警方式可在Grafana做告警也可以在云监控控制台配置推荐用Prometheus告警规则也可接Grafana告警适合场景以云产品资源为主快速出图有容器、K8s、自定义业务指标需要更灵活的查询我自己这边的选择是“两条腿走路”。基础云产品监控CVM、CLB、云数据库等走官方数据源插件因为这类指标开箱即用、维度清晰插件里封装好了按实例ID过滤的逻辑查询写起来快。TKE里容器和业务侧的自定义指标走Prometheus托管服务因为PromQL在复杂聚合场景下的表达能力更强。2.2 配置腾讯云云监控数据源插件的完整步骤如果你决定先用官方云监控数据源插件把数据接进来那操作步骤大概是这样的。先说明一下我以Grafana 10版本为例不同版本的菜单层级可能会略微有差异但总体思路是一样的。第一步是安装插件。如果你的Grafana运行在Linux服务器上可以直接在Grafana的bin目录下执行grafana cli命令grafana cli plugins install grafana-tencentcloud-monitor-app安装完成之后重启Grafana服务然后在Grafana的“Configuration - Plugins”页面找到腾讯云监控插件点击“Enable”启用。如果是在容器环境部署的Grafana可以通过环境变量ENABLE_PLUGINS或在Docker启动命令里加载插件目录方式稍有不同但核心都是把插件文件放到Grafana的plugins目录下。第二步是在Grafana里新增数据源。进入“Configuration - Data sources”点击“Add data source”找到腾讯云监控相关的数据源类型。这里需要填三个关键信息SecretId、SecretKey和Region。SecretId和SecretKey是你在腾讯云访问管理CAM里创建的API密钥建议单独创建一个只读权限的子账号密钥权限范围限制在DescribeMetricData等监控查询接口避免主账号密钥泄露造成大范围风险。Region可以填写你资源主要所在的地域如果资源分布多地可以在查询时再调整。第三步是验证连通性。在数据源配置页的底部点击“Save Test”如果提示连接成功就说明密钥和网络都没问题。如果失败优先检查密钥是否正确、该子账号是否具备云监控只读权限。2.3 通过Prometheus托管服务接入容器指标再补充一下走Prometheus托管服务的情况。这种方式适合你已经在用TKE或者对自定义指标有强需求。腾讯云的Prometheus托管服务简称TPS开通之后会提供一个远程写入和查询的Endpoint你可以把Grafana的“Prometheus”类型数据源指向这个Endpoint。配置时要注意认证信息需要开一个Prometheus HTTP API的访问凭证通常是Token或者Basic Auth形式。你在TPS控制台创建实例后能看到对应的API地址和凭据填到Grafana数据源配置里即可。这类数据源的查询语言就是PromQLPolystat面板里的Query类型选择“Prometheus”然后写PromQL查询表达式。举个例子如果你想在Polystat面板里展示每个TKE工作负载的Pod重启次数可以写成这样的PromQLsum(kube_pod_container_status_restarts_total) by (namespace, pod)这类指标在原生Kubernetes监控里是现成的Prometheus托管服务会自动采集kube-state-metrics不需要额外写采集器。聚合维度根据你的场景灵活调整比如想按Node汇总、按Deployment汇总都是改一下by后面的label即可。3. Polystat面板核心配置与状态编排实战3.1 安装Polystat插件并创建第一个面板数据源准备好之后下一步就是让Polystat面板上场。安装同样是命令行操作grafana cli plugins install yesoreyeram-boomtheme-panel你可能注意到插件ID不大一样Polystat面板在Grafana插件仓库里的ID是yesoreyeram-boomtheme-panel作者是yesoreyeram。装完之后重启Grafana然后在新建面板时就能在可视化类型里找到“Polystat”选项。这里有个小技巧在创建面板时先选择Polystat类型再配置查询这样查询出的列和面板字段之间的映射关系会更直观。Polystat面板最核心的交互方式是通过JSON配置来控制显示逻辑和状态逻辑。第一次打开面板配置时你可能有点懵因为它左侧是标准的查询区右侧却是一大堆JSON选项。但搞清楚几个核心概念之后其实很好上手。3.2 理解面板的查询列与字段映射Polystat面板不像Graph面板那样自动把查询结果按序列画成曲线它是把查询结果“当作表格”来处理。每一行代表一个独立的格子每一列代表这个格子的某个属性。面板里用到的最核心字段是这三个metric格子的名称显示在格子内部通常用实例名或标签拼接value格子的当前数值决定格子显示什么也决定阈值判断取哪个数字status可选字段如果你希望状态和数值分离可以单独给一个状态列举个例子你想展示5台CVM的CPU使用率那么查询结果应该返回五行数据一列叫metric存放实例名一列叫value存放CPU使用率数值。在Polystat面板的JSON里你需要通过“metrics”配置告诉面板“metric列对应哪个字段value列对应哪个字段”。这个映射关系是Polystat配置里最重要的环节映射错了面板就显示不出来。我在实际使用中经常用Grafana的Transform来处理查询结果。比如默认的查询结果列名是“Value #A”不好识别我就在Transform里用“Organize”或者“Rename by regex”把列名改成value再用“Labels to fields”把Prometheus的标签变成独立的列。这样Polystat面板的JSON配置就会很干净。3.3 阈值规则与颜色状态设计Polystat面板的阈值配置通过“thresholds”字段控制这是整个面板的灵魂。阈值不是简单写一个数字而是一个数组每个数组元素包含一个值和这个值以上/以下对应的颜色和状态文案。我在生产环境里用的阈值规则一般是这样的结构thresholds: [ { value: 0, state: ok, color: green, text: 正常 }, { value: 60, state: warning, color: yellow, text: 预警 }, { value: 85, state: critical, color: red, text: 告警 } ]这里有个容易踩的坑Polystat的阈值判断逻辑是从高到低匹配的如果某个格子的值是50它不会命中第一段“0”而是会命中“60”这一档不对实际上它是先匹配最大的value如果当前值大于等于某个value就用这个value对应的状态如果小于最小value就用第一段的默认状态。所以上面这个配置的语义是85红色60黄色其他绿色。如果你想做小于某个值告警的指标比如内存可用量可以单独设计一套递减阈值或者把查询结果取负值反过来判断。颜色语义上也建议制定一个自己的规范。运维看板最重要的是快速识别风险所以颜色的含义必须全局统一。我的规范是绿色代表完全正常黄色代表性能劣化或容量接近临界红色代表需要立即介入的故障灰色则用于无数据或实例已下线。这样的好处是新来的同学看任何一张看板不需要额外解释就能明白。3.4 通过模板变量实现多环境复用Polystat面板真正强大起来是在配合模板变量之后。模板变量是Grafana里的一种动态过滤机制可以通过下拉框切换环境、地域、业务分组等维度让同一张看板在不同范围内复用。我这边默认配置了几个变量env环境维度可选值生产、预发、测试region地域维度app业务应用维度。变量的查询来源可以是另一个数据源也可以是Prometheus里的标签值。比如app变量可以通过PromQL查出来label_values(kube_pod_info, app)然后在Polystat面板的查询语句里引用变量SELECT instance_id, cpu_usage FROM metric WHERE region $region AND app $app面板的标题也可以带上变量这样切换下拉框时看板标题会同步变化方便截图留档。Polystat格子数量比较敏感如果查询结果显示的数据行数非常多比如几百个Pod一屏塞满会非常拥挤。我的经验是控制在50个格子以内超过50个就拆分成多个面板或者用变量分组先看一组再看另一组。格子太多以后字号会变小颜色区分度也会下降反而失去总览的意义。4. 完整落地案例某在线业务系统全景监控看板4.1 场景设定与监控目标为了让你更直观地理解整个配置流程我用一个具体的案例把流程串起来。假设我们有一个在线预订系统部署在腾讯云上组件包括4台CVM承载Nginx和业务进程2台云数据库MySQL承载订单数据2个CLB负载均衡对外提供入口另外还有若干COS bucket存放静态资源。监控目标是在一张总览看板上用不超过5秒的时间判断整个系统是否健康。我把指标核心圈定为四类CVM的CPU使用率、内存使用率、磁盘IO云数据库MySQL的连接数使用率、慢查询数CLB的QPS、后端异常率COS的存储量和请求错误率。所有这些指标全部来自腾讯云可观测平台通过官方数据源插件查询。4.2 指标选择与查询编写我通常会在Grafana里先用Explore功能验证查询确认数据源返回的字段名和值没问题再复制到Polystat面板里。这一步很关键可以避免在面板配置里来回调试。以CVM CPU使用率为例腾讯云监控数据源插件通常支持这样的查询方式选择命名空间Namespace为QCE/CVM指标名为CPUUsage然后按实例ID过滤。有些插件版本还支持直接用Region过滤。返回结果里会带instanceId和instanceName标签这两个正好可以映射到Polystat的metric字段。SQL类的查询可能是这样SELECT instanceId, instanceName, CPUUsage FROM QCE/CVM WHERE region ap-guangzhou如果你的数据源插件不支持这种SQL语法而是用“Metric Find”之类的下拉选择同样能实现只是写法上按UI选项来。另外需要特别说明的是腾讯云监控类指标大部分是有采集周期的默认可能是60秒一次。如果你创建面板后发现数值更新不够实时可以在查询里加一个周期参数“period”或者接受默认值。总览型看板不需要秒级刷新每分钟或者每两分钟刷新一次就足够太频繁反而容易被云监控API限流。4.3 Polystat面板JSON配置实例当所有查询都准备好了下面是我用的一套核心JSON配置你可以对照着改。这是Polystat面板的Settings部分不是整个dashboard的JSON面板级的JSON配置在编辑面板时切到“JSON”页签就能看到。{ metrics: [ { name: metric, label: 资源名, type: string }, { name: value, label: 当前值, type: number } ], display: { unit: percent, decimals: 0, showName: true, showValue: true, size: 30, textMode: value-and-name, background: solid }, thresholds: [ { value: 0, state: ok, color: green, text: 正常 }, { value: 60, state: warning, color: yellow, text: 预警 }, { value: 85, state: critical, color: red, text: 告警 } ], global: { decimals: 0, unit: percent }, enableContextMenu: true, enableNewStatus: true, enableNewLayout: true, clickThrough: { url: /d/xxxxx/instance-detail?var-instance${metric}, openInNewTab: true }, layout: { horizontal: 8, vertical: 4 } }这个配置里几个字段稍微解释一下。display.size控制格子内字体大小一般30到35比较合适textMode选择value-and-name这样格子里既能显示实例名又能显示当前数值信息量最大。background设置为solid颜色填充整个格子比只改变文字颜色醒目很多。clickThrough这个字段是点击下钻跳转的配置我这里的url是一个示例实际使用时把/d/xxxxx/instance-detail替换成你自己的实例详情看板ID${metric}会被替换成当前格子的metric值从而实现点击格子跳转到对应实例详情。这个功能在一次线上故障排查时帮我省了大量时间强烈建议设置好。4.4 从数据接入到看板上线的完整操作流说完了JSON再把整个操作流从头到尾过一遍方便你按步骤复现。第一步确认数据源。无论你是用云监控数据源插件还是Prometheus托管服务都要确保Grafana里的Datasource配置正常Test通过。第二步创建文件夹和Dashboard。建议单独建一个“总览看板”的文件夹别和生产环境的其他临时看板混在一起。Dashboard创建好之后添加一个Panel选择Polystat类型。第三步配置查询。在Query区选择你的腾讯云数据源添加多个查询每个查询对应一类资源指标。比如Query A查CVM CPUQuery B查MySQL连接数Query C查CLB异常率。Polystat面板支持多条查询结果自动合并显示在同一个网格里这是我特别看重的一个能力。第四步配置JSON和阈值。把上面那段JSON配置粘贴到面板JSON里注意修改阈值范围和颜色匹配你的业务需求。如果你的查询结果列名不是metric和value记得同步修改metrics映射关系。第五步调整布局。在编辑面板时你可以在可视化区域手动拖拽网格也可以直接通过layout字段指定横向和纵向格子数量。假设你有10个资源需要展示横向5格、纵向2格就挺协调。格子大小保持正方形视觉上最舒服。第六步设置刷新周期和告警。面板右上角设置Dashboard刷新周期建议1分钟或2分钟。如果你还需要告警通知可以在Polystat面板的Alert页签里把某个查询值的阈值条件转成Grafana告警规则关联到企业微信或邮件通知。不过我更推荐告警单独用云监控控制台配置毕竟是云厂商官方通道稳定性和通知渠道集成都更靠谱。5. 常见问题与排查技巧实录5.1 常见问题速查表把我在实际使用中碰到的高频问题整理成一个表遇到类似情况可以直接按着排查。问题现象常见原因解决办法面板显示“No data”查询条件里地域、实例ID不对或者数据源权限不足先在Explore里跑同样的查询确认返回数据格子全是灰色查询返回的value字段为null或字段映射不匹配检查JSON配置metrics字段里的name是否和查询列名一致阈值颜色不生效阈值顺序或判断逻辑没搞对或者阈值字段没对应到value把thresholds配置改成从高到低的数组确认state字段正确格子特别多显示特别拥挤查询结果行数太多超出了面板设计容量用模板变量缩小范围或拆分成多个面板点击格子不跳转clickThrough.url配置错误或变量名不匹配检查URL里是否使用了${metric}确保它和metric列名称一致刷新时API被限流单数据源查询次数过于频繁调大Dashboard刷新周期减少仪表盘同时刷新的面板数量5.2 数据源权限与限流处理腾讯云监控数据源API是有频控的这一点官方文档里写得不明显但在实际使用中非常容易触发。我记得有一次在调试阶段为了测试不同查询效果把刷新周期改成了5秒结果没几分钟就报了一堆“API rate limit exceeded”错误。后来我总结了一套规避限流的策略。第一总览类看板的刷新周期控制在1分钟以上别想着实时刷新总览看板的意义在于快速定位不在于秒级精度。第二把多个查询合并成一个查询尽量避免一个面板里挂8个以上的查询减少API调用次数。第三如果资源真的很多可以按腾讯云控制台里的“实例分组”维度来查询将多个实例聚合到一个返回值里而不是每台实例单独查询。比如CPU使用率可以查询平均值GroupBy设置在region维度返回值减少限流风险大大降低。权限方面也要注意。腾讯云API密钥建议到期轮换子账号只授予“云监控只读”策略具体操作是在CAM里新建策略选择“QcloudMonitorReadOnlyAccess”。这样做的好处不只是安全还能避免手滑在Grafana里误操作云资源比如运行某些高风险API。5.3 面板性能与告警联动优化Polystat面板在数据量大的时候渲染性能会有明显波动。我的经验是如果单面板的格子数超过100个浏览器渲染就会出现卡顿尤其在切换模板变量时会出现白屏或延迟。这个问题的优化路径有三个方向。第一减少数据量。查询时用更多过滤条件只保留真正需要关注的资源。比如只展示“运行中”状态的实例把已销毁的过滤掉。第二简化配置。JSON配置越复杂面板渲染时做的工作越多不必要的link、style尽量别加。第三硬件层面给Grafana实例分配更多内存但这只是兜底方案治标不治本。关于告警联动我建议不要把所有告警都压在Grafana上。Polystat面板适合做可视化状态展示但告警通知最好交给腾讯云可观测平台通过云监控控制台配置告警策略通知渠道可以选择企业微信、短信、电话稳定性远高于Grafana自身告警。两者分工是Grafana负责“看清楚”云监控负责“喊出来”。面板显示异常是一回事通知到人又是另一回事整个体系里两个环节缺一不可。6. 生产环境落地的几点额外建议6.1 看板命名与目录规范规模稍微上来之后看板数量一多命名不统一就会很痛苦。我的建议是建立一套自己的导演规则比如“层级-业务-资源-用途”命名的模式。“总览-CoreOrder-CVM-CPU”这样的名称存活期绝对比“最终版看板”长得多。目录结构也可以按业务域划分比如“线上核心链路”“离线加工链路”“基础设施公共组件”把总览看板放在每个目录最显眼的位置双击就能打开。另外Grafana的看板可以通过JSON导入导出团队协作时把写好的Polystat看板JSON导出发给同事对方只需调整数据源UID就能复用。这一步我用的频率很高新环境起监控看板基本都是从旧环境导出几个典型看板然后改配置。6.2 备份与版本管理Polystat面板的JSON配置比较长稍微改错一个符号就会导致面板失效所以我习惯把看板JSON纳入Git管理。Grafana有Provisioning机制可以直接把dashboard的JSON文件放在指定目录下Grafana启动时自动加载。这样配置变更可追溯回滚也方便。具体配置是在grafana.ini里指定provisoning的路径[dashboards] provisoning /var/lib/grafana/dashboards把看板JSON文件放到这个目录后重启Grafana就会自动导入。如果团队还在用旧版的“导出/导入”方式建议尽早切换到Provisioning体验差距很大。6.3 多人协作和权限控制最后说说权限。Grafana默认情况下所有看板对登录用户可见可操作如果团队成员不具备但能误改配置风险不小。建议在Grafana里创建“Viewer”“Editor”“Admin”三类账号日常值班同学只给Viewer权限可以看但无法修改面板。需要调整面板的同学给Editor权限管理员保留少数。这样即使有人误操作也能通过权限限制把影响范围降到最小。腾讯云可观测平台那边同样也要做好子账号隔离监控查询和告警配置的权限分开避免无意的配置变更。我自己在使用这套体系的过程中最深的体会是监控看板不是做得越复杂越好而是越“好读”越好。Polystat面板最打动我的地方就是把一张看板变成了一个极简的指挥中心告警信息、资源状态、容量风险都能在同一屏里传达出来。找一个周末把腾讯云上的资源按这个思路接进来搭一面属于你自己的“状态灯墙”日常运维会轻松不少。