企业官网建设流程全解析

如何用ps做网站首页的图片,网站设计公司 宁波,wordpress数据过滤,周口seo公司写在前面在我们公司#xff0c;订单团队想看订单创建失败数#xff0c;支付团队关心支付超时率#xff0c;库存团队盯着库存扣减失败……但他们不会写 PromQL#xff0c;也不懂 Grafana 的 Panel 配置。每次都要找 SRE 帮忙建 Dashboa…写在前面在我们公司订单团队想看订单创建失败数支付团队关心支付超时率库存团队盯着库存扣减失败……但他们不会写 PromQL也不懂 Grafana 的 Panel 配置。每次都要找 SRE 帮忙建 Dashboard业务团队等 SRE 响应少则半天多则几天SRE 团队重复劳动一个 Dashboard 配 10 分钟10 个业务组就是 100 分钟后续维护新增指标要手动改 Dashboard删除指标要手动清理Dashboard 数量爆炸我们决定换个思路让业务团队自助配置让 SRE 从Dashboard 工程师中解放出来。于是设计了一套基于指标分组的可视化方案管理员配置一次指标组业务组自助查看新增指标自动出现在菜单中无需手动维护系统自动适配时间范围、多维标签、指标类型本文分享我们的设计思路与关键实现。一、我们想解决什么问题1.1 痛点场景假设你的 Prometheus 已经采集了 100 个业务指标order_create_failed_total 订单创建失败 order_timeout_total 订单超时 payment_failed_total 支付失败 stock_insufficient_total 库存不足 ...还有 96 个不同的业务组只关心自己的指标但现状是所有指标混在一起难以快速定位每个业务组都要去 Grafana 手动创建 Dashboard新增指标后需要手动维护 Dashboard我们想要的效果订单团队打开页面 → 点击订单监控 → 自动展示订单相关的所有指标支付团队打开页面 → 点击支付监控 → 自动展示支付相关的所有指标无需学习 PromQL无需配置 Grafana1.2 我们的解决方案6步搞定光说不练假把式下面是我们的完整思路步骤1把指标列出来系统自动从已有的告警规则中提取所有 Prometheus 指标展示在管理页面✓ order_create_failed_total 订单创建失败 ✓ order_timeout_total 订单超时 ✓ payment_failed_total 支付失败 ✓ stock_insufficient_total 库存不足步骤2按业务分组管理员创建指标组把相关指标加进去 指标组订单监控 ├── order_create_failed_total ├── order_timeout_total └── order_cancelled_total 指标组支付监控 ├── payment_failed_total ├── payment_timeout_total └── refund_error_total配置时间30 秒步骤3菜单自动生成刷新页面后左侧导航自动出现二级菜单系统菜单 └── Metrics查看 ├── 订单监控 ← 自动生成菜单名 指标组名 ├── 支付监控 ← 自动生成 └── 库存监控 ← 自动生成关键无需手动编辑菜单配置无需重启应用。步骤4点击就能看图点击订单监控菜单系统自动做三件事① 查询 Prometheus查询order_create_failed_total 查询order_timeout_total 查询order_cancelled_total② 根据类型智能展示Counter计数器→ 显示整数246 次Gauge瞬时值→ 显示整数128 个连接Summary/Histogram → 显示小数1.25 秒③ 根据标签自动分曲线同一个指标如果有多个标签自动画成多条曲线order_create_failed_total ├─ error_typenetwork, regioneast → 蓝色曲线 ├─ error_typedatabase, regionwest → 红色曲线 └─ error_typetimeout, regionnorth → 绿色曲线步骤5选择时间范围页面顶部提供时间选择器系统自动调整采样粒度时间范围采样间隔为什么15分钟15秒/点数据密集精细查看1小时30秒/点平衡性能和可读性3小时1分钟/点避免数据点过多6小时2分钟/点长期趋势观察好处图表不会密密麻麻性能也不会差。步骤6角色分离管理员SRE后台配置指标组一次配置全员使用业务组打开页面点击自己关心的菜单立即查看业务组不需要学 PromQL、配 Grafana、维护 Dashboard。1.3 效果对比对比项Grafana我们的方案新增监控创建Dashboard → 添加Panel → 写PromQL → 调样式10分钟添加到指标组30秒业务分组手动创建多个Dashboard自动生成菜单学习成本需要学PromQL语法点击菜单即可维护成本每个业务组一个Dashboard数量爆炸零维护自动化二、为什么不用 Grafana2.1 Grafana 的局限Grafana 是优秀的工具但在我们的场景下有些重学习曲线陡峭需要掌握 PromQL、Dashboard/Panel 概念静态配置每次新增指标需要手动添加 Panel配置以 JSON 保存缺少业务视角默认按技术维度服务、实例、端点难以按业务场景分组Grafana 更适合需要高度自定义、复杂查询的专业运维团队。2.2 借鉴 SkyWalking 的思路SkyWalking 在 APM 领域的可视化做得很好多维度自动分组基于 Trace Tag智能图例展示自动拼接标签根据指标类型智能选择展示方式我们借鉴了这些思路但适配到业务告警场景无需 Agent。三、如何处理不同类型的指标Prometheus 有四种指标类型需要区别对待3.1 Counter 和 Gauge显示整数// Counter只增不减订单数、错误次数 // Gauge可增可减连接数、内存使用量 if (metricType counter || metricType gauge) { displayValue Math.round(value) // 246 而不是 246.66 }3.2 Summary 和 Histogram保留小数// 响应时间、百分位数等需要精确展示 displayValue value.toFixed(2) // 1.25 秒3.3 多维度标签自动分曲线同一个指标可能有多个维度Label自动分组展示// 遍历 Label拼接成图例 const nameParts [] Object.keys(metric).forEach(k { nameParts.push(${k}${metric[k]}) }) const displayName nameParts.join(, ) // 结果 // payment_methodalipay, error_typetimeout, regioneast // payment_methodwechat, error_typebalance, regionwest效果一张图自动展示多条曲线每条曲线对应一个标签组合无需手动配置。四、核心设计指标组概念4.1 为什么需要指标组我们需要一个介于 Dashboard 和 Panel 之间的抽象Dashboard 太重一个 Dashboard 完整的可视化页面配置复杂Panel 太细单个图表没有业务语义指标组刚好承载业务语义订单监控、支付监控又足够灵活业务场景举例 指标组订单监控 ├── 关键词规则日志匹配 OrderCreateFailed ├── 关键词规则日志匹配 OrderTimeout └── 查询规则SELECT COUNT(*) FROM orders WHERE statuscancelled4.2 动态菜单如何实现数据流配置指标组 → 保存到数据库 → 前端加载 → 动态生成菜单动态特性新增指标组 → 菜单自动出现删除指标组 → 菜单自动消失修改指标组 → 菜单标题自动更新启用/禁用 → 菜单显示/隐藏关键配置即生效无需重启应用。五、关键技术实现5.1 前端怎么做动态菜单实现① 数据库表设计简化版-- 指标组表 CREATE TABLE alarm_metric_group ( id INT PRIMARY KEY, group_name VARCHAR(100), -- 指标组名称 icon VARCHAR(50), -- 图标 enabled TINYINT(1) -- 是否启用 ); -- 指标组明细表 CREATE TABLE alarm_metric_group_item ( id INT PRIMARY KEY, group_id INT, -- 指标组ID rule_type VARCHAR(20), -- 规则类型keyword/query rule_id INT, -- 规则ID metric_name VARCHAR(200) -- Prometheus指标名称 );② 前端状态管理Vuex// 应用启动时加载指标组 const actions { async loadGroups({ commit }) { const res await getMetricGroupList({ enabled: 1 }) commit(SET_GROUPS, res.data || []) } }③ 动态菜单渲染核心逻辑// Sidebar 组件 computed: { menuRoutes() { // 静态菜单 const staticMenus [ { name: RuleManage, path: /rule-manage, meta: { title: 规则管理 }} ] // 动态菜单从 Store 获取指标组 const dynamicMenus this.$store.state.metricGroups.list.map(group ({ name: MetricView_${group.id}, path: /metric-view/${group.id}, meta: { title: group.group_name, // 菜单名 指标组名 icon: group.icon } })) // 合并创建Metrics查看父菜单 if (dynamicMenus.length 0) { const parent { name: MetricsView, meta: { title: Metrics查看 }, children: dynamicMenus // 动态子菜单 } return [...staticMenus, parent] } return staticMenus } }关键点使用computed属性数据变化时自动重新渲染路由参数化/metric-view/:id通过 ID 区分指标组5.2 后端怎么查接口设计接口1查询启用的指标组GET /api/metric-groups?enabled1返回{ code: 200, data: [ {id: 1, group_name: 订单监控, icon: shopping-cart}, {id: 2, group_name: 支付监控, icon: wallet} ] }接口2查询指标组的详细指标GET /api/metric-groups/:id/metrics核心 SQL关联查询SELECT i.metric_name, CASE WHEN i.rule_type keyword THEN k.rule_name WHEN i.rule_type query THEN q.query_name END AS rule_name FROM alarm_metric_group_item i LEFT JOIN alarm_keyword_rule k ON i.rule_type keyword AND i.rule_id k.id LEFT JOIN alarm_query_rule q ON i.rule_type query AND i.rule_id q.id WHERE i.group_id ?接口3查询 Prometheus 指标数据GET /api/metrics/overview?startxxxendyyystep15后端根据时间参数查询 Prometheus返回时序数据。5.3 时间范围自适应设计思路时间范围越大采样间隔越粗避免数据点过多。getTimeRangeParams() { const now Math.floor(Date.now() / 1000) let start, step switch (this.timeRange) { case 15m: start now - 15*60; step 15; break // 15秒 case 1h: start now - 60*60; step 30; break // 30秒 case 3h: start now - 3*60*60; step 60; break // 1分钟 case 6h: start now - 6*60*60; step 120; break // 2分钟 } return { start, end: now, step } }六、完整流程示意6.1 配置流程管理员操作管理员管理页面数据库创建指标组订单监控INSERT INTO alarm_metric_group添加规则到指标组INSERT INTO alarm_metric_group_item刷新页面SELECT * WHERE enabled1返回指标组列表菜单中出现订单监控管理员管理页面数据库配置时间30 秒6.2 查看流程业务组操作业务人员页面后端Prometheus点击订单监控GET /metric-groups/1/metrics返回指标列表选择1小时GET /metrics/overview?step30QueryRange()时序数据JSON拼接Label、格式化显示多条曲线图表业务人员页面后端Prometheus查看时间 2 秒七、适用场景与局限性7.1 适合的场景业务告警监控已有告警规则需要按业务组分组查看日志分析场景基于关键词规则匹配日志数据库查询监控基于 SQL 查询生成指标中小规模团队指标组 50 个单组规则 100 条7.2 不适合的场景复杂的 PromQL 查询需要聚合、计算、rate() 等复杂运算 → 用 Grafana高度自定义 Dashboard需要特殊布局、自定义图表类型 → 用 Grafana分布式追踪需要 Trace 级别的监控 → 用 SkyWalking7.3 性能考虑当前设计的性能边界指标组数量建议 50 个单个指标组规则建议 100 条平均响应时间 2 秒可能的瓶颈指标组过多时菜单加载较慢 → 可增加缓存大量指标同时查询可能超时 → 可限制并发数大量图表同时渲染可能卡顿 → 可使用虚拟滚动八、写在最后这个方案上线后业务团队的反馈是终于不用等 SRE 了自己点点就能看。而 SRE 团队也从Dashboard 工程师回归到真正的稳定性建设中——不再被 10 分钟一个的配置请求打断。它不是万能的不适合复杂的 PromQL 查询不适合高度自定义的图表Grafana 依然是专业用户的首选但如果你也面临业务组太多每个都要单独配 Dashboard指标太多找起来很费劲非技术人员不会用 Grafana或许这个轻量级思路值得参考。