1. 原监控体系的优缺点
宜泊核心业务使用公有云平台的基础资源,使用云平台自带的云主机监控,prometheus 用于容器环境的监控,grafana 看板和告警服务。现有大多数apm 工具做应用链路追踪,因为代码插桩原因,造成应用响应延时明显增加。出于对业务稳定性考虑,暂时仍通过增加业务日志来监测应用状态,收到的数据比较分散,需花费较多排查时间。
2. 为什么关注观测云
了解到观测云可以使用一个采集器就实现日志、指标和链路数据采集,在统一平台进行存储、计算、查询和分析,对云资源基础设施、中间件、网络、应用进行全栈数据统一关联。原有的监控方案需要安装多个不同 exporter 或者采集器,数据分开存放,本身就有不小的资源消耗。对观测云的全功能采集器和统一存储思路很感兴趣,希望可以在不增加甚至降低系统开销的情况下,获得更全面的运行状态数据,实现全链路可观测,帮助团队快速发现问题和定位根因。
使用观测云
1. 主要场景
宜泊科技作为智慧停车场bingoplus的解决方案提供商,主要业务之一是智能无人停车平台,为机场、写字楼、商场等停车场提供数字化智能服务。近年来随着全国用车需求增长,宜泊系统的每日服务频次也在持续上升,且还需不断加快服务响应速度,以满足车辆更快节奏进出停车场的需求。
针对在线的业务系统,特别是停车场无人收费系统,需要从宏观到细节,全面观测整个系统的运行状态,利用全链路分析能力,及时发现和排除故障。
2. 细节展示
写字楼、工业园区等区域的停车场在高峰期时段,如果某个服务出现异常,用户无法进行停车缴费,会出现停车场出入口拥堵现象,如果长时间未能处理,只能放杆通行,会直接产生经济损失,因此对问题处理的时效性要求较高。
以前遇到这样的情况,需要相关的运维、开发人员全线核查定位,各自负责的服务所在容器查找对应时段的日志,再根据运维人员和开发人员的经验判断,进行分析定位,在异常处理时效性上具备挑战。
使用观测云平台后,可以通过 dataflux function 组件将云监控指标数据接入平台,与业务指标、日志、链路做统一关联,实现从宏观到微观,从前端到、中间件,到后台的整体可观测,快速溯源,大大提高问题处理速度。
在用户访问监测(rum)、应用性能检测(apm)、日志等功能界面,灵活自主选择出现问题的时间段,快速查找到该时间段内所有链路信息,并宏观展示请求数、错误请求数和响应时间:
由此可见,响应时间持续上升,通过“快捷筛选”功能筛选出该时段出现错误的链路。下钻到出现错误的链路属性,通过火焰图、span列表和服务调用关系,可直接找到出错的服务,各服务执行时间占比,以及链路详情信息:
由此,便直接定位到此处执行 mysql 查询时出错,开发人员可快速查找到代码,进行修复。
通过链路关联云监控的rds mysql 指标数据,即可发现此处iops使用率等是否有突增情况,运维人员可判断是否需要申请资源调整。
3. 对观测云的使用规划
观测云已经在我们的预发环境和部分生产环境中完成了部署,已展现出了强大的全链路可观测能力,同时对系统性能几乎没造成额外负担,为我们提供了非常可靠的可观测性bingoplus的解决方案。后续我们会通过灰度发布,在更多生产环境部署观测云,希望观测云可以帮助我们提前发现系统的性能瓶颈点,对潜在风险进行优化,提高整体稳定性。观测云的确是一款可以持续升级和演进的产品,我们会与观测云团队共同搭建适合我们业务场景的仪表盘,更高效地实时感知系统各层面的运行状况。