云监控和普通监控有什么区别?

云杉 世纪

2023年10月12日

产品资讯

随着科技的不断进步,监控系统也在不断升级。但与传统的监控方式相比,云监控带来了哪些不同呢?

首先,我们来看一下传统的监控方式。普通监控通常依赖于本地服务器和硬件,所有的数据采集、存储和处理都在本地完成。这种方式不仅成本高,而且扩展性差。对于大规模的监控需求,维护成本会逐渐增加。

相反,云监控如 DeepFlow 则是基于云计算平台构建的。DeepFlow 主要通过网络流量进行数据收集,并利用先进的技术如 eBPF、WASM 和 OpenTelemetry 实现了 AutoTracing、AutoMetrics、AutoTagging 等高度自动化的可观测性平台。

DeepFlow 的可编程能力和开放接口使得维护成本相对较低,能快速融入到自己的可观测性技术栈中。此外,DeepFlow 的一项调查表明,应用开发者有高达30%的时间花在可观测性能力建设上,DeepFlow 的自动化特点有助于降低这一比例。

总体来说,云监控提供了更高的灵活性和可扩展性,而 DeepFlow 的自动化特性更是将这一优势发挥到极致。

接下来,我们来深入探讨一下 DeepFlow 在云监控方面的其他优势。首先,DeepFlow 提供了高度可自定义的监控面板,用户可以根据自己的需求来配置各种监控参数和视图。这不仅增加了监控系统的灵活性,还使得用户能够更加方便地获取所需的信息。

其次,DeepFlow 还提供了一系列先进的数据分析工具,如高性能数据引擎和实时数据流处理。这些工具不仅可以用于监控数据的实时处理,还可以用于长期的数据分析和趋势预测。

总之,DeepFlow 不仅在基础的监控功能上表现出色,还在数据分析和自定义方面具有很高的优势。因此,无论是个人还是企业,都可以通过使用 DeepFlow 来大幅提升其监控系统的效能和可用性。

Related Posts

金融银行业可观测性方案

金融信创是金融机构重点投入以及技术迭代的方向,经过多年阶段迭代,进入难度更大的核心系统、关键业务系统的更替阶段。DeepFlow解决行业中普遍存在的分布式交易系统保障难、平台双轨多芯调优难、云上资源把控难、分布式数据库追踪难等挑战。

Read More

根因分析假 running 真故障 记一次电力行业的 SRE 实践

用户:某省级电网企业 挑战 定界困难:当发生故障,业务部门和网络部门互相推诿,而不是解决问题; 监控颗粒度不足:运维难以深入到POD维度,大量微服务的业务交互在虚拟机内已经完成业务交互; 全栈链路追踪难:电网要求运维能力覆盖整个业务链条,在微服务架构下,难以看到完整跨容器节点的全链条追踪数据; 定位方法单一:大部分运维工具功能单一,比如日志只可以查询日志,没办法进行指标,追踪、日志等联动定位。 用户期望 期望1分钟发现问题、15分钟研判问题、1小时内解决问题; 监控体系完成业务全覆盖、系统全覆盖; 全业务链条可追踪、可溯源。 这里交代了背景 经济发展,电力先行。作为国家电网旗下最年轻的某省级电网企业,链接东北和华北电网,承担着京津冀北区域电力供应的重要使命。于2012年2月9日正式成立,2017年实施了全业务数据中心的建设,并陆续完成四大数据中心的建设,实现了统一的数据共享与业务融合。 随着信息技术在电力行业经营管理中的广泛应用,越来越多的业务系统从传统的物理环境迁移上云,导致诸多电力业务系统如:营销系统、BPM、PMS2.0、各类6000系统,成分布式微服务化部署,系统环境也多为异构场景,混合云和云上云下的场景尤为凸显。网络分层导致电力行业的业务系统很难用传统的运维手段探测到全局的网络,网络故障发生时很难快速做到端到端的定位等等。 事件起因从这里开始 我(作为现场支撑人员也是小编本身)和电网企业的故事要从一次联合故障定位开始,在往常巡检的过程发现其中一个业务系统,内部微服务(POD)间有大量的建连失败,在 DeepFlow 中输入更多关于建连失败的指标量,如建连客户端 SYN 结束、建连服务端 SYN 结束、建连服务端直接重置等,下钻到流日志后发现了主要建连失败的原因:即客户端 SYN 结束表现形式为客户端多次尝试建连,但是服务端无回应,于是服务端口未放行或者服务端口失效。 为了验证是否下沉到业务侧,与南瑞 I6000 运维同事进行联合定位,在交流过程中用户并没有发现有任何问题,用户随即手动输入 POD 健康检查的命令发现没有响应,与我判断一致,表面上看所有业务都在正常 running,但是 POD 实际没有启动好,监控端口已经失联。为了缓解尴尬的场景用户调侃道“假 running,真故障”。 接着与用户进一步讨论时,发现使用的是 Livceness,可以制定检测规则,如果检测失败就会重启 POD ,全部是以 K8s 被动触发,手动检测会变的很复杂,甚至会出现一种假活现象。根据这次联合定位,我和用户运维部门做了一次深入的沟通,同时也从内心深刻的体会到:一个运维人员面对微服务场景下缺失可观测性能力的无力感。 首先 K8s 的产生是面向业务的,最大限度的保证服务的高可用,但是很多流量都是瞬发的,微服务(POD)在不停的自动化运转,根据工作负载,随时可能发生业务 POD 剔除或者重建的情况,导致微服务场景的监控变得非常复杂。 还有就是以目前的运维手段用户更在乎业务的可读性,也就是电力行业常说的小绿泡,绿色代表正常,红色代表异常,但这远远不能达到实际的运维要求。在和用户深入沟通的同时,我也根据产品能力,建立较为完善的应对措施,帮助用户提升整体运维能力。 首先需要站在用户实际的业务角度出发,完成个性化的运维场景定制。 通过 DeepFlow 丰富的监控指标,可以全面覆盖网络和应用层的R(吞吐)E(异常)D(时延)的场景况,结合目前较为先进的 SRE 方法论,优化故障发现到故障解决的时间,使得整体业务水平在一个良好的 slo(服务等级目标);并针对重要业务中发现过的故障进行重点监控和故障场景复现进行针对性优化,改变过去发现业务问题再做问题定位的被动情景,转变为主动检测、主动监控、主动告警的监控闭环。 接下来为了解用户实际的业务场景和容忍度,和运维部门针对运维指标开设了讨论会,建立丰富、贴合用户使用要求和习惯的 SLI 指标和基线,通过主动监测和建立健康度管理模型的方式,帮助用户发现潜在故障。并且当发现了某些指标不合格,快速进行告警推送到指定责任人手里,再联合 DeepFlow […]

Read More