埋点数据模型

埋点的目标是RED(Request,Error,Duration)

初期

当上线初期整体数据量不大的时候，我们可以统统以事件（event）来埋点。

例如埋点数据模型如下：

measurement: laker_order #metrics name
fileds:value: 398 # 泛化的value，可以是duration unit: ms，也可以是 filesize unit:byte，订单金额等。count: 1 # default 1.browser_version: 107.0.0.0 # autofill 浏览器版本os_version: # autofill 操作系统版本userid:  # autofill 用户idtracking_id: # TrackingIDbiz_id: # 业务id, 订单id/账单id/消息id等  description: # description
tag:error_type: DECRYPTION_FAILED # DECRYPTION_FAILED/DECRYPTION_UNAUTHORIZED/DECRYPTION_GET_KEY_FAILED  status: 1 #用这个来代替 success感觉更好呢 0成功 1失败 2：xx 3：xx（但是要控制好 别扩散）-- success: true # true/false 成功失败org_id: # autofill 组织idos: Win #autofill 操作系统browser: chrome # autofill 浏览器az: # autofill 可用区 A/B/C region: # autofill 地域 上海/杭州

注意：tag中的值一定是可枚举的，且其基数不能太大，基数计算如下：

例如：

error_type：值有3

success：2

org_id: 20

os：3

browser：6

az：1

region：1

则基数为：3*2*20*3*6*1*1=2160

基数一般建议小于1w，当然这取决于你服务器的配置有多高。

这里注意下，内存基数和influxdb端基数是不一样的。例如，还是上面的计算方式。

error_type：内存：3 ，全局：3
success：内存：2 ，全局：2
org_id: 内存：20 ，全局：20
os：内存：20 ，全局：20
browser：内存：6，全局：6
az：内存：1，全局：6（因为一个实例，在内存上只有一个az，但是整体是有6个的）
region：内存：1，全局：2

则实例内存基数为：3*2*20*3*6*1*1=2160

小心应用实例内存溢出。

则influxDB基数为：3*2*20*3*6*6*2=25920

小心influxdb内存溢出。

优化

当系统用户数据量上来后，我们需要优化了，因为上面每个event，都是一条数据，会导致数据量太大了，我们需要用聚合指标来收集数据。以http request举例子。

例如有 10000个事件

uri: /api/v1/users/{id} status : 200 ,有3000条
uri: /api/v1/users/{id} status : 500,有3000条
uri: /api/v1/orgs/{id} status : 200 ,有3000条
uri: /api/v1/orgs/{id} status : 500,有1000条

事件指标数：10000条。

聚合指标数：2 * 2 = 4条。

优点：

把指标数量从事件数量级别下降到tag value的基数级别。

缺点：

相关字段变少。

可以配合异常事件或者日志处理。可观测性-Event-指标事件采样策略总结（基于条件的采样）
基数爆炸会导致服务内存压力。

埋点模型如下：

measurement: laker_order
# metric_type: timer/counter
fileds:mean: 100    # 步长内事件值平均值，平均响应时间count: 1000  # 步长内事件数sum: 10000   # 步长内事件值总和，响应时间的总和upper: 250   # 步长内事件最大值，最大响应时间
tag:error_type: DECRYPTION_FAILED # DECRYPTION_FAILED/DECRYPTION_UNAUTHORIZED/DECRYPTION_GET_KEY_FAILED  success: true # true/falseorg_id: # autofillos: Win #autofillbrowser: chrome # autofillaz: # autofill 可用区 A/B/Cregion: # autofill 地域 上海/杭州

可以看到没有指标细节了，细节可以用事件指标+log解决。

可观测性-Event-埋点数据模型相关推荐

手动埋点转无痕埋点，如何做到代码“零”入侵
前言在起初的手动埋点的时候,每次版本大更新,很多埋点都要进行修改,删除.这个时候之前嵌在源码里面的一行行埋点代码要进行修改,删除.删了又找,找了又改,很麻烦.如果遇到有代码洁癖的,"产品你 ...
携程的 Dubbo 之路
作者 | 董艺荃注:本篇文章整理自董艺荃在 Dubbo 社区开发者日上海站的演讲. 缘起携程当初为什么要引入 Dubbo 呢?实际上从 2013 年底起,携程内主要使用的就是基于 HTTP 协议的 ...
看大众点评如何通过实时监控系统CAT打造7*24服务
为什么80%的码农都做不了架构师?>>> 看大众点评如何通过实时监控系统CAT打造7*24服务 2015-06-08 尤勇高可用架构 https://github.com ...
一文读懂Data Lake的概念、特征、架构与案例
本文包括七个小节: 1.什么是数据湖: 2.数据湖的基本特征: 3.数据湖基本架构: 4.各厂商的数据湖解决方案: 5.典型的数据湖应用场景: 6.数据湖建设的基本过程: 7.总结.受限于个人水平,谬 ...
CAT 性能优化的实践和思考
作者简介锦华,携程高级技术专家,超过 10 年互联网研发经验,2011 年至今一直从事框架和中间件相关产品研发,对高并发.分布式中间件以及应用性能优化等有浓厚兴趣. *本文来自锦华在Qcon的分享, ...
“数据湖”：概念、特征、架构与案例
写在前面: 最近,数据湖的概念非常热,许多前线的同学都在讨论数据湖应该怎么建?阿里云有没有成熟的数据湖解决方案?阿里云的数据湖解决方案到底有没有实际落地的案例?怎么理解数据湖?数据湖和大数据平台有什么 ...
怎么理解数据湖？（深度长文）
▲ 点击上方"分布式实验室"关注公众号回复"1"抽取技术书最近,数据湖的概念非常热,许多前线的同学都在讨论数据湖应该怎么建?阿里云有没有成熟的数据湖解决方案 ...
java天眼培训_Java天眼大型分布式跟踪系统附带源码_IT教程网
资源名称:Java天眼大型分布式跟踪系统附带源码教程内容: APP: 接入skyeye-client的系统会通过kafkaAppender向kafka写入日志 es-indexer-group: ...
震惊！这篇文章解读数据仓库、数据湖、数据中台等概念，竟然写了4万字！
点击上方 "zhisheng"关注, 星标或置顶一起成长 Flink 从入门到精通系列文章如今,随着诸如互联网以及物联网等技术的不断发展,越来越多的数据被生产出来-据统计,每天 ...

可观测性-Event-埋点数据模型

埋点数据模型

初期

优化

可观测性-Event-埋点数据模型相关推荐

最新文章

热门文章