15.微服务的监控与可观测性

曹大讲课问题记录

发布时间 : 2024-02-27 17:58

阅读 :

如果有优化json：我看助教上周的分享好像只是优化了unmarshal，为什么不优化marshal呢？json的优化场景有什么？有没有必要全局替换？有什么场景不适合替换么
优化标准库的json的优化点在哪，标准库差劲在哪呢，看数据，字节的https://github.com/bytedance/sonic比json-iterator快很多。
开源的优化epoll都是为了节省内存么，看字节的kitex分享，延迟和CPU也优化了很多。
看pprof为什么调度的时间长了总是伴随着GC的时间也长了，比如MAXPROCS开的很多，GC时间也很长
Go服务的CPU为什么最好不要超过50%
goroutine池是为了解决什么问题，
Go的亲和性为啥不好，G上的M亲和不也行么，G不是能亲和P么（L1, L2cache不是在cpu上么，线程不是没换么，线程1每次都调度到CPU1不也行么）goutine的上下文切换不是很快么
有了k8s后网关像kong、nacos之类的是不是不需要引入了，就可以用k8s替代了？
sre方面公司内部对接口响应需要保证时，比如通常所说保证延迟 100ms 内这个是怎么测出来的，不同网络带宽延迟不是不一样的吗？
GRPC和RESTFUL从框架层上有什么区别？
这节课讲写技术文章的要点嘛？
我们的实战项目是当作作业吗？没经验的怎么自学一些监控等等的相关知识（好像没有数据光凭测试很难学习）？
我使用了jaeger UI 的docker 部署在本地，不使用udp agent，使用client http 发送collector，发现jaeger UI 最多存储2000条span，怀疑是部署问题，使用aliyun 的链路送端的配置queue size也调至了100000了
目前线上pprof默认会全部开启吗？对性能影响大吗？
是每个P都有GC么，还是GC是全局的
我公司里的 Prometheus 是阿里云提供的，感觉看到的数据指标和 golang 关系不大。像这种是一定需要集成在代码里？(懂了。。。
Prometheus Server怎么做高可用?
曹大，我们公司目前的监控是一个服务将agent采集的linux性能指标发送到kafka，然后解析服务从kafka拉数据解析存到es，目前有个问题就是，监控的机子多了，解析服务每3分钟拉这里的解析服务cpu和内存尽可能均匀呢, 每3分钟会聚合数据展示
prometheus采集Go服务的数据和go1.16提供的runtime/metrics有啥区别么
公司日志量很大，ES比较耗费大咋优化呢
tracing全部开启线上对性能有影响吗？
给小伙伴们推荐一下挣star的项目，去整一个专门对接各个云的export，现在github上的都不太好用，数据也不全
问个有意思的问题，基础设施部门写了一个agent，agent里面包含了很多功能比如（日志收集，crontab, 统计等功能…），经常agent更新或修改功能，结果agent不稳定经常挂掉；还是适当拆分?
有没有较完整的压测流程和相关工具介绍？
在用prometheus的时候 metrics， abc{name=’xx’} 当 name=xx 之后一直没有update值的时候，后续一直会有该 metrics，不知道怎么去掉
不做全采trace是因为存储的原因吗？

如果有优化json：我看助教上周的分享好像只是优化了unmarshal，为什么不优化marshal呢？json的优化场景有什么？有没有必要全局替换？有什么场景不适合替换么

有的服务涉及到大量的序列化，反序列化
- 自己在数据里存了很多 json 配置
- 运营相关的系统里面，活动相关的配置
一般是从火焰图看出来 json 是瓶颈的，比如 unmarshal 占了 30% 的 CPU
k8s 的 apiserver 有机器列表多的情况，json marshal，unmarshal
{“a” : 1, “b”:2. —- incompatible
gin jsoniter 5w 行测试
没有性能瓶颈，尽量使用标准库

优化标准库的json的优化点在哪，标准库差劲在哪呢，看数据，字节的https://github.com/bytedance/sonic比json-iterator快很多。

sonic 的优点
- sonic 针对编解码器动态组装带来的function-call开销，采用JIT方式来组装schema对应的opcode（as m）并编译成机器码，以go func形式cache到堆外内存中,降低了反射的消耗
- sonic 针对go语言编译优化不足的问题，采用 C/Clang编写关键的解析函数（strch、itoa等），并开发了一套 asm2asm工具，将充分编译优化后的x86 asm转译成plan9并嵌入到go代码中
- sonic 用 JIT 实现了一套轻量级的 function-call,并实现了寄存器传参。
- hack 不,你敢用不
marshal/unmarshal，走 reflect

开源的优化epoll都是为了节省内存么，看字节的kitex分享，延迟和CPU也优化了很多。

看下 kitex 的 P99 https://colobu.com/2021/08/01/benchmark-of-rpc-frameworks/
- mosn sidecar — pod { [java instance] [mosn sidecar] } ==== 4c8G，sidecar resource = max / 4 = 1c2G，2c4G
- RPC 和所有依赖之间都是要建立长连接的
- depend on 100 services * 500 instances = 50000, goroutine stack == 400M –> 500 MB，稍微申请一些 read buffer，write buffer
- push server，10w — 100w 长连接
- netpoll 方案以后，goroutine 数只和活跃连接相关，100w 连接，qps = 1w，1w * goroutine 栈大小 = 100MB

看pprof为什么调度的时间长了总是伴随着GC的时间也长了，比如MAXPROCS开的很多，GC时间也很长

GC 占了更多 CPU，调度变化不大的场景，可以造出来的吧
感觉可以用 pprof –base 看看哪部分变多了。。再结合代码分析

Go服务的CPU为什么最好不要超过50%

物理机上，CPU 超过 50% 后，系统整体的延迟会大幅增加
在 docker 里似乎不太一样
perf 可以调研一下，物理机的 50% 以上之后是不是进程上下文切换更多了

goroutine池是为了解决什么问题，

workerpool，ants，减少 goroutine 的创建与销毁成本( gFree 现在也有复用的逻辑
限制系统总的 goroutine 数，goroutine 超过 30w，延迟会非常非常高，基本不可用了—-是因为加锁么，锁、调度成本都有

Go的亲和性为啥不好，G上的M亲和不也行么，G不是能亲和P么（L1, L2cache不是在cpu上么，线程不是没换么，线程1每次都调度到CPU1不也行么）goutine的上下文切换不是很快么

因为你的 goroutine 在执行过程中可能会被调度走，影响 CPU 中的 L1，L2 cache，regs
goroutine 上下文切换快，说的 goroutine 本身的现场少一些，CPU L1 的重刷新成本应该没有计算在内

有了k8s后网关像kong、nacos之类的是不是不需要引入了，就可以用k8s替代了？

kong bff
东西流量，南北流量（nginx，kong, ingress）
nacos 做服务发现，如果直接用 k8s 内置的服务发现，那可以不用 nacos

sre方面公司内部对接口响应需要保证时，比如通常所说保证延迟 100ms 内这个是怎么测出来的，不同网络带宽延迟不是不一样的吗？

配合 RPC 框架做统计，RPC 框架在接口响应时，统一打印请求/响应时间日志
把请求响应日志收集起来，streaming 平台写一个 sql，就可以计算出你的 99 分位，max resp time，avg resp time
SLA 平台，提供服务的一方会签个协议，99 分位不能超过多少多少 ms

GRPC和RESTFUL从框架层上有什么区别？

基本是两套生态了

这节课讲写技术文章的要点嘛？

https://xargin.com/notes-on-logic-writing/
总结性质：
- 问题 —> Google 搜索 —-> 消化内容 —–> 总结
- 流式计算感兴趣 —-> 曹大对流计算也有了解,话说Go里面能搞出来像Flink 一样的东西吗用Go 写 Flink (我们加餐吧！！！) —> 读书笔记，java/scala UDF，map().keyby().agg(), func callFunc() (data, error)，泛型问题
- 公司里的项目 —> 完成之后 —-> 调研更高级的项目 —> 总结
- ytb 很好的国外的视频分享 —> 怕忘了 —> 结合自己的理解记下来
指引类 tutorial
- 翻译官方文档，补充一些在使用的时候会遇到的坑
公司遇到的问题
- 业务脱敏，只把关键的技术部分整理出来 —-> 输出
内容翻译：
- medium，lobster，acm 里不错的新论文，acm queue，macm 杂志上的文章，都是不错的翻译目标

我们的实战项目是当作作业吗？没经验的怎么自学一些监控等等的相关知识（好像没有数据光凭测试很难学习）？

prometheus，可以自己搭起来玩的
找个便宜的云，买个 ecs，上面搭一个自己的服务(blog，爬虫
prometheus 搭上去，grafana 搭好
《prometheus up and running》这本书要看看
可以用 wrk 之类的工具人工制造一些流量

我使用了jaeger UI 的docker 部署在本地，不使用udp agent，使用client http 发送collector，发现jaeger UI 最多存储2000条span，怀疑是部署问题，使用aliyun 的链路送端的配置queue size也调至了100000了

“docker run -d --name jaeger \
  -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14268:14268 \
  -p 14250:14250 \
  -p 9411:9411 \
  jaegertracing/all-in-one:1.25

目前线上pprof默认会全部开启吗？对性能影响大吗？

影响大,估计也得开。要不然就瞎了～～
需要压测一下看看
给官方提 issue 看看

是每个P都有GC么，还是GC是全局的

GC fractional 计算 P/4 + xxx 25%

我公司里的 Prometheus 是阿里云提供的，感觉看到的数据指标和 golang 关系不大。像这种是一定需要集成在代码里？(懂了。。。

http://github.com/prometheus/client_golang?
counter, gauge

Prometheus Server怎么做高可用?

https://viva.gitbook.io/project/cloud-native/prometheus/cun-chu-fang-an-cha-yi-dui-bi

曹大，我们公司目前的监控是一个服务将agent采集的linux性能指标发送到kafka，然后解析服务从kafka拉数据解析存到es，目前有个问题就是，监控的机子多了，解析服务每3分钟拉这里的解析服务cpu和内存尽可能均匀呢, 每3分钟会聚合数据展示

stream processing —-> flink (cluster) —-> job manager
keyby. shuffle, sum, job
window function, watermark
看一下《stream processing with apache flink/spark》

prometheus采集Go服务的数据和go1.16提供的runtime/metrics有啥区别么

指标应该差不多

公司日志量很大，ES比较耗费大咋优化呢

https://developer.51cto.com/art/202010/628359.htm

tracing全部开启线上对性能有影响吗？

有影响
很多公司 trace 降采样的，可能只有特别核心的链路才是 100%

给小伙伴们推荐一下挣star的项目，去整一个专门对接各个云的export，现在github上的都不太好用，数据也不全

aliyun exporter
tencent cloud exporter

问个有意思的问题，基础设施部门写了一个agent，agent里面包含了很多功能比如（日志收集，crontab, 统计等功能…），经常agent更新或修改功能，结果agent不稳定经常挂掉；还是适当拆分?

同一个部分写的，可以按功能拆多个 agent 吧
多进程模型

有没有较完整的压测流程和相关工具介绍？

wrk，ghz，vegeta，hey
公司内有
- API 压测平台
- 全链路压测平台
  - https://www.usenix.org/conference/osdi16/technical-sessions/presentation/veeraraghavan
- rhino

在用prometheus的时候 metrics， abc{name=’xx’} 当 name=xx 之后一直没有update值的时候，后续一直会有该 metrics，不知道怎么去掉

https://www.shellhacks.com/prometheus-delete-time-series-metrics/
这个问题是说客户端这边吧，你删除的是服务端

不做全采trace是因为存储的原因吗？

监控、trace、log 存储—- 花钱的，成本问题

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 lihuanjie113@gmail.com

15.微服务的监控与可观测性

如果有优化json：我看助教上周的分享好像只是优化了unmarshal，为什么不优化marshal呢？json的优化场景有什么？ 有没有必要全局替换？有什么场景不适合替换么

优化标准库的json的优化点在哪，标准库差劲在哪呢，看数据，字节的https://github.com/bytedance/sonic比json-iterator快很多。

开源的优化epoll都是为了节省内存么，看字节的kitex分享，延迟和CPU也优化了很多。

看pprof为什么调度的时间长了总是伴随着GC的时间也长了，比如MAXPROCS开的很多，GC时间也很长

Go服务的CPU为什么最好不要超过50%

goroutine池是为了解决什么问题，

Go的亲和性为啥不好，G上的M亲和不也行么，G不是能亲和P么（L1, L2cache不是在cpu上么，线程不是没换么，线程1每次都调度到CPU1不也行么）goutine的上下文切换不是很快么

有了k8s后网关像kong、nacos之类的是不是不需要引入了，就可以用k8s替代了？

sre方面公司内部对接口响应需要保证时，比如通常所说保证延迟 100ms 内这个是怎么测出来的，不同网络带宽延迟不是不一样的吗？

GRPC和RESTFUL从框架层上有什么区别？

这节课讲写技术文章的要点嘛？

我们的实战项目是当作作业吗？没经验的怎么自学一些监控等等的相关知识（好像没有数据光凭测试很难学习）？

我使用了jaeger UI 的docker 部署在本地， 不使用udp agent，使用client http 发送collector，发现jaeger UI 最多存储2000条span， 怀疑是部署问题，使用aliyun 的链路送端的配置queue size也调至了100000了

目前线上pprof默认会全部开启吗？对性能影响大吗？

是每个P都有GC么，还是GC是全局的

我公司里的 Prometheus 是阿里云提供的，感觉看到的数据指标和 golang 关系不大。像这种是一定需要集成在代码里？(懂了。。。

Prometheus Server怎么做高可用?

prometheus采集Go服务的数据和go1.16提供的runtime/metrics有啥区别么

公司日志量很大，ES比较耗费大咋优化呢

tracing全部开启线上对性能有影响吗？

给小伙伴们推荐一下挣star的项目，去整一个专门对接各个云的export，现在github上的都不太好用，数据也不全

问个有意思的问题，基础设施部门写了一个agent，agent里面包含了很多功能比如（日志收集，crontab, 统计等功能…），经常agent更新或修改功能，结果agent不稳定经常挂掉； 还是适当拆分?

有没有较完整的压测流程和相关工具介绍？

在用prometheus的时候 metrics， abc{name=’xx’} 当 name=xx 之后一直没有update值的时候，后续一直会有 该 metrics，不知道怎么去掉

不做全采trace是因为存储的原因吗？

如果有优化json：我看助教上周的分享好像只是优化了unmarshal，为什么不优化marshal呢？json的优化场景有什么？有没有必要全局替换？有什么场景不适合替换么

我使用了jaeger UI 的docker 部署在本地，不使用udp agent，使用client http 发送collector，发现jaeger UI 最多存储2000条span，怀疑是部署问题，使用aliyun 的链路送端的配置queue size也调至了100000了

问个有意思的问题，基础设施部门写了一个agent，agent里面包含了很多功能比如（日志收集，crontab, 统计等功能…），经常agent更新或修改功能，结果agent不稳定经常挂掉；还是适当拆分?

在用prometheus的时候 metrics， abc{name=’xx’} 当 name=xx 之后一直没有update值的时候，后续一直会有该 metrics，不知道怎么去掉