• 欢迎来到小爱博客,一个分享互联网IT技术的网站,喜欢就收藏吧!

prometheus编写exporter

prometheus 小爱 2个月前 (08-29) 44次浏览 已收录 0个评论 扫描二维码

如果您要检测自己的代码,则应遵循有关如何使用Prometheus客户端库检测代码一般规则。当从另一个监视或仪器系统中获取度量标准时,事情往往不会那么黑与白。

本文档包含编写导出器或自定义收集器时应考虑的事项。涉及的理论也将对那些直接使用仪器的人感兴趣。

如果您正在编写导出程序,并且不清楚此处的内容,请通过IRC(Freenode上的#prometheus)或邮件列表与我们联系

可维护性和纯度

编写导出程序时,您需要做出的主要决定是,您愿意投入多少工作才能从中获得完美的指标。

如果所讨论的系统仅具有少量很少更改的指标,那么使一切都变得完美是一个简单的选择,HAProxy导出器就是一个很好的例子。

另一方面,如果您试图在系统具有数百个随新版本而频繁更改的度量标准时使事情变得完美,那么您已经为许多正在进行的工作注册了自己。在MySQL的出口是在光谱的这一端。

节点出口是这些的组合,与由模块的复杂性而变化。例如, mdadm收集器手动解析文件并公开专门为该收集器创建的指标,因此我们也可以正确获取指标。对于meminfo收集器而言,结果因内核版本而异,因此我们最终仅进行了足够的转换即可创建有效的指标。

组态

使用应用程序时,您应该针对不需要用户自定义配置的导出程序,而无需告诉应用程序在哪里。如果某些指标在大型设置中可能过于精细和昂贵,则可能还需要提供过滤这些指标的功能,例如,HAProxy导出器允许按服务器统计信息的过滤。同样,默认情况下可能会禁用昂贵的指标。

与其他监视系统,框架和协议配合使用时,您通常需要提供其他配置或自定义,以生成适用于Prometheus的指标。在最佳情况下,监视系统具有与Prometheus类似的数据模型,您可以自动确定如何转换指标。Cloudwatch, SNMP和 Collected就是这种情况。最多,我们需要能够让用户选择他们想要提取的指标的能力。

在其他情况下,取决于系统和基础应用程序的使用情况,来自系统的度量标准完全是非标准的。在这种情况下,用户必须告诉我们如何转换指标。该JMX出口是最明显的案例,用 石墨和 StatsD出口商也需要配置提取标签。

建议确保出口商无需配置即可开箱即用,并建议在需要时提供一些示例配置供转换。

YAML是标准的Prometheus配置格式,默认情况下,所有配置都应使用YAML。

指标

命名

遵循度量标准命名最佳做法

通常,度量标准名称应允许熟悉Prometheus而不是特定系统的人很好地猜测度量标准的含义。名为的度量标准http_requests_total不是很有用-是在传入,过滤器中或到达用户代码时对其进行测量吗?而且requests_total更糟糕的,要求的是什么类型?

通过直接检测,给定的度量标准应该恰好存在于一个文件中。因此,在出口商和收集商中,一个度量标准应该恰好适用于一个子系统并相应地命名。

除编写自定义收集器或导出器时外,永远不要以程序方式生成度量标准名称。

应用程序的度量标准名称通常应以出口者名称为前缀,例如haproxy_up

指标必须使用基本单位(例如,秒,字节),并保留将其转换为图形工具更易读的内容。无论最终使用什么单位,度量标准名称中的单位都必须与使用中的单位匹配。同样,显示比率,而不是百分比。更好的是,为比率的两个分量中的每个分量指定一个计数器。

度量标准名称不应包含导出时所使用的标签,例如by_type,因为如果将标签汇总在一起,则没有意义。

一个例外是,当您通过多个指标导出带有不同标签的相同数据时,在这种情况下,这通常是区分它们的最明智的方法。对于直接检测,仅当导出带有所有标签的单个度量标准的基数过高时,才应该出现这种情况。

Prometheus度量标准和标签名称用编写snake_case。转换camelCasesnake_case是可取的,但这样做会自动并不总是产生的东西像好的结果 myTCPExample还是isNaN如此,有时,最好给他们留下原样。

暴露的指标不应包含冒号,保留这些冒号供用户定义的记录规则在聚合时使用。

[a-zA-Z0-9:_]在度量标准名称中有效,任何其他字符都应清除为下划线。

_sum_count_bucket_total后缀由摘要,柱状图和计数器使用。除非您要制作其中之一,否则请避免使用这些后缀。

_total 是计数器的约定,如果使用COUNTER类型,则应使用它。

process_scrape_前缀被保留。如果它们遵循匹配的语义,可以在这些前缀上添加自己的前缀。例如,普罗米修斯(Prometheus)scrape_duration_seconds花费了多长时间才能获得报废,因此,最好还有一个以出口商为中心的指标,例如jmx_scrape_duration_seconds,说出特定出口商花费多长时间来完成任务。对于可以访问PID的流程统计信息,Go和Python都提供了收集器来为您处理。HAProxy导出器就是一个很好的例子。

当请求计数成功且请求计数失败时,公开此数据的最佳方法是将请求总数作为一个度量标准,将失败请求作为另一个度量标准。这使得计算故障率变得容易。不要使用带有失败或成功标签的度量标准。同样,对于缓存命中或未命中,最好有一个指标作为总指标,而另一个指标为命中指标。

考虑使用监视的人将对度量名称进行代码或网络搜索的可能性。如果名称建立得很好,并且不太可能在习惯使用这些名称的人员(例如SNMP和网络工程师)的领域之外使用,那么将它们保持原样可能是个好主意。这种逻辑并不适用于所有导出器,例如,MySQL导出器度量标准可能被各种人使用,而不仅仅是DBA。一个HELP与原来的名称字符串可以提供大部分相同的好处使用原来的名字。

标签

阅读标签上的一般建议

避免将其type作为标签名称使用,因为它太笼统且通常没有意义。你也应该尝试尽可能地避免有可能与目标的标签,如发生冲突的名称regionzonecluster, availability_zoneazdatacenterdcownercustomer, stageserviceenvironmentenv。但是,如果那是应用程序调用的某些资源,则最好不要通过重命名而引起混乱。

避免仅仅因为它们共享前缀就将它们放到一个度量中的诱惑。除非您确定某一项指标有意义,否则多个指标会更安全。

该标签le对于直方图和quantile摘要具有特殊含义。通常避免使用这些标签。

最好将读/写和发送/接收作为单独的指标,而不是作为标签。这通常是因为您一次只关心其中一个,并且使用这种方式更容易。

经验法则是,一个指标在求和或求平均值时应该有意义。导出器还有另外一种情况,那就是数据从根本上呈表格格式,否则,用户将需要对度量标准名称进行正则表达式才能使用。考虑一下主板上的电压传感器,尽管对它们进行数学运算是没有意义的,但将它们设置为一个度量而不是每个传感器具有一个度量是有意义的。度量标准内的所有值都应(几乎)始终具有相同的单位,例如,请考虑是否将风扇速度与电压混合在一起,并且您无法自动将它们分开。

不要这样做:

my_metric {label = a} 1
my_metric {label = b} 6
my_metric {label = total} 7

或这个:

my_metric {label = a} 1
my_metric {label = b} 6
my_metric {} 7

前者适合那些sum()超过您的指标的人,而后者则适合和,很难与您合作。某些客户端库(例如Go)会主动尝试阻止您在自定义收集器中执行后者,而所有客户端库都应阻止您使用直接检测来执行后者。永远不要做任何一个,而要依靠Prometheus聚合。

如果您的监控显示了这样的总数,请删除总数。如果由于某种原因必须保留它,例如,总计中包括未单独计数的内容,请使用不同的度量标准名称。

仪器标签应尽量少,每增加一个标签,用户在编写PromQL时就需要考虑一个标签。因此,请避免使用可以在不影响时间序列唯一性的情况下删除的仪器标签。可以通过信息指标添加有关指标的其他信息,例如,请参见下面的示例如何处理版本号。

但是,在某些情况下,预计指标的几乎所有用户都需要附加信息。如果是这样,添加非唯一标签而不是信息度量标准是正确的解决方案。例如, mysqld_exporter的 mysqld_perf_schema_events_statements_totaldigest标签是全查询模式的散列和就足够了唯一性。但是,如果没有人类可读的digest_text标签,该标签就没什么用了,长时间的查询将只包含查询模式的开始,因此不是唯一的。因此,我们最终得到了digest_text人类的digest标签和独特性的标签。

目标标签,而非静态刮擦标签

如果您发现自己想对所有指标应用相同的标签,请停止。

通常有两种情况。

第一个是对于某些标签,将其包含在度量标准(例如软件的版本号)上将很有用。相反,请使用https://www.robustperception.io/how-to-have-labels-for-machine-roles/中描述的方法 。

第二种情况是标签实际上是目标标签。这些是区域,群集名称等之类的东西,它们来自基础结构设置而不是应用程序本身。应用程序并不是要说它适合您的标签分类法,而是让运行Prometheus服务器的人进行配置,并且监视同一应用程序的不同人员可能会给它使用不同的名称。

因此,这些标签通过您使用的任何服务发现都属于Prometheus的scrape配置中。也可以在这里应用机器角色的概念,因为这对于至少某些人来说可能是有用的信息。

种类

您应该尝试将指标的类型与Prometheus类型进行匹配。这通常意味着计数器和仪表。该_count_sum 总结的也比较常见,有时你会看到位数。直方图很少见,如果您遇到一个问题,请记住,博览会格式会公开累积值。

通常,度量的类型并不明显,尤其是当您自动处理一组度量时。通常UNTYPED 是安全的默认设置。

计数器不会下降,因此,如果您有一个来自其他可以递减的仪表系统的计数器类型,例如Dropwizard指标,则它不是计数器,而是一个量表。UNTYPED最好是在那里使用的最佳类型,GAUGE如果将其用作计数器会产生误导。

帮助字符串

当您转换指标时,用户能够追溯到原始内容以及导致转换的规则是有用的。在收集器或导出器的名称中输入所应用的任何规则的ID,并将原始度量的名称和详细信息放入帮助字符串中,将极大地帮助用户。

Prometheus不喜欢一种具有不同帮助字符串的指标。如果您要从多个指标中选择一个指标,请选择其中一个指标以放入帮助字符串。

例如,SNMP导出器使用OID,而JMX导出器将输入示例mBean名称。该HAProxy的出口有手写的字符串。的节点出口也有各种各样的实施例。

减少有用的统计数据

mean除最小,最大和标准偏差外,某些仪器系统还显示自应用程序开始以来的1m,5m,15m速率,平均速率(例如,在Dropwizard度量标准中称为“平均速率” )。

这些都应该删除,因为它们不是很有用,并且会增加混乱。普罗米修斯可以自己计算利率,并且通常更准确,因为所暴露的平均值通常呈指数衰减。您不知道计算最小值或最大值的时间,标准偏差在统计上是无用的,并且始终可以公开平方和,_sum以及_count是否需要计算平方 和。

分位数有相关问题,您可以选择删除或将其放在摘要中。

虚线

许多监视系统没有标签,而是执行 my.class.path.mymetric.labelvalue1.labelvalue2.labelvalue3

石墨和 StatsD出口商分享一个小配置语言转换这些的一种方式。其他出口商应实施相同的规定。该转换目前仅在Go中实现,并且将从分解成一个单独的库中受益。

收藏家

为出口商实施收集器时,切勿使用通常的直接检测方法,然后在每个刮板上更新指标。

而是每次都创建新的指标。在Go中,这是通过 您的方法中的MustNewConstMetric完成的 Collect()。对于Python,请参见 https://github.com/prometheus/client_python#custom-collectors ;对于Java List<MetricFamilySamples>,请在您的collect方法中生成, 有关示例,请参见 StandardExports.java

其原因有两个。首先,可能同时发生两次刮擦,并且直接检测使用的是有效的文件级全局变量,因此您将获得竞争条件。其次,如果标签值消失了,它将仍然被导出。

可以通过直接检测对出口商本身进行检测,例如,传输的总字节数或出口商在所有报废中执行的调用。对于不与单个目标捆绑在一起的出口商(例如黑盒出口商SMNP出口商),这些出口商仅应公开征求意见,而不应 /metrics刮擦某个特定目标。

有关刮擦本身的指标

有时,您希望导出有关抓取的指标,例如花费了多长时间或处理了多少条记录。

这些应该作为事件,刮擦和以出口商名称为前缀的度量标准名称的形式公开显示 jmx_scrape_duration_seconds。通常将_exporter排除在外,如果导出程序也可以用作收集器,则一定要排除它。

机器和过程指标

许多系统(例如Elasticsearch)都公开机器指标,例如CPU,内存和文件系统信息。当节点导出器在Prometheus生态系统中提供这些功能时,应删除此类指标。

在Java世界中,许多检测框架都公开进程级别和JVM级别的统计信息,例如CPU和GC。Java客户端和JMX导出器已经通过DefaultExports.java以首选形式包含了它们 ,因此也应该删除它们。

与其他语言和框架类似。

部署方式

每个出口商都应该准确地监视一个实例应用程序,最好直接坐在同一台机器上。这意味着您为运行的每个HAProxy运行一个haproxy_exporter进程。对于装有Mesos工作程序的每台计算机,您都在上面运行Mesos导出程序,如果主计算机同时运行,则在主服务器上运行。

这背后的理论是,对于直接检测,这就是您要做的,并且我们正在尝试与其他布局尽可能接近。这意味着所有服务发现都在Prometheus中完成,而不是在出口商中完成。这还有一个好处,就是Prometheus拥有允许用户使用黑盒导出程序探查您的服务所需的目标信息。

有两个例外:

第一个是在应用程序旁边运行时,您的监视完全没有意义。SNMP,黑盒和IPMI导出器是其中的主要示例。作为设备的IPMI和SNMP导出器通常是黑盒,无法在其上运行代码(尽管如果可以在它们上运行节点导出器则更好),而黑盒导出器则在其中监视诸如DNS名称,也没有任何内容可运行。在这种情况下,Prometheus仍应进行服务发现,并将要刮除的目标传递出去。有关示例,请参见黑盒和SNMP导出器。

请注意,目前只有使用Go,Python和Java客户端库编写这种类型的导出程序。

第二个例外是,您要从系统的随机实例中提取一些统计信息,而不必在意与之交谈的那个。考虑要对数据运行一些业务查询然后导出的一组MySQL副本。让出口商使用您通常的负载平衡方法与一个副本进行对话是最明智的方法。

当您监视具有主选举功能的系统时,此方法不适用,在这种情况下,您应该分别监视每个实例并处理Prometheus中的“控制权”。这是因为并不总是只有一个大师,改变普罗米修斯脚下的目标会引起奇怪。

排程

仅当Prometheus抓取度量标准时才将其从应用程序中拉出,出口商不应根据自己的计时器执行度量标准。也就是说,所有刮擦应该是同步的。

因此,您不应在公开的指标上设置时间戳,让Prometheus来处理。如果您认为需要时间戳记,则可能需要使用 Pushgateway 。

如果度量的检索成本特别高,即花费超过一分钟,则可以对其进行缓存。这应该在HELP字符串中注明 。

Prometheus的默认刮擦超时为10秒。如果可以预期出口商会超过此数量,则应在用户文档中明确指出这一点。

推入

某些应用程序和监视系统仅推送指标,例如StatsD,Graphite和Collected。

这里有两个注意事项。

首先,您何时使指标过期?收集到的信息以及与Graphite进行对话的信息均会定期导出,并且当它们停止时,我们希望停止公开指标。收集的包含到期时间,因此我们可以使用它,而Graphite则不是,因此它是出口商的标志。

StatsD有点不同,因为它处理事件而不是度量。最好的模型是在每个应用程序旁边运行一个导出器,并在应用程序重新启动时重新启动它们,以便清除状态。

其次,这类系统倾向于允许您的用户发送增量或原始计数器。您应该尽可能地依赖原始计数器,因为这是常规的Prometheus模型。

对于服务级别的指标,例如服务级别的批处理作业,您应该让导出程序推入Pushgateway并在事件发生后退出,而不是自己处理状态。对于实例级别的批次指标,尚无明确的模式。这些选项要么是滥用节点导出器的文本文件收集器,要么是依赖于内存中状态(如果您不需要在重新引导后继续运行,则可能是最好的选择),或者实现与文本文件收集器类似的功能。

刮擦失败

当前有两种刮刮失败模式,您正在与之交谈的应用程序没有响应或出现其他问题。

第一种是返回5xx错误。

第二个是要具有myexporter_up例如haproxy_up变量,其值取决于刮擦是否起作用,值为0或1。

后者更好,即使刮擦失败,您仍然可以获得一些有用的指标,例如提供过程统计信息的HAProxy导出程序。up尽管您无法区分导出器和应用程序都处于关闭状态,但前者通常可以以一种通常的方式使用户更容易处理 。

登陆页面

如果访问时http://yourexporter/有一个简单的带有导出器名称的HTML页面以及指向该/metrics 页面的链接,则对用户来说更好。

端口号

一个用户可能在同一台计算机上有许多导出器和Prometheus组件,因此,使每个导出器和Prometheus组件具有唯一的端口号变得更加容易。

https://github.com/prometheus/prometheus/wiki/Default-port-allocations 是我们跟踪它们的地方,这是可公开编辑的。

开发出口商时,最好在公开宣布之前,获取下一个免费端口号。如果您尚未准备好发布,则可以输入用户名和WIP。

这是一个注册表,它使我们的用户的生活更加轻松,而不是致力于发展特定的出口商。对于内部应用程序的导出器,我们建议使用默认端口分配范围之外的端口。

宣布

准备好向世界宣布您的出口商之后,请向邮件列表发送电子邮件,然后发送PR以将其添加到可用出口商列表中


小爱博客 , 版权所有
转载请注明原文链接:prometheus编写exporter
喜欢 (0)
【你的支持, 我的动力】
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址