Giter Site home page Giter Site logo

tencentblueking / bk-log Goto Github PK

View Code? Open in Web Editor NEW
119.0 12.0 56.0 40.8 MB

蓝鲸日志平台是为了解决运维场景中查询日志难的问题而推出的一款SaaS,基于业界主流的全文检索引擎,通过蓝鲸智云的专属agent进行日志采集,无需登录各台机器,集中管理所有日志。

Home Page: https://bk.tencent.com/

License: Other

Makefile 0.01% Python 60.02% Shell 0.22% HTML 1.06% Batchfile 0.01% JavaScript 5.59% CSS 2.20% Vue 26.34% TypeScript 3.91% SCSS 0.65% EJS 0.01%
python log elasticsearch

bk-log's Introduction

license GitHub release (latest by date) PRs Welcome codecov Web Test

English | 简体中文

重要提示: master 分支在开发过程中可能处于 不稳定或者不可用状态 。 请通过 releases 而非 master 去获取稳定的二进制文件。

蓝鲸日志平台(BK-LOG)是为解决分布式架构下日志收集、查询困难的一款日志产品,基于业界主流的全文检索引擎,通过蓝鲸智云的专属 Agent 进行日志采集,提供多种场景化的采集、查询功能。

Overview

Features

  • 简单易用的日志采集
  • 可视化的日志字段提取
  • 功能强大的日志查询
  • 实时日志和日志上下文
  • 日志关键字/汇聚告警
  • 支持第三方 ES 接入
  • 分布式跟踪支持
  • 仪表盘能力
  • 在线日志文件提取

Getting Started

  • 安装好MySQL 5.7Python3.6,若同时开发多个项目,请创建Python虚拟环境

  • 创建数据库 CREATE DATABASE bk_log DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

  • 在项目config新建local_settings.py文件,文件内容为数据库配置,如

       DATABASES = {
          'default': {
              'ENGINE': 'django.db.backends.mysql',
              'NAME': 'bk_log',
              'USER': 'root',
              'PASSWORD': '',
              'HOST': '127.0.0.1',
              'PORT': '3306',
          },
      }
  • 编译前端

    cd web
    npm install
    npm run build
  • 配置环境变量

    APP_ID=${APP_ID}
    BK_IAM_V3_INNER_HOST=${BK_IAM_V3_INNER_HOST}
    BK_PAAS_HOST=${BK_PAAS_HOST}
    APP_TOKEN=${APP_TOKEN}
    # BKAPP_REDIS_PASSWORD=${BKAPP_REDIS_PASSWORD}  # 缓存和Celery会使用到redis,如果本地redis有密码需要增加这个环境变量
  • 启动工程 python manage.py runserver 8000

  • 启动celery celery -A worker -l info -c 8

Support

BlueKing Community

  • BK-CMDB:蓝鲸配置平台(蓝鲸 CMDB)是一个面向资产及应用的企业级配置管理平台。
  • BK-CI:蓝鲸持续集成平台是一个开源的持续集成和持续交付系统,可以轻松将你的研发流程呈现到你面前。
  • BK-BCS:蓝鲸容器管理平台是以容器技术为基础,为微服务业务提供编排管理的基础服务平台。
  • BK-PaaS:蓝鲸 PaaS 平台是一个开放式的开发平台,让开发者可以方便快捷地创建、开发、部署和管理 SaaS 应用。
  • BK-SOPS:标准运维(SOPS)是通过可视化的图形界面进行任务流程编排和执行的系统,是蓝鲸体系中一款轻量级的调度编排类 SaaS 产品。

Contributing

如果你有好的意见或建议,欢迎给我们提 Issues 或 Pull Requests,为蓝鲸开源社区贡献力量。关于 bk-log 分支管理、Issue 以及 PR 规范, 请阅读 Contributing Guide

腾讯开源激励计划 鼓励开发者的参与和贡献,期待你的加入。

License

项目基于 MIT 协议, 详细请参考 LICENSE

bk-log's People

Contributors

benero avatar evildoerxiaoyy avatar jacky15 avatar jayjiahua avatar kiritoscs avatar liuwenping avatar orenzhang avatar qqqqqie avatar rxwycdh avatar ta0tao avatar wyyalt avatar yetlau111 avatar zijiaone avatar zzhutianyu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bk-log's Issues

自定义上报方案

日志自定义上报方案(Logs Trace)

阿里云

日志上报

https://help.aliyun.com/document_detail/112903.html?spm=a2c4g.11186623.6.817.626f175bMJTh5c

  • 基于SDK上报日志

