如何快速构建高效的监控系统|学习笔记

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
可观测可视化 Grafana 版,10个用户账号 1个月
应用实时监控服务ARMS - 应用监控,每月50GB免费额度
简介: 快速学习如何快速构建高效的监控系统

开发者学堂课程【HBase 入门与实战如何快速构建高效的监控系统】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/808/detail/13901


如何快速构建高效的监控系统


内容介绍

一、最佳实践

二、实机演示

一、最佳实践

1、适应不同 APM 场景的 Lindorm 时序技术栈

APM 场景需要一系列的组件构建,Lindorm 时序引擎已兼容大多主流的 APM 开源组件,因此可适用于多种 APM 场景

对于常见的监控需求,推荐采用的 Lindorm 时序引擎+开源组件的架构

image.png

将 Lindorm 时序应用基于 Prometheus 架构,Prometheus 本身以 local storage 内存储,但能保存的数据本身是有限的,这时基于 Prometheus most storage 将移动TSDB 接进去,组织架构 Telearaf 将数据采集到后,写入 Kafka,通过 Flink 进行汇总写入到 Lindorm。开源的 APM Open-Falcon 可直接写入到 Lindorm 数据。作为 APM 展示层面,目前市面上所有的开源 APM 架构中都是 Grafana 作为 APM 架构的展示端。

案例:某互联网餐饮系统的业务 APM

采集端:自制采集监控脚本,涉及到若干种采集系统,采集多种多样是自建的采集端。

收集端:汇总端自制 Collector 切入到 Kafka 中,从 Kafka 数据流入到 Flink 汇总后写入到 Lindorm TSDB,通过 Lindorm TSDB 所暴露的接口整合到展示端。通过此链路稳定性达到了99%,整个系统不可用时长每年可以降低约8.76小时,MTBR 缩短了30%

image.png

·采集端

自制采集脚本

·收集端

自制Collector+Kafka+Flink

·存储端 Lindorm时序引擎

·分析&展示

自制可视化工具

案例:某直播平台运维监控 APM

采集端自制的采集工具,直播时采集指标很多包括直播时感官的卡顿、网络卡顿、错误率、加载播放时间等等一系列业务监控指标,自建一套指标采集监控数据。通过自制的汇总端写入到 Kafka,Lindorm TSDB 的方式通过定制化的 Consumer 写入。分析和展示通过 Grafana,告警接入 Bosun

image.png

.采集端

自制采集工具

.收集端

自制 Collector+Kafka+ 定制 Consumer

.存储端

Lindorm 时序引擎

.分析&展示  

Grafana

.告警  

Bosun

相较原先的 OpenTSDB 集群,写入性能↑,集群稳定性↑, 借助Lindorm TSDB本身内置的时间线索引,复杂聚合查询成为可能。

2、案例:Lindorm 时序公有云实例自监控

时序引擎在公有云上实例的云单位向外售卖,每多一个实例,多一系列的监控指标,团队需要在后台做整体的运维,每一个监控的数据都很重要。云上售卖产生的所有 Lindorm 时序引擎的监控数控通过 Telegraf 采集,用阿里 SLS 汇总,汇总后通过阿里云实时计算 Flink 版进行写入到 Lindorm 时序中,在后台通过 Grafana 进行数据监控。

image.png

.采集端  

Telegraf

.收集端

SLS+实时计算Flink版

.存储端 Lindorm时序引擎

.分析&展示  

Grafana

·告警

阿里云监控

在现在自监控体系下整体写入速率达到了50万点/秒+,随着时序引擎的写入速率升高,整体采集到的监控数据的时间序列的规模达到了1000万+,在监控系统中所设置的数据保留60天,更广泛的角度看业务监控方面需要将历史数据到达一定范围内转为数据。

.写入速率 50万点/秒+  

.时间序列规模1000万+(持续增长中)

.数据保留 60天  

3.最佳实践-监控数据建模

.数据建模的核心是时间线的设计,最关键的便是标签的设计。

