可观测性平台下的低代码技术实践
凌云时刻
本文为阿里云SLS丁来强（花名成喆）在PyCon2021上海站分享时的议题内容，结尾有录播的视频和PPT下载链接。
背景与趋势
本节介绍可观测性平台与低代码技术的相应背景和相关发展趋势。
![]()
数字化对工程师的挑战
随着云计算与云原生技术的大量应用，研发运维类工程师总体上花费在部署环境上的时间相对其他工作有所减少。而数字化时代的趋势下，为了更好地减少业务损失或发展业务，工程师需要对系统进行观测分析的时间也逐步增加。
从软件研发的生命周期看，有大量的工作需要做，不同人员参与的协同会大大降低响应速度，越来越多的公司要求一专多能。开发、测试、运维融合逐步成为趋势，开发人员逐步开始承担测试的工作、部分运维甚至运营的工作。
![]()
趋势1：工作模式的统一
Ops（运营）工作中很重要一环就是观测与分析，不同角色关注不同的观测源，进行相应的处理动作，例如开发运营维护（DevOps）关注稳定性、安全运营（SecOps）关注风险控制、商务运营（BizOps）关注业务健康增长等，但是他们的工作模式基本一致，可以统一为两个阶段：对观测源进行数据处理（数据采集、数据存储、分析加工）到分析判断（信息展示与响应动作）。
![]()
趋势2：数据存储的统一
不同运营角色的数据源都需要采集与存储，而他们有很大程度上的重叠，例如安全运营与商务运营人员关注的用户操作与行为日志，同样也是开发运营维护人员所需要关注的。这就好比智能汽车的发展一样，从一开始孤立的各个数据监测系统（行车记录仪、车载录音、胎压监测、倒车雷达、ETC等）到现在逐步趋于统一化：统一采集、存储与分析的总线系统实现了接口统一、数据互通互联。
![]()
趋势3：算力带来实时洞察
传统监控一般以一个白盒方式监控系统，专注发现核心指标异常，例如500错误，客户订单成功率等。一般这种问题发生时，准取性极高（例如大量500错误，大量订单失败，一定表示SLA有问题），一般也都比较严重。因为是黑盒，进一步排错和修复时间和成本极大，往往给开发运维人员带来极大压力。
根据海恩法则(Heinrich's Law)，每一起严重事故背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。如果提前处理那些不那么严重的问题、先兆或者隐患，其实是可以避免后续严重事故的，也就避免了其带来的巨大压力和损失。
可观测性是对传统监控的升级，其要求进行白盒化监控，对各种可能的隐患、先兆、不严重问题进行监测、跟踪处理。且不再只是在发布后，而是在开发、测试阶段就进行。
因此对比两者，可以发现，传统监控主要由SRE人员从系统外部进行监控，关注指标，发现问题（Know What）；而可观测性由DevOps人员从系统内部进行监控，关注指标、日志和跟踪等数据各种数据，发现问题并挖掘原因（Know Why）。
可观测性需要采集更多的数据，对数据进行更多的预处理，而现在算力的增强（更丰富的机器资源，加上更好的大规模数据处理能力），让实时观测落地变得更容易与流行。
![]()
趋势4：业务与技术越成熟越驱动低(无)代码技术/平台落地
在疫情时代大量轻应用需求带动下，低代码（Low Code）或无代码（No Code）技术以及其衍生出的低代码应用平台（LCAP：Low Code Applicaiton Platform）开始流行。其核心理念就是使用低代码甚至无代码就可以完成某项之前需要代码才能完成的工作，除了常规应用软件开发，也可应用于数据分析、流程管理、工业领域等复杂业务系统的建设。
从实际落地角度看，低（无）代码技术的应用与技术成熟度、业务模式成熟度有很大关系，例如云计算简化了软件架构、前端组件化让多端开发更容易，从而催生了许多通用轻应用领域的低（无）代码应用。而某些特定行业的应用或典型数据流程审批系统的业务模式也越来越成熟，使得低（无）代码也有了相应的用武之地。新一代可观测平台，因为在技术挑战和业务模式上还在逐步完善中，使用LCAP协同开发还无成熟落地，但低（无）代码技术已经开始被应用辅助提升用户体验。
![]()
典型的可观测平台解决方案
基于前述一些趋势，我们可以看到一个典型的可观测平台应该具备这样的特性：
对包括日志、时序、链路、跟踪和事件的统一存储、处理、分析、展示以及相应的基础中台能力。
支撑上层业务方（开发运营、监控、安全、用户运营）的观测分析需求（与定制能力）。
同时可以对接上下游系统的生态支持。
![]()
开发运维智能化、无代码化发展趋势
可观测平台也是智能运维平台（AIOps）的载体，可以看到在算力算法和低（无）代码技术下逐步提升效率，让机器代替部分人力，将智能自动化水平逐步提高。
以下是各个层次的智能化、低（无）代码化发展水平：
各环节的场景与挑战
下面我们从可观测平台支持的各个环节介绍低（无）代码技术的应用场景与相应挑战。
![]()
可观测平台下配置部署时的低（无）代码层次
运营模式下的各个环节使用低（无）代码技术可以分成三个层次：纯代码、低代码到无代码。
纯代码层次下，各个环节都存一定的编码任务，例如采集时需要在代码中写入数据以便被采集，或集成方需要编写程序来拉取特定数据；存储下需要部署加工程序或在流计算框架下编写代码完成存储预处理工作；分析阶段需要调用不同接口分析并关联协同；展示阶段需要在可视化系统中编写提取数据并展示价值信息；动作阶段需要集成代码与三方系统交互，完成特定流程逻辑。
低代码层次下，做到了组件化封装大部分编码工作，避免代码编写或通过DSL方式简化编码工作。
无代码层次下，大大简化或自动化了编码工作，通过内置组件、图形化操控、智能提示等完成各环节工作。
![]()
数据采集的低(无)代码场景
数据采集需要解决各类数据源的数据摄入，这一阶段的低（无）代码采集的主要场景如图，可简单分为：
以低(无)代码方式接入任意源的任意类型数据。
不修改程序以无/低代码接入程序中相关数据。
无代码采集技术成熟度的问题，例如Java代码侵入、JMX采集、JS在终端浏览器注入（RUM）以及eBPF技术等，如何包装适配性，以及在实时密集采集时，控制对目标系统的稳定性与性能影响，以便在核心生产环境中大规模部署。
非结构化日志的格式解析，目前典型使用正则等方式，如何保持灵活性又减低门槛。
如何降低编排复杂度，让采集变得更加智能，例如云资产如何自动发现与适配对应云产品日志等。
![]()
数据存储加工的低(无)代码场景
数据在入库存储前需要进行规整加工，典型场景如图，支持以低（无）代码方式对无结构、半结构化数据进行各种形式的分派、加工、归并与富化等。
如何灵活适配以上各种场景，又具备一定扩展性？
架构方面又如何实现自动化扩容与缩容？
![]()
数据分析的低(无)代码场景
如背景中介绍的各种运营模式下，分析阶段的场景主要是对数据进行各类分析计算（或动态加工），对包括时序、日志、Trace、事件等数据进行查询、聚集、转换、关联、智能算法等低（无）代码的计算命令。
不同存储的查询分析语法各不相同，如何降低使用门槛？以开源为例，有ES（Lucence、DSL）、 Prometheus （PromQL）、OpenTelemetry（API）、Presto（SQL）、ClickHouse（类SQL）等。
多种系统的数据之间如何实现低（无）代码的关联协同？
![]()
数据展示的低(无)代码场景
数据展示阶段的低（无）代码场景比较直观，不需要写代码就可以构建包括各类图表的可视化大盘，包括各类图表；也包括写很少代码就可以定制支持其他交互分析场景的可视化模块。
该阶段目前有很多成熟的方案已经可以做到，但依然存在一些挑战，包括：
数据与可视化之间如何进一步简化关联？
多端可视化如何自动化适配？（目前LCAP在软件开发阶段已经较好的解决了Form场景，但数据图表展示场景依然有一定配置复杂度）。
仪表盘外的可视化定制如何支持低（无）代码扩展？
![]()
操作响应的低(无)代码场景
操作响应阶段的场景可以理解为从数据中挖掘更重要的信息进行相应的动作，典型的可观测平台下是告警事件的监测、管理以及行动（如图）。
开发运维（DevOps）时强调通知的触达与管理，包括了分派、故障升级、值班敏感、各类通知渠道调度、通知内容编排等，
智能运维（AIOos）时强调告警处理，包括了上下文富化、关联、人工标注、根因分析、以及止血自动化等。
安全运营（SecOps）时强调安全编排（SOAR）的支持，包括与威胁情报联动、故障流程处理、二次审批与风控介入自动化等。
主要的挑战是：
如何以低（无）代码方式满足上诉场景，并支持灵活扩展？
如何在可观测平台下以统一模式方式支持各类场景？
最佳实践与Python技术的应用
采集阶段的低代码实践比较多与生态建设以及各类具体技术相关，这里针对除采集阶段外的各个阶段的低（无）代码技术实践进行简单介绍与探讨。
![]()
数据存储加工的低(无)代码实践
这里介绍一种PaaS形态的数据加工的实践方式，架构层面如下：
采用队列如Kafka、阿里云LogHub、AWS Kinesis等对数据进行流式读取消费。
调度系统基于K8S构建，对数据流量与计算消耗，动态缩容扩容。
而低（无）代码的方式以Python子集语法方式提供用户侧的输入与实际逻辑的映射。
提供了200+封装算子，与Flink、Python原生、ESLogstash的Ruby方案对比，代码更少。低于20行代码即可满足大部分用户的加工需求。
以子集方式提供保证了低门槛与灵活性，也进一步保护了计算环境，同时也支持通过代码优化裁剪、部分重写等方式进行进一步性能优化可能。
如下是一个对数据进行字段设置、丢弃、判断处理场景的样例：
![]()
数据分析的低(无)代码实践
针对对应环节描述的挑战，该阶段的实践方案采用如下架构：
一套存储，多种索引方式，支撑随机查询（日志）、列存（日志分析）、行存（时序分析）等场景。
以一套统一语法方式，SQL为中心覆盖所有分析能力（Query、PromQL均作为SQL一部分）
统一使用SQL = Search + PromQL + SQL92作为平台核心接口。
提供Query Builder可视化功能，进一步降低分析语法构建的门槛。
例如以下查询分析语句展示了，如何使用一套SQL完成对日志、时序、机器学习算法等一起使用并协同的方式：
![]()
数据展示的低(无)代码实践
数据展示针对前述挑战，低（无）代码的主要实践是：
依托统一查询分析接口语法映射数据，这就解决了数据协同的问题。
提供开箱机用的各种图表（如图），在画布基础上支持所见即所得（这种方式目前在行业方案中也比较普遍）。
![]()
操作响应的低(无)代码实践
在低（无）代码场景（例如告警监控、管理逻辑）落地时，提供可视化界面（GUI）交互配置编排，其并自动映射为Python子集。
关联参考：
• 什么是可观测性：https://www.sumologic.com/glossary/observability