Prometheus采不到数据了!居然是Prometheus client包的锅

本文永久链接 – https://tonybai.com/2022/06/15/prometheus-can-not-pick-up-data-because-of-the-prometheus-client-package

在基于eBPF的新一代观测设施尚未成熟之前,我们采用了业界成熟的Prometheus+Grafana方案采集节点与应用度量指标(metrics)信息。众所周知,这样的方案是一种对应用有侵入的方案,即需要在应用内部嵌入采集度量信息及与Prometheus通信的client包。

Prometheus官方提供并维护了主流语言的client包,包括Go、Java、Python、Ruby、Rust等,如下图:

Prometheus的go client端使用起来也不算复杂,总共分两步:

  • 把你要获取的度量指标注册(Register)到Prometheus的Registry中;
  • 建立起一个HTTP Server,暴露度量指标采集端口即可。

Prometheus采用拉模型(pull)收集时序度量数据,数据拉取行为是由Prometheus服务端来决定的,比如可以设定Prometheus拉取各个采集点的时间周期。 一般来说,这个技术栈已经很成熟,配置完启动后,马上就能看到效果。这个技术栈也很稳定,我们使用后一直运行良好,直到本周压测时遇到一个问题:Prometheus采不到数据了

从最初的数据由连续的线变成“断断续续”的点,见下图:

到后来干脆就无法采到任何数据了:

之前Prometheus跑的好好的,为什么现在却采不到数据了呢?这次与之前的不同之处在于我们的压测用例情景下,每个服务节点都要建立百万以上的连接,而之前仅仅是10w左右的量级。

好在我们部署了在线Continuous Profiling工具,可以查看一下压测那段时间的资源占用,如下图:

上面是一个alloc object的火焰图,我们看到Prometheus client的Registry.Gather方法占了50%的内存分配开销,这是很不正常的。继续沿着Gather函数的火焰图看,我们看到底端居然是readdir。我们应用注册的度量指标也没有哪个采集时需要readdir啊!

要想解决这个问题只有翻Prometheus client源码了!

我们使用的是prometheus client端的默认defaultRegistry。 从源码中可以看到:这个defaultRegistry在初始化时,默认注册了两个collector:

// registry.go
func init() {
    MustRegister(NewProcessCollector(ProcessCollectorOpts{}))
    MustRegister(NewGoCollector())
}

我们发现:第一个processCollector会采集如下度量指标数据:

// process_collector.go
func (c *processCollector) Describe(ch chan<- *Desc) {
    ch <- c.cpuTotal
    ch <- c.openFDs
    ch <- c.maxFDs
    ch <- c.vsize
    ch <- c.maxVsize
    ch <- c.rss
    ch <- c.startTime
}

在采集openFDs时,processCollector遍历了/proc/{pid}下面的fd目录:

// process_collector_other.go
func (c *processCollector) processCollect(ch chan<- Metric) {
    pid, err := c.pidFn()
    if err != nil {
        c.reportError(ch, nil, err)
        return
    }

    p, err := procfs.NewProc(pid)
    if err != nil {
        c.reportError(ch, nil, err)
        return
    }

    if stat, err := p.Stat(); err == nil {
        ch <- MustNewConstMetric(c.cpuTotal, CounterValue, stat.CPUTime())
        ch <- MustNewConstMetric(c.vsize, GaugeValue, float64(stat.VirtualMemory()))
        ch <- MustNewConstMetric(c.rss, GaugeValue, float64(stat.ResidentMemory()))
        if startTime, err := stat.StartTime(); err == nil {
            ch <- MustNewConstMetric(c.startTime, GaugeValue, startTime)
        } else {
            c.reportError(ch, c.startTime, err)
        }
    } else {
        c.reportError(ch, nil, err)
    }

    if fds, err := p.FileDescriptorsLen(); err == nil { // 这里获取openFDs
        ch <- MustNewConstMetric(c.openFDs, GaugeValue, float64(fds))
    } else {
        c.reportError(ch, c.openFDs, err)
    }

    if limits, err := p.Limits(); err == nil {
        ch <- MustNewConstMetric(c.maxFDs, GaugeValue, float64(limits.OpenFiles))
        ch <- MustNewConstMetric(c.maxVsize, GaugeValue, float64(limits.AddressSpace))
    } else {
        c.reportError(ch, nil, err)
    }
}

采集openFDS时,processCollector调用了FileDescriptorsLen方法,在FileDescriptorsLen方法调用的fileDescriptors方法中,我们找到了对Readdirnames的调用,见下面源码片段:

// github.com/prometheus/procfs/proc.go

