For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
数据收集与分析随着互联网的不断发展而被越来越多的程序员掌握,许多人也在学习达内数据分析的相关课程知识,而本文我们就简单来了解一下。调用链主要因素与实践。
数据收集部分
主要用于多样化的数据收集,为数据分析做准备。要求易用好用侵入尽量小(开发工作量),并且在极端情况下(如收集组件不可用)不能对业务有任何影响。可以看到此部分的开发量是巨大的,尤其是需要集成Nginx上下游、基础组件多样、技术栈多样的情况下。
数据分析部分
主要有实时分析与线下分析。一般,实时分析的价值更大一些,主要产出如秒级别的调用量、平均响应时间、TP值等。另外,调用链(Trace)需要存储全量数据,一些高并发大埋点的请求,会有性能问题。
监控报警
此部分利用数据分析的产出,通过短信邮件等形式,通知订阅人关注。监控报警平台应尽量向devops平台靠拢,包括自主化服务平台。
实现方式分析
根据收集方式可分为日志收集方式和程序实现方式
日志收集方式
日志收集方式与传统的ELK链路差不多。主要通过日志组件,打印出符合规范的日志格式。Flume守护进程会读取、过滤这些日志,将数据Sink到kafka集群中。会接收一份全量数据(调用链需要)到ES中供查询分析;同时接收一份日志使用Spark或Strom方式分析出需要的数据,存结果。
主要开发量集中在日志组件和各个模块的组合调试中。另外,由于需要在每台宿主机上安装配置flume-agent,此模式依赖完善的运维体系,可使用jenkens或者ansible集成支持。
手动埋点方式
这种方式采用业务端直推的方法,将数据直接汇集到kafka中。客户端一般会开一个堆上的缓冲区,将有单独的线程定时上报缓冲区数据。数据落地到kafka后,后续的处理类似。
为了支持易用性,需要较多的开发工作和可用性设计不会因为Trace组件或者Kafka的不可用造成服务的不可用。
此种方式的主要坏处是,功能是以jar包方式提供的,如有重大bug或者改动,所有服务都必须重新发布。
监控报警
一般的,grafana等组件即可满足需求,够用,并能够快速实现。但其方式,仅仅能展示数据,需要肉眼盯盘,如果有更灵活的监控需求,不支持。
监控曲线,应该能够发现系统性能瓶颈,为扩容、缩容提供决策依据。
同比、环比、斜率,包括报警,需要进行开发(报警和历史走势),功能不复杂,但需要考虑以下问题:
报警接收人变更,是否能及时支持
报警阈值调整,是否需要走工单等复杂流程
是否能查看历史报警和处理的报警,并依此评价响应速度
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。