腾讯云

蓝鲸日志平台

架构设计

日志平台自定义上报

模块说明

  • bk-log-receiver
    实现接收日志协议格式包括

    • otlp-grpc
    • otlp-http
    • 日志上报http
    • 日志上报TCP
    • 日志上报UDP
      通过以上上报协议接收日志或者Trace并通过协议内携带的dataid进行上报
      读取平台下发自定义上报dataid,不符合的dataid进行丢弃
  • 节点管理

    • 安装上报集群
    • 下发自定义上报配置到上报集群

上报协议

  • otlp协议(http|grpc) (上报logs Trace)
    上报需要在resource携带bk_data_id
    python如下所示
resource = Resource.create({
			"service.name": settings.APP_CODE,
			"bk_data_id": 1
		}),
	)
  • http协议
/v1/push/
{
	"bk_data_id": 113,
	"source": "xxxx", 来源ip或者其他
	"logs": ["xxx", "xxx"]
}
  • tcp|udp协议
  1. 二进制格式
type LogMessage struct {
	Timestamp uint64
	MessageLen uint32
	Message []byte
}

// LogPack log package define
type LogPack struct {
	PkgLen uint32 // 包总长度 (标识符不计算在内)
	PkgVer uint8 // 包版本号,0x02
	SourceLen uint8 // 来源长度
	Source []byte // 来源字符串
	BkDataId int // bkdataid
	Compress uint8 // 压缩选项,0x00 无,0x01 gzip
	Messages []*LogMessage // 消息体(若 compress!=0x00 则为压缩后的 buffer)
}
  • 需要提供包协议格式或者sdk
  • 可以进行压缩
  1. json格式
{
	"bk_data_id": 113, 蓝鲸dataid
	"source": "xxxx", 来源ip
	"logs": ["xxx", "xxx"], 日志数组
	"version": "v1", 协议版本
}
  • 每种语言都有json库方便序列化

上报集群部署

  • 节点管理部署
  1. 平台管理员在平台进行集群选择通过节点管理下发到选择到机器,并通过节点管理进行维护
  2. 并可以在平台指定域名(企业版默认云区域自动写入到consul)
  3. 提供cmd命令进行安装
  • 运维手动部署
  1. 运维通过部署文档部署到指定机器
  2. 在平台侧进行配置上报集群

上报服务配置

主配置

max_message_size: 512kb
queue_limit: 50000
ip_limit: true

子配置

- type: otlp-trace
  dataid: 1111
  
- type: otlp-logs
  dataid: 1111
  
- type: http
  dataid: 1111
  
- type: udp
  dataid: 2222
  
- type: tcp
  dataid: 22223

集群保护(QOS)

  • 单次请求大小限制
  • 队列水位限制(超过丢弃)
  • ip屏蔽
  • dataid 限制 不在配置内的dataid 丢弃
  • 是否加token进行限制?

otlp-trace 采样&染色能力

采样

相关trace采样
https://docs.newrelic.com/docs/distributed-tracing/concepts/how-new-relic-distributed-tracing-works/
trace数据量大 全量大数据上报对链路&存储都是巨大的压力

  • 原始SDK采样配置
    原始sdk会在入口侧进行采样判断,然后后续链路则不进行上报操作
    但是会存在错误trace 触发采样导致无法上报

  • 接收侧采样
    image
    image

otlp官方实现
https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/tailsamplingprocessor/README.md
https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/loadbalancingexporter/README.md

  • 需要实现基于trace_id的LB服务将一类trace_id发送到一个bk-log-receiver服务,通过尾采样算法进行采样,能够将错误的trace充分还原
  • 集群自转发 通过一致性hash等类似算法将同一trace转发到对应recevier服务,不通过lb进行前端负载,集群自中转

染色能力

  • SDK获取染色配置
    需要提供SDK拉取染色配置,需要平台方提供SDK去拉取对应的染色配置
  • 接收侧染色能力
    需要实现接收端多机分布下的数据汇聚能力,将trace进行采样豁免使其能够进行稳定上报

负载均衡方案

  • gslb提供就近vip接入
  • vip进行后端rs负载均衡

Saas配置

  • 平台方
  1. 选择不同云区域的机器部署上报服务
  2. 配置域名的能力
  • 用户
  1. 创建自定义上报
  2. 获取自定义上报地址

系统调优

  • 长链接调优
ulimit -n 1040000

otlp-grpc 压测报告

测试条件

限制单核使用

工具 ghz