.在时序数据的应用中,尽量减少时间线的数量时序数据库会对时间线进行索引,索引不是无限的膨胀,随着所有数量级别的状况,查询性能产出一定影响。核心的设计考量需要将时间线的数量进行减少。

.TSDB 会为标签建立倒排索引,因此要避免设计类似所有时间线都具备的同一个标签键值对的情况。因为当一个标签可以命中全部时间线时,这样的倒排索引本身已不再有意义。

.对于使用开源组件作为监控数据链路的上下游时,当前建议通过 OpenTSDB 协议接入,因此该类场景下的的数据模型只能是单值数据模型。如果使用的不是开源的 APM 组件可以考量更多设计。

image.png

4、最佳实践-Lindorm 时序引擎规格选择

两种实例形态

.Serverless 共享型实例

·适用于: 开发/测试环境、业务流量峰谷分明、免运维。

.实例计算资源共享、数据隔离。并发查询限制严格

·资源独享型实例

·适用于:生产环境、大规模写入型业务、时序查询密集型业务、存在自主运维需求。 .独享型实例申购时的引擎节点规格能力

两种实例形态,一种 Serverless 共享型实例另一种资源独享型实例。Serverless 适用于开发/测试环境、业务流量峰谷分明、免运维,对于大规模的写入型业务、生产环境、时序查询密集型业务推荐使用资源独享型实例。对于资源独享型实例每一个引擎节点有一系列性能的最佳实践。

image.png

5、最佳实践-Grafana 对接 Lindorm 时序引擎

LindormTSDB 可通过 Open TSDB 协议与 Grafana 实现对接 配置要点 ·OpenTSDB协议版本

·LindormTSDB实例URL

·时间戳的精度 ·(根据实例配置)用户认证信息

image.png

如何用 Grafana 作为开源 APM 的展示端,展示端如何接入到 Lindorm 时序引擎? 原生支持 Open TSDB 协议,接入时只需要在 Grafana 配置,按照与 Open TSDB 相同的配置去配置地址、时间戳精度,根据 Lindorm 时序引擎是否要开启用户认证模式配置相应的认证信息。  


二、实机演示

1.迷你监控方案演示

.开源Flink+Lindorm时序引擎+Grafana

·示例Demo任务的源码:Lindorm TSDB Sinker Demo

·阿里云托管Blink+通用LindormTSDB Connector效果更优

.开源Open-Falcon+Lindorm时序引擎+Grafana

第一个场景,用 Flink 汇总写入到 Lindorm 时序引擎,Grafana 展示数据。

第二个场景如何将 Lindorm时序引擎与开源的 Open-Falcon 融合,通过 Grafana 进行监控数据的展示。

数据通过 Flink 汇总写入到 Lindorm 时序引擎的场景,运用 Flink 的过程中通常要构建 Flink 进行写入任务,在实际接入 TSDB 时方式很简单。

做一个简单的 Demo,代码很少,采用的上游数据来自 Flink 的专业指导书介绍的样例,上游数据模拟一系列的 Sinke 生产按照当前时间持续设计一系列数据。

Public void run(SourceContext<SensorReading>srcCtx)thro

ws Exception{;

//initialize random number generator  

Random rand=new Random();

//look up index of this parallel task

Int taskIdx=this.getRuntimeContext().getIndex0fThisSubtas k();

//initislize sensor ids and temperatures;

String[] sensorIds=new String[10];  

double[]curfTemp=new double[10];

for(int i=e;i<10;i++){

sensorIds[i]<"sensor"+{taskIdx*10+i);

curFTemp[i]=65+(rand.nextGaussian()*20);

}

while {running){

//get current time

long curTime =Calendar.getInstance().getTimeInMillis();

// emit SensorReadings

for (int i=0;i<10;1++){

//update current temperature

curFTemp[i]+=rand.nextGaussian()*e.5;  

//emit reading

srcCtx.collect(new SensorReading(sensorIds[i],curTime,cur FTemp[i]));

}

//wait for 100 ms

Thread.sleep[milis:100);

}

}

