埋点的目标是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
: 值有3success
:2org_id
: 20os
:3browser
:6az
:1region
:1则基数为:
3*2*20*3*6*1*1
=2160基数一般建议小于1w,当然这取决于你服务器的配置有多高。
这里注意下,内存基数和influxdb端基数是不一样的。例如,还是上面的计算方式。
error_type
: 内存:3 ,全局:3success
:内存:2 ,全局:2org_id
: 内存:20 ,全局:20os
:内存:20 ,全局:20browser
:内存:6,全局:6az
:内存: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条。
优点:
缺点:
相关字段变少。
可以配合 异常事件或者日志处理。可观测性-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解决。