// FileDescriptorsLen returns the number of currently open file descriptors of
// a process.
func (p Proc) FileDescriptorsLen() (int, error) {
    fds, err := p.fileDescriptors()
    if err != nil {
        return 0, err
    }

    return len(fds), nil
}  

func (p Proc) fileDescriptors() ([]string, error) {
    d, err := os.Open(p.path("fd"))
    if err != nil {
        return nil, err
    }
    defer d.Close()

    names, err := d.Readdirnames(-1) // 在这里遍历目录中的文件
    if err != nil {
        return nil, fmt.Errorf("could not read %q: %w", d.Name(), err)
    }

    return names, nil
}

通常情况下,读取/proc/{pid}/fd目录是没有问题的,但当我们的程序上连接着100w+的连接时,意味着fd目录下有100w+的文件,逐一遍历这些文件将带来很大的开销。这就是导致Prometheus在超时时间(通常是10几秒)内无法及时采集到数据的原因。

那么如何解决这个问题呢?

临时解决方法是将registry.go文件的init函数中的MustRegister(NewProcessCollector(ProcessCollectorOpts{}))这一行注释掉!这个进程度量指标信息对我们用处不大。不过这样做的不足是我们自己需要维护一份prometheus golang client包,需要用到go mod replace,十分不便,并且不便于prometheus golang client包的版本升级。

一劳永逸的解决方法是:不使用默认Registry,而是使用NewRegistry函数新建一个Registry。这样我们抛开默认注册的那些度量指标,并可以自行定义我们要注册的度量指标。需要时,我们也可以将ProcessCollector加进来,这个根据不同Go程序的需要而定。

按这个方案修改后,那些熟悉的连续曲线就又重现在眼前了!


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go 1.19新特性前瞻

本文永久链接 – https://tonybai.com/2022/06/12/go-1-19-foresight

美国时间2022年5月7日,Go 1.19版本开发分支进入新特性冻结(freeze)阶段,即只能修Bug,不能再向Go 1.19版本中增加新特性了。由于上一个版本Go 1.18因引入泛型改动较大,推迟了一个月发布,这直接导致了Go 1.19版本的开发周期被缩短。

虽然开发周期少了近一个月,但Go 1.19版本仍然会按计划在2022年8月份发布。而Go 1.19的第一个beta版也于今天凌晨发布了。Go 1.19版本都有哪些重要变化呢,我通过这篇文章带大家先睹为快。

注1:版本特性变化以最终发布为准!
注2:本文仅是前瞻,不会过于深入细节。细节待Go 1.19正式发布后再聊。

泛型问题的fix

尽管Go核心团队在Go 1.18泛型上投入了很多精力,但Go 1.18发布后泛型这块依然有已知的天生局限,以及后续逐渐发现的一些问题,而Go 1.19版本将继续打磨Go泛型,并重点fix Go 1.18中发现的泛型问题。目前Go 1.19开发版本中大约有5-6个泛型问题待解决。之前谈到的可能放开一些泛型约束,在Go 1.19估计不会如期兑现了。

不过可以确定的是Go 1.19将包含Go语法规范中的一处关于泛型的修正,即由下面表述:

The scope of an identifier denoting a type parameter of a function or declared by a method receiver is the function body and all parameter lists of the function.(译文:一个用于表示函数的类型参数或由方法接收器声明的类型参数的标识符的作用域范围包括函数体和函数的所有形式参数列表。)

改为下面更新版的表述:

The scope of an identifier denoting a type parameter of a function or declared by a method receiver starts after the function name and ends at the end of the function body.(译文:一个用于表示函数的类型参数或由方法接收器声明的类型参数的标识符的作用域始于函数名,终止于函数体末尾。)

这样一个改动,使得原本在当前版本Go编译器(Go 1.18.x)下编译报错的源码,在Go 1.19版本中可以正常编译通过:

type T[T any] struct {}
func (T[T]) m() {} // error: T is not a generic type

修订Go memory model

Go memory model是Go文档中最抽象的一篇,没有之一!随着Go的演进,原先的Go memory model描述有很多地方不够正式,也缺少对一些同步机制的说明,如atomic等。

这次修订,参考了Hans-J. Boehm和Sarita V. Adve在“Foundations of the C++ Concurrency Memory Model,(PLDI 2008)”中对C++ memory model的描述方式,对Go memory model做了更正式的整体描述,增加了对multiword竞态、runtime.SetFinalizer、更多sync类型、atomic操作以及编译器优化方面的描述。

修订go doc comment格式

Go内置了将comment直接提取为包文档的能力,这与其他语言通过第三方工具生成文档不同。go doc comment为Gopher提供了很大便利。但go doc comment设计于2009年,有些过时。对很多呈现形式的支持不够或缺少更为精确的格式描述,这次Russ Cox主导了go doc comment的修订,增加了对超链、列表、标题、标准库API引用等格式支持,修订后的go doc comment并非markdown语法,但从markdown语法中做了借鉴,同时兼容老comment格式。下面是Russ Cox提供的一些新doc comment的渲染后的效果图:



同时,Go团队还提供了go/doc/comment包,gopher使用它可以轻松解析go doc comment。

runtime.SetMemoryLimit

在Go 1.19中,一个新的runtime.SetMemoryLimit函数以及一个GOMEMLIMIT环境变量被引入。有了这个memory软限制,Go运行时将通过限制堆的大小,以及更积极地将内存返回给底层os,来试图维持这个内存限制,以尽量避免Go程序因分配heap过多,超出系统内存资源限制而被kill。

默认memory limit是math.MaxInt64。一旦通过SetMemoryLimit自行设定limit,那么Go运行时将尊重这个memory limit,通过调整GC回收频率以及及时将内存返还给os来保证go运行时掌控的内存总size在limit之下。

注意:limit限制的是go runtime掌控的内存总量,对于开发者自行从os申请的内存(比如通过mmap)则不予考虑。limit的具体措施细节可以参考该proposal design文档

另外要注意的是:该limit不能100%消除out-of-memory的情况。

Go 1.19在启动时将默认提高打开文件的限值

经调查,一些系统对打开的文件数量设置了一个人为的soft限制, 主要是为了与使用select和其硬编码的最大文件描述符(由 fd_set 的大小限制)的代码兼容。通常限制为1024,有的更小,比如256。这样即便是gofmt这样的简单程序,当它们并行地遍历一个文件树时,也很容易遇到打开文件描述符超量的错误。

Go不使用select,所以它不应该受这些限制的影响。于是对于导入os包的go程序,Go将在1.19中默认提高这些限制值到hard limit。

Go 1.19 race detector将升级到v3版thread sanitizer

升级后的新版race detector的race检测性能相对于上一版将提升1.5倍-2倍,内存开销减半,并且没有对goroutine的数量的上限限制。

注:thread sanitizer检测数据竞态的工作原理:记录每一个内存访问的信息,并检测线程对这块内存的访问是否存在竞争。基于这种原理,我们也可以知道一旦开启race detect,Go程序的执行效率将受到很大影响,运行的开销将大幅增加。v3版thread sanitizer虽然得到了优化,但对程序的总体影响还是存在的并且依旧很大。

Go 1.19增加”unix” build tag

Go 1.19将增加”unix”构建标签:

//go:build unix

等价于

//go:build aix || linux || darwin || dragonfly || freebsd || openbsd || netbsd || solaris

不过要注意,”*_unix.go”还保留原语义,不能被识别,以便向后兼容现有文件,尤其是go标准库之外的使用

标准库的一些变化

net软件包将使用EDNS

在Go 1.19中,net软件包将使用EDNS来增加DNS数据包的大小,以遵守现代DNS标准和实现。这应该有助于解决一些DNS服务器的问题。

flag包增加TextVar函数

Go flag包增加TextVar函数,这样flag包便可以与任何实现了encoding.Text{Marshaler,Unmarshaler}的Go类型集成。比如:

flag.TextVar(&ipaddr, "ipaddr", net.IPv4(192, 168, 0, 1), "what server to connect to?") // 与net.IPv4类型
flag.TextVar(&start, "start", time.Now(), "when should we start processing?") // 与time.Time类型

其它

  • 在linux上,Go正式支持64位龙芯cpu架构 (GOOS=linux, GOARCH=loong64)。
  • 当Go程序空闲时,Go GC进入到周期性的GC循环的情况下(2分钟一次),Go运行时现在会在idle的操作系统线程上安排更少的GC worker goroutine,减少空闲时Go应用对os资源的占用。
  • Go行时将根据goroutine的历史平均栈使用率来分配初始goroutine栈,避免了一些goroutine的最多2倍的goroutine栈空间浪费。
  • sync/atomic包增加了新的高级原子类型Bool, Int32, Int64, Uint32, Uint64, Uintptr和Pointer,提升了使用体验。
  • Go 1.19中Go编译器使用jump table重新实现了针对大整型数和string类型的switch语句,平均性能提升20%左右。

小结

相对于Go 1.18,Go 1.19的确是一个“小版本”。但Go 1.19对memory model的更新、SetMemoryLimit的加入、go doc comment的修订以及对go runtime的持续打磨依然可以让gopher们产生一丝丝“小兴奋”,尤其是SetMemoryLimit的加入,是否能改善Go应用因GC不及时被kill的情况呢,让我们拭目以待。

Go 1.19的里程碑在这里,所有feature和fix大家可以在该里程碑中看到。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats