技术类场景使用演示
为了减少不必要的篇幅，本文缩减了一些具体细节描述，在阅读本文前建议您首先阅读： ICON图标点击数据统计 以及 移动支付订单数据统计，以便于您对XL-LightHouse的使用有初步了解。
XL-LightHouse的运算依赖业务方接入主动上报的原始统计消息，XL-LightHouse自身的功能不涉及相关埋点数据采集环节。
1. 序言
前面几篇文章阐述了XL-LightHouse在业务类指标、运营类指标、产品类指标等场景的使用，而在技术服务领域XL-LightHouse同样有较为广泛的应用场景。本文选择几个常见的例子阐述一下其在技术类场景的使用。
2. 前端耗时类问题监控
对一个互联网产品来说前端操作流畅度是影响用户体验的重要因素。目前各类互联网产品功能模块日益增多，交互形式也更加多样化，这给前端程序的性能和稳定性提出了更高的要求。为了便于前端工程师实时掌握程序运行状态，辅助后续的优化迭代，重要前端模块往往需要添加耗时监控。下面我们以app启动时动画广告加载耗时监控为例来介绍一下这类场景中XL-LightHouse的使用。 首先我们假设动画广告加载流程主要包括三个耗时较长的环节：（1）、请求后端接口，获取广告配置信息（2）、动画广告数据下载耗时（3）、组件加载，页面渲染耗时。
2.1. 统计需求梳理
平均耗时：
1、每分钟_平均耗时
2、每分钟_第一环节_平均耗时
3、每分钟_第二环节_平均耗时
4、每分钟_第三环节_平均耗时
5、每分钟_各APP版本_平均耗时
6、每分钟_各手机系统_平均耗时
7、每分钟_各网络环境_平均耗时
各耗时区间次数：
1、每分钟_各耗时区间_次数
2.2. 元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| imei | string | 用户标识 | |
| step1_cost | numeric | 第一环节耗时_毫秒 | |
| step2_cost | numeric | 第二环节耗时_毫秒 | |
| step3_cost | numeric | 第三环节耗时_毫秒 | |
| total_cost | numeric | 总耗时_毫秒 | |
| version | string | App版本 | |
| os | string | 用户手机系统 | android、ios |
| net | string | 用户网络环境 | WIFI、2G、3G、4G、5G |
3. 前端异常类问题监控
前端程序的运行环境相对于后端来说更为复杂，不管是Android、IOS还是JS同样一段程序可能会因为用户手机型号、硬件配置、系统版本、APP版本、网络环境等各种因素影响到它的正常执行，这会给企业带来一定的损失。为了便于快速定位问题就有必要在较为重要的业务逻辑处增加异常监控。下面我们以一个全屏广告是否正常加载的例子阐述一下在这类场景下XL-LightHouse的使用。
我这里将全屏广告加载状态按照是否正常加载以及异常原因分成如下几种： 0:正常加载，1：查询广告配置接口请求异常，2：接口数据解析异常，3：广告图片加载异常，4：广告组件页面渲染异常
3.1. 统计需求梳理
各异常次数统计：
1、每分钟_各状态_次数统计
2、每天_各状态_次数统计
3、每天_各APP版本_各状态_次数统计
4、每天_各网络环境_各状态_次数统计
5、每天_各手机系统_各状态_次数统计
6、每天_各手机型号_各状态_次数统计
影响用户数统计：
1、每分钟_各状态_影响用户数
2、每天_各状态_影响用户数
3、每天_各APP版本_各状态_影响用户数
4、每天_各网络环境_各状态_影响用户数
5、每天_各手机系统_各状态_影响用户数
6、每天_各手机型号_各状态_影响用户数
3.2. 元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| imei | string | 用户标识 | |
| code | string | 加载状态 | |
| version | string | App版本 | |
| model | string | 用户手机型号 | |
| os | string | 用户手机系统 | android、ios |
| net | string | 用户网络环境 | WIFI、2G、3G、4G、5G |
4. 基础服务监控
有一定规模的互联网企业都比较重视基础服务建设，这些基础服务种类繁多，比如RPC服务、关系型数据库服务、KV存储服务、索引服务、消息中间件、任务调度平台、AI算法平台、数仓服务、用户画像服务、图片存储服务、埋点系统、ABTest系统、运维类系统等等，不管任何一种基础服务都需要完善的数据指标来辅助其运行。下面我以一个KV存储服务为例来阐述一下XL-LightHouse在这类场景中的使用。 有些企业的KV存储是基于开源项目搭建的(比如redis,memcache，LevelDB, RocksDB等等)也有些企业是自研的，这种KV存储服务可以对公司内部各个业务方开放共用，每个业务方可以在KV平台上创建一个或多个实例，每个实例可以理解为是一个相对独立由多个节点组成的集群。
4.1. KV存储服务 -- 接口请求数据监控
KV存储服务会对外提供很多操作命令，比如get、set、batchGet、batchSet、delete、scan等等。相对应的数据指标主要有：命令执行次数、响应时间、请求数据量、返回数据量等等。
假如我们有如下数据需求：
统计项需求梳理
命令执行次数：
1、每分钟_各实例_命令执行次数
2、每分钟_各实例_各节点_命令执行次数
3、每分钟_各实例_各命令_执行次数
4、每天_各实例_命令执行次数
5、每天_各实例_各节点_命令执行次数
6、每天_各实例_各命令_命令执行次数
平均响应时间：
1、每分钟_各实例_平均相应时间
2、每分钟_各实例_各节点_平均相应时间
3、每分钟_各实例_各命令_平均相应时间
4、每天_各实例_平均相应时间
5、每天_各实例_各节点_平均相应时间
6、每天_各实例_各命令类型_平均相应时间
接口接收数据量：
1、每分钟_各实例_接收数据量
2、每分钟_各实例_各节点_接收数据量
3、每分钟_各实例_各命令类型_接收数据量
4、每天_各实例_接收数据量
5、每天_各实例_各节点_接收数据量
6、每天_各实例_各命令类型_接收数据量
接口返回数据量：
1、每分钟_各实例_返回数据量
2、每分钟_各实例_各节点_返回数据量
3、每分钟_各实例_各命令类型_返回数据量
4、每天_各实例_返回数据量
5、每天_各实例_各节点_返回数据量
6、每天_各实例_各命令类型_返回数据量
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| clusterId | string | 实例ID | |
| nodeId | string | 节点ID | |
| command | string | 操作命令 | set、get、mset、mget ... |
| in_bytes | numeric | 接收字节数 | |
| out_bytes | numeric | 返回字节数 | |
| cost | numeric | 耗时 |
备注：上面的元数据我是基于"操作命令"的维度来设计的，一个命令有可能会对应多个key，有时我们需要基于key的维度统计执行耗时、传输数据量、QPS等数据就需要设计key维度的元数据结构。 举例： 假设一个场景，一个电商业务场景在KV存储中存储了用户点击商品的记录数据和用户购买商品的数据。userClickItems#UserId和userBuyItems#UserId。 如果要分别统计两类存储数据的请求数据量、返回数据量、接口耗时、QPS等数据。KV存储平台可以约定key前缀的指定分隔符，使用XL-LightHouse内置的分割函数统计相应数据。
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| clusterId | string | 实例ID | |
| nodeId | string | 节点ID | |
| keyPrefix | string | key前缀 | userClickItems、userBuyItems... |
| in_bytes | numeric | 接收字节数 | |
| out_bytes | numeric | 返回字节数 | |
| cost | numeric | 耗时 |
4.2. KV存储服务状态监控
XL-LightHouse支持时序性数据的存储和查询，在KV存储这个场景中一般服务状态可以有如下几种：当前连接数、碎片率、节点负载、内存使用率、缓存命中率等等。
统计需求梳理
节点状态监控：
1、每分钟_各节点_当前连接数
2、每分钟_各节点_碎片率
3、每分钟_各节点_节点负载
4、每分钟_各节点_内存使用率
5、每分钟_各节点_命中率
元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| clusterId | string | 实例ID | |
| nodeId | string | 节点ID | |
| hit_rate | numeric | 命中率 | |
| connections | numeric | 连接数 | |
| mem_rate | numeric | 内存使用率 | |
| fragmentation | numeric | 碎片率 | |
| load | numeric | 节点负载 |
5. 前端埋点数据量监控
移动互联网时代企业通过前端埋点来收集用户行为相关数据，获得这些行为数据之后企业可以进行个性化推荐或者一些数据指标的统计分析。埋点对于互联网企业来说非常重要。但是随着APP的更新迭代和各类埋点的日益增多，再加上埋点的上报和接收流程相对复杂，这都给埋点的管理和维护带来了很大的困难。经常会出现一些异常情况，比如：某个埋点的数据量大幅度波动、已经过时业务不再需要的埋点还在继续上报、不同app版本、手机型号上报的埋点数据量有差大差异、埋点存在重复上报、少报、参数空值等问题。在这种背景下是非常有必要对埋点数据进行必要的监控，以便于快速发现问题和辅助排查问题。 针对于上面罗列的一些异常情况，或许不能通过一个统计组来全部实现。XL-LightHouse需要企业根据自己实际情况灵活的使用。
不同企业的埋点规范各有差异，一般来说一个埋点消息可包括几个主要组成部分：所属页面、所属功能模块、埋点标识、埋点公共参数（可包括用户设备标识、用户id、地区、时间戳等参数）、埋点私有参数等。
5.1. 统计需求梳理
数据量统计：
1、每分钟_各埋点_数据量统计
2、每分钟_各APP版本_各埋点_数据量统计
3、每小时_各APP版本_各埋点_数据量统计
4、每天_各APP版本_各埋点_数据量统计
5.2. 元数据结构
| 字段 | 字段类型 | 描述 | |
|---|---|---|---|
| imei | string | 用户标识 | |
| trackId | string | 埋点标识 | |
| province | string | 省份 | |
| city | string | 城市 | |
| county | string | 县 | |
| version | string | App版本 | |
| model | string | 用户手机型号 | |
| os | string | 用户手机系统 | android、ios |
| net | string | 用户网络环境 | WIFI、2G、3G、4G、5G |
有时针对于一些比较重要的埋点，我们需要对其私有参数的空值、格式错误、参数错误等异常情况进行监控，可以通过创建单独的统计组来实现。
而对于埋点重复上报、少报等问题，很多时候并不能通过单一的数据指标确定问题。一般来说可以通过相关联的数据指标、上下游数据指标的对比分析来定位问题。比如在从一个列表点击进入到详情页的业务场景中，如果怀疑点击埋点上报异常，可以通过详情页的曝光埋点来判断。如果我们怀疑详情页的曝光埋点上报有问题，可以通过详情页后端接口的调用次数等相关指标进行交叉判断。
6. 服务中间态数据监控
对于一些较复杂的系统，程序中的数据流转往往会经过一系列的环节，而对于程序中间状态的监控是非常有必要的，它可以帮助我们实时的、较为准确的衡量服务的运行状况。下面以一个常见Feed推荐召回的例子来阐述一下使用XL-LightHouse应对这类问题。 推荐系统本质是一个信息过滤系统，通常包括：召回、排序、重排序三个环节，每个环节逐层过滤，最终从海量的物料库中筛选出用户最感兴趣的物品。 召回环节一般可以包括多种召回策略，比如：热数据召回、画像召回、协同过滤召回、点击相似的帖子召回等等。 排序环节也可以有一种或多种排序模型，排序模型一般是根据物料本身的特征、用户的特征以及其他的外部特征进行综合打分排序。 重排序模型一般是在排序模型之后，再依据一些自定义规则进行重拍，比如可以考虑用户的历史点击情况、召回结果的多样性、帖子过期情况等等因素。
6.1. 统计需求梳理
召回环节数据统计：
1、每5分钟_各召回号_总召回帖子数量
2、每5分钟_各召回号_返回结果为空请求占比
3、每5分钟_各召回号_覆盖用户数占比
4、每5分钟_各召回号_各帖子分类_帖子数量
5、每5分钟_各召回号_新发布帖子召回数量
6、每5分钟_各召回号_违规类帖子召回数量
7、每5分钟_各召回号_各城市_召回数量
8、每天_各召回号_召回帖子数量
9、每天_各召回号_返回结果为空请求占比
10、每天_各召回号_覆盖用户数占比
11、每天_各召回号_各帖子分类_帖子数量
12、每天_各召回号_新发布帖子召回数量
13、每天_各召回号_违规类帖子召回数量
14、每天_各召回号_各城市_召回数量
排序模型数据统计：
1、每5分钟_各混排模型_输入帖子数量
2、每5分钟_各混排模型_各帖子分类_输入帖子数量
3、每5分钟_各混排模型_各帖子分类_输出帖子数量
4、每5分钟_各混排模型_各帖子发布时间段_输入帖子数量
5、每5分钟_各混排模型_各帖子发布时间段_输出帖子数量
6、每5分钟_各混排模型_使用用户年龄/性别特征覆盖率
7、每5分钟_各混排模型_使用用户业务画像特征覆盖率
8、每天_各混排模型_输入帖子数量
9、每天_各混排模型_各帖子分类_输入帖子数量
10、每天_各混排模型_各帖子分类_输出帖子数量
11、每天_各混排模型_各帖子发布时间段_输入帖子数量
12、每天_各混排模型_各帖子发布时间段_输出帖子数量
13、每天_各混排模型_使用用户年龄/性别特征覆盖率
14、每天_各混排模型_使用用户业务画像特征覆盖率
重排序模型数据统计：
1、每5分钟_各重排模型_输入数据平均一级分类个数(假设用这个指标来衡量结果的多样性)
2、每5分钟_各重排模型_输入数据平均二级分类个数
3、每5分钟_各重排模型_输出数据平均一级分类个数
4、每5分钟_各重排模型_输出数据平均二级分类个数
5、每5分钟_各重排模型_用户已点击的帖子召回数量
6、每5分钟_各重排模型_用户已曝光的帖子召回数量
7. 辅助分布式问题排查
当前软件开发提倡微服务形式的架构设计，微服务对大中型软件项目来说有很大好处，它降低了系统间的耦合度，各服务职责专一，便于敏捷开发，可以合理规划集群资源。但微服务也同样会带来一些问题，除了会增加一定的服务间性能损耗外，微服务也加剧了整个系统的复杂程度。很多互联网产品响应用户一次请求会涉及三四个微服务之间的相互调用是很正常的，甚至涉及十几个微服务之间的相互调用也并不罕见，这种情况对于一些数据波动、超时异常类问题，灵活的使用XL-LightHouse，在重要的业务环节、容易出问题的环节尤其是涉及到跨部门协助的环节加上流式数据监控，对于衡量服务运行状况以及后续排查定位问题都有很大好处。
8. 辅助运维监控、性能监控、压测、ABTest等功能
我认为通用型流式大数据统计服务将成为企业最核心的基础服务之一，而诸如运维监控告警、应用性能监控、压测、ABTest以及形式各样的时序型数据处理类服务其中所有涉及数据指标的功能将不再需要单独开发。
9. 可作为指标管理平台
XL-LightHouse除了流式统计相关的指标之外，也可以将其他任务统计结果数据存储到XL-LightHouse，使其作为一个指标管理平台。元数据的设计类似于数据库中的表结构设计，使用seq函数将数据存储到XL-LightHouse。
10. 结束语
XL-LightHouse希望能够帮助各种工种的程序员尽可能从琐碎、反复的数据统计的事情中抽身出来，而专注于对个人成长、对企业发展更有价值的事情。我相信巧妙的设计元数据结构、灵活的使用XL-LightHouse可以为您解决很多棘手的问题，希望XL-LightHouse能够成为您职业生涯常伴左右的工具。