asppj / lolita

基于gin 微服务opentrace集成

1. Logging - 用于记录离散的事件。例如，应用程序的调试信息或错误信息。它是我们诊断问题的依据。
2. Metrics - 用于记录可聚合的数据。例如，队列的当前深度可被定义为一个度量值，在元素入队或出队时被更新；HTTP 请求个数可被定义为一个计数器，新请求到来时进行累加。
3. Tracing - 用于记录请求范围内的信息。例如，一次远程方法调用的执行过程和耗时。它是我们排查系统性能问题的利器。

Opentrace

1. 埋点：gin-web,http 请求，grpc 请求封装并埋点；
2. 收集：zipkin,AppDash,jaeger 选择其一（阿里云日志服务优先）
3. 展示：

埋点

1. Inject 请求方注入
   • http header
   • grpc with 接口
2. Extract 服务方提取
   • http header
   • grpc with 接口

1. gin-web 服务方 埋点(完成，待测)

添加中间件的方式

2. requests 请求 埋点（完成，待测）

封装 GET、POST、DELET、PUT 等 http 请求方法

3. grpc 埋点（完成，待测）

grpc 使用 grpc 提供的钩子函数

4. DB 驱动埋点

1. mongodb 埋点 （完成）
2. redis 埋点 （未开始）
3. es 埋点 （完成）

opentrance-go 介绍

1. Trace 调用链

2. Span 调用链节点

1. Span-Tag 调用链节点标签

ext.PeerHostname.Set(sp, c.Request.Host)
ext.PeerAddress.Set(sp, c.Request.RemoteAddr)
ext.PeerService.Set(sp, c.ClientIP())
ext.HTTPStatusCode.Set(sp, uint16(statusCode))
ext.HTTPMethod.Set(sp, c.Request.Method)
ext.HTTPUrl.Set(sp, c.Request.URL.Path)

2. Span-Log 调用链节点日志

span.LogKV("Request:", ctx.Request)
span.LogFields("Request:", ctx.Request)

3. Baggage item 全局范围不属于 span

// set
span.SetBaggageItem("greeting", greeting)
// get
greeting := span.BaggageItem("greeting")

4. Sampling,采样[0,1]

sampling.priority - integer

1. const，全量采集，采样率设置0,1 分别对应打开和关闭
2. probabilistic ，概率采集，默认万份之一，0~1之间取值，
3. rateLimiting ，限速采集，每秒只能采集一定量的数据
4. remote ，一种动态采集策略，根据当前系统的访问量调节采集策略

inject/extract

childOf、followOf

1. opentracing.GlobalTracer().Extract 方法提取HTTP头中的spanContexts
2. opentracing.ChildOf 方法基于提取出来的spanContexts生成新的child spanContexts
3. opentracing.GlobalTracer().StartSpan 方法生成一个新的span
4. github.com/opentracing/opentracing-go/ext 通过ext可以为追踪添加一些tag来展示更多信息，比如URL，请求类型(GET，POST...), 返回码
5. sp.Finish() 结束这一个span

context 传递 span

// 存储到 context 中
ctx := context.Background()
ctx = opentracing.ContextWithSpan(ctx, span)
//....

// 其他过程获取并开始子 span
span, ctx := opentracing.StartSpanFromContext(ctx, "newspan")
defer span.Finish()
// StartSpanFromContext 会将新span保存到ctx中更新

context 传递

网络方式传递

Extrect 从 Header 中获取
Extrect 从 grpc Ctx 中提取
inject 注入 Header Inject 注入 grpc Ctx

# 进程中
opentracing.SpanFromContext(ctx)
# 或
span, ctx := opentracing.StartSpanFromContext(ctx, "newspan")
gin.Context:ctx.Request.Context()
gin.Context!=context.Context!=opentracing.SpanContext
mongodb/redis/es:

• context 不再使用 DefaultContext()
• 统一使用 gin.request.Context()[因为携带了 span ]
• 另外添加中间件自定义每个接口的超时时间

jaeger 搭建(本地)

all_in_one 镜像 tools->jaeger->docker-compose.yml

prometheus metrics 统计

prometheus 收集数据

Grafana 展示数据

prometheus 指标类型

1. Counter 单调增
2. Guage 可增减
3. Historygram 直方图
4. Summary 聚合图（1-10 占比，10-20 占比。。。）

gin-ext web 中间件

1. 启动时长-uptime
2. 请求总数-http_request_count_total
3. 请求延时-http_request_duration_seconds
4. 请求字节-http_request_size_bytes
5. 响应字节-http_response_size_bytes

grpc 中间件

kafka golang 驱动封装

消费者

1. 消费延时-kafka_consumer_duration_seconds
2. 消费成功数-kafka_consumer_success_total
3. 消费失败数-kafka_consumer_failed_total
4. Payload 字节数-kafka_consumer_payload_byte_size

生产者

1. 生产延时-kafka_product_duration_seconds
2. 生产成功数-kafka_product_success_total
3. 生产失败数-kafka_product_failed_total
4. Payload 字节数-kafka_product_payload_byte_size

kafka exporter 监控

与版本有关参考

官方 sdk

• github.com/prometheus/client_golang

工具

dem 开发辅助工具 https://github.com/asppj/dem

opentrace 参考资料

1. 几种分布式调用链监控组件的比较
2. opentracing 翻译版
3. grpc-opentracing 中间件
4. openTracing 讲解
5. 阿里云日志服务配置 aliyun-log-jaeger

prometheus 参考资料

1. prometheus 介绍
2. 【监控】Kafka - 详细指标
3. Grafana 与数据可视化
4. 其他参考

Thanks

lolita's Issues

同学，您这个项目引入了132个开源组件，存在1个漏洞，辛苦升级一下

检测到 asppj/lolita 一共引入了132个开源组件，存在1个漏洞

漏洞标题：Gin-Gonic Gin 环境问题漏洞
缺陷组件：github.com/gin-gonic/[email protected]
漏洞编号：CVE-2020-28483
漏洞描述：Gin-Gonic Gin是Gin-Gonic团队的一个基于Go语言的用于快速构建Web应用的框架。
github.com/gin-gonic/gin 全部版本存在安全漏洞，该漏洞源于可以通过设置X-Forwarded-For头来欺骗客户端的IP。
影响范围：(∞, 1.7.7)
最小修复版本：1.7.7
缺陷组件引入路径：github.com/asppj/lolita@->github.com/gin-gonic/[email protected]

另外还有几个漏洞，详细报告：https://mofeisec.com/jr?p=af8fa9

如何自动抓取数据库相关数据

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

codahale/hdrhistogram repo url has been transferred under the github HdrHstogram umbrella

Problem

The codahale/hdrhistogram repo has been transferred under the github HdrHstogram umbrella with the help from the original author in Sept 2020 (new repo url https://github.com/HdrHistogram/hdrhistogram-go). The main reasons are to group all implementations under the same roof and to provide more active contribution from the community as the original repository was archived several years ago.

The dependency URL should be modified to point to the new repository URL. The tag "v0.9.0" was applied at the point of transfer and will reflect the exact code that was frozen in the original repository.

If you are using Go modules, you can update to the exact point of transfer using the @v0.9.0 tag in your go get command.

go mod edit -replace github.com/codahale/hdrhistogram=github.com/HdrHistogram/[email protected]

Performance Improvements

From the point of transfer, up until now (mon 16 aug 2021), we've released 3 versions that aim support the standard HdrHistogram serialization/exposition formats, and deeply improve READ performance.
We recommend to update to the latest version.