机器

8核心16G

CPU MHz: 2595.124

链接数量 1
span数量 1
并发数量 10000 20000 50000 100000
1 3961 4025 4053 3996
10 12513 13056 12753 12379
100 15978 13852 14549 14736
1000 13708 14721 15121 14921
10000 9546 10128 10789 10861
链接数量 1
span数量 10
并发数量 10000 20000 50000 100000
1 1767 1752 1767 1767
10 2987 2893 2900 3009
100 5621 5381 4660 4194
1000 788 807 1069 2418
10000 3819 1770 2155 2097

机器配置

8核

gse上报

链接数量 1
span数量 100
并发数量 10000 20000 50000 100000
1 207 208 209 218
10 461 487 507 555
100 451 456 536 472
1000 456 451 536 451
10000 472 412 432 452

image

Otlp-http-json 压测报告

机器配置

8核

自研云机器

gse上报

测试工具 ab

链接数量 1
span数量 1
并发数量\请求数量 10000 20000 50000 100000
1 2141 2120 2120 2132
10 3278 3358 3291 3311
100 3476 3414 3585 3530
1000 3221 3303 3285 3391
10000 2715 2911 3053 3144
链接数量 1
span数量 10
并发数量\请求数量 10000 20000 50000 100000
1 655 669 652 661
10 753 760 756 768
100 779 787 785 793
1000 716 710 707 733
10000 618 754 656 665
span数量 100
并发数量\请求数量 10000 20000 50000 100000
1 95 95 96 96
10 96 96 96 96
100 97 93 92 92
1000 77 77 77 77

主要消耗在json反序列上面
image-20210909091238466

Otlp-http-proto 压测报告

span数量 1
并发数量\请求数量 10000 20000 50000 100000
1 3491 3491 3411 3564
10 8176 8997 9674 9532
100 8795 8457 8871 8422
1000 9712 3303 3285 3391
10000 7240 8613 8359 8401

采集项数据量过大,索引集管理新增采集类型索引集报502错误

  1. 问题描述
    当业务下“数据接入”建立的采集项过多时,在“索引集管理”-“新建”-“采集接入”-“新增索引” 报502错误;

  2. 版本信息
    4.2.653

  3. 报错截图
    image

  4. 问题原因
    metadata_get_result_table_storage 接口设计不合理,为get请求,参数result_table_list支持传list,当达到一定大小后接口返回502错误

分隔符过滤匹配带有空格数据无法采集到数据

数据接入配置日志内容过滤规则,采用分隔符过滤,匹配字段前后带有空格数据无法采集到日志数据:

  • 采集接入配置:采用","分割,匹配第二列包含“ after callback”(字符串前面带有空格),编辑查看详情已将空格自动删除;
    image
    image

  • 问题原因

  1. django 序列化器默认将空格删除(默认trim_whitespace=True);
    image

  2. 下发的采集配置文件已将空格取消,但采集器匹配内容的时候分割日志后是带空格去匹配关键字的,导致匹配不到内容;
    image
    image

  • 解决方案
  1. 方案一:修改序列器,增加trim_whitespace=False;
  2. 方案二:修改采集器匹配逻辑,分割完去除前后空格去匹配关键字(个人建议采用该方案,因为空格内容对用户无意义);
    image

日志提取 打包脚本未清理历史文件

What happened:
日志提取 打包脚本未清理历史文件

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

日志平台对接bk-repo

What would you like to be added:

  • 日志提取从nfs升级为bk-repo
  • 异步导出对接bk-repo

Why is this needed:

Trace-Log-Metric关联方案

指标关联Trace

exemplar机制

prometheus

prometheus主要是采用 exemplars 的机制在 metrics 中带上额外的信息。通过metrics的接口可以同事暴露exemplar
https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#exemplars-1

# 后面的内容就是exemplar
# lable 采样值 采样时间
foo_bucket{le="0.1"} 8 # {} 0.054
foo_bucket{le="1"} 11 # {trace_id="KOO5S4vxi0o"} 0.67
foo_bucket{le="10"} 17 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607.789

注入方式

c := GetPlayURLTotal.WithLabelValues(
            strconv.FormatInt(int64(callerType), 10),
            strconv.FormatInt(int64(device.GetOs()), 10),
            strconv.FormatInt(int64(device.GetNetwork()), 10),
            videoFormat,
)
sp := trace.SpanFromContext(ctx).SpanContext()
if sp.IsSampled() { // 可以继续增加其他条件使得exemplar样本更加典型
    c.(prometheus.ExemplarAdder).AddWithExemplar(1, prometheus.Labels{
          "traceID": sp.TraceID().String(),
    }) // 如果是histogram类型的则类型断言为prometheus.ExemplarObserver
} else {
    c.Inc()
}