/** Cancels this SourceFunction.*/  

Override

public void cancel(){

this.running = false;

}

}

在消费端做简单的实践,实现了 Lindorm 时序引擎的 Sinker 端。使用 TSDB,可以参照官方的手册有相应介绍 TSDB 的文章。用 TSDB 方法将数据持续写入。

private TSDB client;

public TsdbSink(ParameterTool parameters){ address=parameters.get("tsdbAddress"); port=Integer.parseInt(parameters.get("tsdbPort")); ioThreadCount=Integer.parseInt(parameters.getl(key:“ioThreadCount”,defaultValue:“2")); batchPutConsuerThreadCount=Integer.parseInt( parameters.get( key:"putThreadCount",defaultValue:“4")); batchSize=Integer.parseInt( parameters.get( key: "batchSize", defauitValut: “500")) ; batchBufferSize=Integer.parseInt( parameters.get(key:“batchBufferSize",defaultValue:“500")); }

Override

Public void open(Configuration parameters)throws Except ion{ super.open(parameters);

TSDBConfig config=TSDBConfig.address(address,port)

.asyncPut(true)

.ioThreadCount(ioThreadCount) .batchPutConsumerThreadCountbatchPutConsumerThreadCount) .backpressure(true) .batchPutSize(batchSize) .batchPutBufferSize(batchBufferSize) .listenBatchPut(new AbstractBatchPutCallback<Result>(){

Override

publicvoidresponse(Stringaddress,List<Point>input,Resultout

put){

logger.error( "failed!"+address+"\n"+output.to]SON());

}

})

.batchPutRetryCount(5)

.config();

client =TSDBClientFactory.connect(config);

}

Override

public void close()throws Exception{

client.close(force:true) ;

super.close()

Override

Publicvoidinvoke(SensorReadingval,Contextcontext)throwException{

try{

client.put(Point

.metric(Measqrement)

.tag(TagId, val.id)

.timestamp(val.timestamp)

.value(val.temperature)

.build()):

}catch (Exception e){

logger.error("currenttime[{}]:tsdbsinkerror,message:{}",con

text.currentProcessingTime(),e.getMessage());

}

}

效果,将 Demo 打包成架包后,通过 Flink 方式直接进行 Submit 可参照代码输入参数,可直接复制  

运行 Demo 主要是 Lindorm时序的域名并一个监听的端口。在任务的 Submit 中需要将入口进行指令,可能数据持续写入到 TSDB。

image.png

Demo 就可以按照刚才的方式接入到 Lindorm TSDB Kafka 中。

接入 Lindorm 时序引擎,通过 Grafana Data Sources 配置制定类型是末端 TSDB,将 Lindorm 时序引擎的 URI写入,Auth 可留白,文本信息需要指定是 Open TSDB 2.3 版本,Lindorm 时序引擎对标的 Open TSDB 2.3版本的协议  

指定好后可以使用 Data Sources

基于 Flink 进行数据展示如下

image.png

展示出的数据是通过 Demo 中持续生成的数据写入到 TSDB 中就可以实际展示。 Flink 写入 TSDB 的用法

2.如何使用国产开源 APM Open-Falcon接入 TSDB

Open-Falcon 并不需要特别的安装,只需要下载二进制。Open-Falcon 组件 agent 和 transfer,transfer 是作为持续数据的升级版。

配置 agent

Last login:Thu May 20 14:10:11 2021 from 47.96.60.214  

Welcome to Alibaba Cloud Elastic Compute Service! [root@iZuf6drui104r85fglid9uZ~] ls [root@iZuf6drui104r85fglid9uZ~] ls [root@iZuf6drui104r85fglid9uz~]cd open-falcon/ [root@iZuf6drui104r8Sfg1id9uZ open-falcon] ls [root@iZuf6drui104r85fglid9uZ open-falcon]cd agent/ [root@iZuf6drui104r85fg1id9uZ agent] ls [root@iZuf6drui104r85fg1id9uZ agent]cd config/ [root@iZuf6drui104r85fglid9uZ com fig] ls  

cfg.json

[root@iZuf6drui104r85fglid9uZ comfig] vim cfg.json

agent 有一个配置文件一系列配置,包括 transfer 在什么位置,核心的采集通过 transfer 做,需要配置 transfer 的地址。同时指定需要采集哪些指标,指标已经提前预制好,机器上的核心指标都进行了采集。

配置 transfer,通过文件搞定与 Lindorm 时序对接。

Last login: Thu May 20 14:10:00 2021 from118.31.243.144  

Welcome to Alibaba Cloud Elastic Compute Service! [root@iZuf6drui104r85fglid9uZ~] ls [root@iZuf6drui104r85fglid9uz~]cd open-falcon/ [root@iZuf6drui104r8Sfg1id9uZ open-falcon] ls [root@iZuf6drui104r85fglid9uZ open-falcon]cd transfer/ [root@iZuf6drui104r85fg1id9uZ tramsfer] ls [root@iZuf6drui104r85fg1id9uZ tramsfer]cd config/ [root@iZuf6drui104r85fglid9uZ com fig] ls  

cfg.json

[root@iZuf6drui104r85fglid9uZ comfig] cd cfg.json

bash: cd: cfg.jsonz :Not a directory

[root@iZuf6drui104r85fglid9uZ comfig] vim cfg.json  

核心的配置取决于最后配置段,transfer 所对接的 JSB 策划案信息。其它的指标可以根据数据规模总计,最核心的配置项是组件的 rice,rice 需要配置到 Lindorm 时序云上,Lindorm 时序云所公开的域名端口写入,可启动相关的 transfer,将各个 agent 采集的数据持续进入。transfer 启用完毕回到 Grafana 中。

Grafana 下面三个  

image.png

刚才通过 agent 采集的数据,采集的一系列数据包括 CPU 监控指标内存的监控指标。 结合 Grafana 接口进行配置,整个监控指标展示在 Grafana

相关文章
|
4月前
|
运维 Prometheus 监控
构建高效自动化运维系统的关键策略
【2月更文挑战第30天】随着云计算和微服务架构的兴起,现代IT运维环境变得愈加复杂多变。为保持业务连续性、提高响应速度并降低成本,企业亟需构建一个高效的自动化运维系统。本文将深入探讨自动化运维系统构建过程中的关键策略,包括工具和技术选型、流程优化、监控与告警体系搭建以及持续集成/持续部署(CI/CD)实践,旨在为读者提供一个清晰的构建蓝图和实用的实施建议。
|
3月前
|
运维 监控 数据库
构建高效后端:从代码优化到系统监控的全方位策略
【6月更文挑战第12天】本文深入探讨了如何打造一个高效、稳定的后端系统。我们将从代码层面的最佳实践出发,逐步扩展到系统架构设计,再到性能监控和故障排查,提供一系列实用的技巧和工具,帮助开发者提升后端服务的性能和可靠性。
|
24天前
|
Prometheus 监控 Cloud Native
【揭秘可观测性】构建完美参考框架,打造系统监控的瑞士军刀!
【8月更文挑战第25天】在现代软件设计中,可观测性是确保系统稳定性和效率的关键因素。它主要由日志、指标及链路追踪(统称LMx)三大核心组件构成。本文详细介绍了构建高效可观测性框架的六个步骤:需求分析、工具选择、数据收集策略设计、实施集成、数据可视化及持续优化。并通过一个Spring Boot应用集成Prometheus和Micrometer收集指标的示例,展示了具体实践方法。合理构建可观测性框架能显著提升团队对软件系统的管理和监控能力,进而增强系统整体性能和可靠性。
38 2
|
1月前
|
存储 运维 监控
监控与日志管理:保障系统稳定运行与高效运维的基石
【8月更文挑战第16天】监控与日志管理是保障系统稳定运行和高效运维的基石。它们不仅能够帮助企业及时发现并解决问题,还能够为性能调优、资源优化和业务决策提供有力支持。因此,在构建系统架构时,企业应高度重视监控与日志管理的规划和实施,确保它们能够充分发挥作用,为企业的发展保驾护航。同时,随着技术的不断进步和应用场景的不断拓展,监控与日志管理也将持续演进和创新,为企业带来更多的价值和便利。
|
4月前
|
运维 Prometheus 监控
构建高效可靠的自动化运维系统
【5月更文挑战第30天】 在信息技术迅猛发展的今天,企业对IT基础设施的依赖性日益增强。为了确保系统的高可用性和最佳性能,越来越多的组织开始转向自动化运维。本文旨在探讨构建一个高效、可靠的自动化运维系统的关键技术和实践策略,通过案例分析和技术比较,提出一种综合解决方案,以期帮助企业实现运维效率的最大化和风险的最小化。
|
4月前
|
运维 监控 安全
构建高效自动化运维系统:策略与实践
【5月更文挑战第27天】随着信息技术的飞速发展,企业对于运维效率和稳定性的要求日益提高。本文深入探讨了构建一个高效自动化运维系统的关键技术和实施策略,旨在为运维团队提供一种提升工作效率、降低人为错误和管理复杂性的可行途径。文中不仅分析了自动化运维的必要性,还详细介绍了实现过程中的工具选择、流程设计以及最佳实践,并通过案例分析展示自动化运维在现实环境中的应用效果。
|
4月前
|
存储 监控 Kubernetes
构建高效稳定的云原生日志监控系统
【5月更文挑战第26天】 随着微服务架构和容器化技术的普及,传统的日志监控方法面临重大挑战。本文将探讨如何构建一个既高效又稳定的云原生日志监控系统,该系统旨在提供实时的日志分析能力,同时保证系统的高可用性和可扩展性。我们将讨论利用现代技术栈如Fluentd、Elasticsearch和Kibana(EFK栈)来搭建日志收集、存储和可视化的解决方案,并深入探讨如何通过容器编排工具如Kubernetes来实现日志服务的自动伸缩和故障恢复。此外,我们还将介绍一些最佳实践,帮助运维团队在保持系统性能的同时,降低资源消耗和运营成本。
|
4月前
|
运维 监控
构建高效自动化运维体系的关键步骤
【5月更文挑战第24天】 随着信息技术的不断进步,企业对于IT运维的要求越来越高。传统的手工运维方式已经不能满足快速变化的业务需求,而自动化运维逐渐成为提升效率、保障系统稳定性的重要手段。本文将探讨构建一个高效自动化运维体系所需的关键步骤,包括自动化策略制定、工具选择、流程设计、监控与优化等方面,旨在为读者提供一条清晰的自动化运维实施路径。
|
4月前
|
机器学习/深度学习 人工智能 运维
构建高效自动化运维系统的五大关键步骤
【5月更文挑战第18天】在数字化转型的浪潮中,高效的自动化运维系统成为企业保障IT服务管理效率和稳定性的核心。本文将探讨构建自动化运维系统的五个关键步骤,包括需求分析、设计蓝图、选择合适的工具、实施与集成以及持续优化。通过这些步骤的实施,企业能够实现故障快速响应、资源优化配置和成本有效控制,从而提升整体的IT服务质量和用户满意度。
|
4月前
|
运维 Prometheus 监控
构建高效自动化运维系统的策略与实践
【5月更文挑战第29天】 在当今快速迭代的技术环境下,自动化运维已经成为确保服务可靠性和效率的关键。本文将深入探讨构建一个高效自动化运维系统的必备策略及其具体实践步骤。通过分析当前自动化工具的选择、配置管理的最佳实践以及持续集成和持续部署(CI/CD)流程的整合,我们旨在为读者提供一个清晰可行的蓝图,以实现运维工作的优化。