otlp

otlp在协议中有Exemplar字段 可以在指标上报时将被采样的span跟指标关联.otlp-SDK是自动进行注入的,因为trace-log-metric 三者共享同样的otlp-context,所以可以不必要进行手工关联

// A representation of an exemplar, which is a sample input measurement.

// Exemplars also hold information about the environment when the measurement

// was recorded, for example the span and trace ID of the active span when the

// exemplar was recorded.

message Exemplar {

// The set of key/value pairs that were filtered out by the aggregator, but

// recorded alongside the original measurement. Only key/value pairs that were

// filtered out by the aggregator should be included

repeated opentelemetry.proto.common.v1.KeyValue filtered_attributes = 7;

// Labels is deprecated and will be removed soon.

// 1. Old senders and receivers that are not aware of this change will

// continue using the `filtered_labels` field.

// 2. New senders, which are aware of this change MUST send only

// `filtered_attributes`.

// 3. New receivers, which are aware of this change MUST convert this into

// `filtered_labels` by simply converting all int64 values into float.

//

// This field will be removed in ~3 months, on July 1, 2021.

repeated opentelemetry.proto.common.v1.StringKeyValue filtered_labels = 1 [deprecated = true];

// time_unix_nano is the exact time when this exemplar was recorded

//

// Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January

// 1970.

fixed64 time_unix_nano = 2;

// The value of the measurement that was recorded. An exemplar is

// considered invalid when one of the recognized value fields is not present

// inside this oneof.

oneof value {

double as_double = 3;

sfixed64 as_int = 6;

}

// (Optional) Span ID of the exemplar trace.

// span_id may be missing if the measurement is not recorded inside a trace

// or if the trace is not sampled.

bytes span_id = 4;

// (Optional) Trace ID of the exemplar trace.

// trace_id may be missing if the measurement is not recorded inside a trace

// or if the trace is not sampled.

bytes trace_id = 5;

}

prometheus存储方式(tjg使用该方式)

https://github.com/prometheus/prometheus/pull/6635/files
prometheus 实现了一种环形连续内存的结构来存储 exemplar,并实现了对应的查询接口

$ curl -g 'http://localhost:9090/api/v1/query_exemplars?query=test_exemplar_metric_total&start=2020-09-14T15:22:25.479Z&end=020-09-14T15:23:25.479Z'
{
    "status": "success",
    "data": [
        {
            "seriesLabels": {
                "__name__": "test_exemplar_metric_total",
                "instance": "localhost:8090",
                "job": "prometheus",
                "service": "bar"
            },
            "exemplars": [
                {
                    "labels": {
                        "traceID": "EpTxMJ40fUus7aGY"
                    },
                    "value": "6",
                    "timestamp": 1600096945.479,
                }
            ]
        },
        {
            "seriesLabels": {
                "__name__": "test_exemplar_metric_total",
                "instance": "localhost:8090",
                "job": "prometheus",
                "service": "foo"
            },
            "exemplars": [
                {
                    "labels": {
                        "traceID": "Olp9XHlq763ccsfa"
                    },
                    "value": "19",
                    "timestamp": 1600096955.479,
                },
                {
                    "labels": {
                        "traceID": "hCtjygkIHwAN9vs4"
                    },
                    "value": "20",
                    "timestamp": 1600096965.489,
                },
            ]
        }
    ]
}

image

日志关联Trace

日志关联Trace 比较简单 只要在打印日志的时候获取到链路的TraceId和spanId 就可以关联Trace和单条日志了

Log
timestamp= TraceId=xxxx SpanId=xxxxx
Json
{"trace_id": "xxx", "span_id": "xxx", "log": "xxxx"}

最终清洗入库并标记trace_id和span_id即可实现联动
image

otlp-SDK 最终可以实现默认关联因为共享Context

监控存储exemplar

由于influxdb目前不支持exemplar入库,所以基于现有存储结构监控可以使用ES进行exemplar存储,避免高基线问题
修改如下

  • 相关prometheus的数据解析需要支持exemplar类型的解析并上报
  • transfer需要支持exemplar数据入库到ES
  • saas支持exemplar数据的查询

采集日志,支持排除某个路径

日志路径:
现在要一起采集服务器A和服务器B的日志,日志路径如下
服务器A日志:

/log/a/*.log
/log/b/*.log
/log/c/*.log

服务器B日志:

/log/a/*.log
/log/d/*.log
/log/e/*.log

采集需求:排除 /log/a/ 路径,其余的都采集。

image

成功接入外部ES后无法创建索引集

问题:接入外部ES后(连通性测试正常),但是创建索引集失败:
QQ截图20210813114828
QQ截图20210813115556

原因:连通性测试走的是APPO到ES(用户只开通了APPO到ES的防火墙),创建索引集查询走的却是日志后台:

建议功能优化:连通性测试需要测试日志后台到ES的网络连接(连通性测试接口走日志后台?):

成功接入外部ES后无法创建索引集

问题:接入外部ES后(连通性测试正常),但是创建索引集失败:
QQ截图20210813114828
QQ截图20210813115556

原因:连通性测试走的是APPO到ES(用户只开通了APPO到ES的防火墙),创建索引集查询走的却是日志后台:

建议功能优化:连通性测试需要测试日志后台到ES的网络连接(连通性测试接口走日志后台?):

字段提取功能问题

版本信息

  • saas&后台版本:4.2.653

json提取方式问题

  1. 问题描述:json清洗后带特殊字符的字段重命名后前端校验不通过;
  2. 理想结果:json清洗后带特殊字符的字段重命名,只需要校验重命名字段格式,而不需要校验原始字段;
  3. 问题截图:
    image
  4. 日志原文:
{
    "@timestamp": "2021-11-05T22:10:00.000Z",
    "@version": "1",
    "program": "/usr/sbin/cron",
    "host": "127.0.0.1",
    "timestamp": "Nov  6 06:10:00",
    "message": "(root) CMD (   /usr/libexec/atrun)",
    "priority": 78,
    "pid": "39172",
    "facility_label": "clock",
    "logsource": "ELI-PC",
    "severity_label": "Informational",
    "severity": 6,
    "facility": 9
}

时间字段清洗问题

  1. 问题描述:“2021-11-05T22:10:00.000Z” 时间数据用“YYYY-MM-DDTHH:mm:ss.SSSZ”格式清洗失败;
  2. 理想结果:时间字段和数据格式匹配应该清洗成功;
  3. 问题截图:
    image
  4. 日志原文:
{
    "@timestamp": "2021-11-05T22:10:00.000Z",
    "@version": "1",
    "program": "/usr/sbin/cron",
    "host": "127.0.0.1",
    "timestamp": "Nov  6 06:10:00",
    "message": "(root) CMD (   /usr/libexec/atrun)",
    "priority": 78,
    "pid": "39172",
    "facility_label": "clock",
    "logsource": "ELI-PC",
    "severity_label": "Informational",
    "severity": 6,
    "facility": 9
}

仪表板设置变量信息报错

  1. 问题描述
    点击“仪表盘” - “Dashboard settings” - “variables” - “add variable” 填写变量信息有报错,无法设置变量

  2. 版本信息
    4.2.653和4.3.1-275测试都有发现

  3. 报错截图

企业微信截图_16527818859300
企业微信截图_16527819816703
企业微信截图_1652782020591

新增syslog日志采集能力

What would you like to be added:

  • 日志平台采集器新增syslog日志采集能力;

Why is this needed:

  • 路由器、交换机等设备可以直接通过syslog协议将日志发送到bkunifylogbeat,实现日志平台对硬件设备日志的采集能力;

bugfix: ESQuery接口对已删除的索引集ID处理有问题

What happened:

ERROR [2021-07-17 16:53:52] /data/bkee/bklog/api/apps/common/log.py 74 exception 16473 139768304719680
0e9371dd-8fb9-41f1-80bc-8ee62b601fa0 | 'NoneType' object has no attribute 'scenario_id'
Traceback (most recent call last):
File "/data/bkee/.envs/bklog-api/lib/python3.6/site-packages/rest_framework/views.py", line 506, in dispatch
response = handler(request, *args, **kwargs)
File "/data/bkee/bklog/api/apps/log_esquery/views/esquery_views.py", line 205, in search
data = self.params_valid(EsQuerySearchAttrSerializer)
File "/data/bkee/bklog/api/apps/generic.py", line 126, in params_valid
return custom_params_valid(serializer=serializer, params=params)
File "/data/bkee/bklog/api/apps/utils/drf.py", line 85, in custom_params_valid
_serializer.is_valid(raise_exception=True)
File "/data/bkee/.envs/bklog-api/lib/python3.6/site-packages/rest_framework/serializers.py", line 220, in is_valid
self._validated_data = self.run_validation(self.initial_data)
File "/data/bkee/.envs/bklog-api/lib/python3.6/site-packages/rest_framework/serializers.py", line 422, in run_validation
value = self.validate(value)
File "/data/bkee/bklog/api/apps/log_esquery/serializers.py", line 74, in validate
index_info = _get_index_info(index_set_id)
File "/data/bkee/bklog/api/apps/log_esquery/serializers.py", line 326, in _get_index_info
result_dict = _init_index_info(index_set_id)
File "/data/bkee/bklog/api/apps/log_esquery/serializers.py", line 336, in _init_index_info
scenario_id = tmp_index_obj.scenario_id
AttributeError: 'NoneType' object has no attribute 'scenario_id'

minor: 采集列表页的顺序经常会迷之变化

What happened:
列表页的顺序采用的是CollectorConfig的update_at字段。
当前系统存在周期任务,刷新这周表的字段数据。会导致周期任务执行后,列表页自动变化了。
image

What would you like to be added:
CollectorConfig表设计需要重新整理,当前字段太多,一些和用户配置相关的保留,其余字段都需要拆到新的表来存储

Why is this needed:
Not user friendly enough

采样方案

为什么需要采样

  • 在生产系统中,调用是非常频繁的这就导致了在高频系统中,会产生非常多的span,这样就会给整个链路和存储带来压力
  • 而一些系统又不是高频系统,所以可以存储所有的span
    合理的采样可以极大降低成本和整体系统的压力
    所以我们对于span的产生需要进行合理采样

怎么进行采样

目前主要有两种采样形式

  • 一种是基于头部的采样
    也就是在根链路的产生的时候来进行采样策略判断是否进行采样,目前主流的分布式跟踪框架都主要使用这一方式,虽然头部采样的形式能比较好降低span的产生,但是在实际生产中,大部分都是正常的链路,少部分才是异常链路,采样策略可能会将错误链路给命中,导致异常被遗漏。基于头部的采样,是需要在TRACE-SDK进行配置,它直接在应用程序生效,所以管控这个配置是有成本的。如果在微服务更个服务比较独立的时候还存在一些服务开启了采样,一些服务没有开启采样,这就会导致某几个未开启服务产生大量span对整个上下游服务进行了传播,导致后端服务压力大增。
  • 基于尾部的采样
    基于尾部的采样能很好的将异常的链路进行保留,而且基于尾部的采样是允许在接收服务中的,这就意味着,应用程序只需要关注上报服务是谁,而不在需要关注额外的配置和配置变更。但是尾部采样也存在的一些问题,就是当span跨度过大时,进行的采样的时候,可能会遗漏部分长尾span.而且过大的全量流量对于上报服务来说也有着一定的压力考验。

基于头部的采样

image

基于头部的采样是现在主流分布式跟踪的框架进行采样的主要模式。在otlp当中就原生实现了采样的配置,并支持了一些原生的采样策略。

  • ALWAYS_ON 总是产生
  • ALWAYS_OFF 不产生
  • ALWAYS_PARENT 信任父span的采样结果
  • Probability 概率采样
    这些都是配置的头部采样的配置。
    如果支持头部采样,我们还需要实现能够让用户进行应用运行时的一些配置的修改。
  • 采样配置
    • 采样策略
    • 采样精度
  • 染色配置
    • 匹配字段
    • 目标值

平台SDK-api配置拉取或者直接api获取配置

主要需要后端平台侧提供配置获取接口
用户需要在应用层或者平台SDK实现以下功能

  • 定时的配置拉取
  • 配置刷新
    image

用户配置文件读取

用户需要自行手动或者自动化程序去修改对应的配置文件例如yaml文件等进行相应的配置文件修改,应用需要支持以下功能

  • 动态文件配置读取更新

image

用户自定义配置服务更新

和第一类类似,主要是业务侧自己的配置服务或者其他类似服务可以进行配置的下发或者拉取

image

基于尾部的采样

image

尾部采样主要是在上报之后由接收侧服务进行采样,这样做需要进行一定数据的缓存,我们可以在接收端做,也可以在链路中做,但是最主要解决的问题,是需要相同trace_id的span进行缓存主要有以下方式

Trace-Lb

image

集群一致性转发

image

检索查询优化专项

What would you like to be added:
大索引查询时间过长时,查询时间较长,优化为分段时间进行加载

Why is this needed:

The keyword 'interface' is reserved

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.