尧图网站建设 
Telegraf Prometheus 文本格式解析器Parser完整指南配置、数据模型与源码原理【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegrafPrometheus Text-Based Format Parser 是 Telegraf 内置的数据解析器用于将 Prometheus 文本暴露格式 的 README、源码实现与测试用例讲解该解析器的配置方法、v1/v2 两种指标版本的数据模型差异、时间戳处理规则以及底层解码流程帮助你正确接入 Prometheus 生态数据。解析器概述从 Prometheus 指标到 Telegraf MetricPrometheus 解析器本身没有任何独立的配置参数它读取 Prometheus 文本格式的指标数据直接映射为 Telegraf 的telegraf.Metric。其典型使用场景有两个在 prometheus 输入插件 内部使用负责解析抓取到的/metrics响应体在 http_listener_v2 输入插件 中使用data_format prometheus让 Telegraf 充当一个 Pushgateway接收客户端通过 HTTP Push 过来的 Prometheus 格式数据。从源码看解析器在 parser.go 中通过AcceptsContent函数基于 HTTP 响应头expfmt.ResponseFormat判断内容类型并依赖 Prometheus 官方库github.com/prometheus/common/expfmt完成底层解码——因此它天然兼容 Prometheus 生态的文本格式与 protobufdelimited编码格式。配置方法与参数说明最小可用配置在任意支持data_format的输入插件中将data_format设为prometheus即可启用[[inputs.file]] files [example] ## Data format to consume. ## Each data format has its own unique set of configuration options, read ## more about them here: ## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md data_format prometheus仓库测试用例 testcases/valid_gauge/telegraf.conf 给出了同样的最小配置形态配合input.txt即可验证解析行为。两个可选配置项尽管 README 中声明没有额外配置选项但当前源码 parser.go 实际支持两个通过 TOML 注入的选项配置项TOML 字段默认值作用prometheus_ignore_timestampIgnoreTimestampfalse为true时忽略输入数据自带的时间戳使用解析时刻作为指标时间prometheus_metric_versionMetricVersion0等效 v2指定指标映射版本0或2为 v21为 v1例如 testcases/ignore_timestamp/telegraf.conf[[inputs.test]] files [input.txt] data_format prometheus prometheus_ignore_timestamp true若在配置中传入非法版本号Parse会返回错误unknown prometheus metric version %d见 parser.go。通过 Header 指定编码格式protobuf 场景当使用http_listener_v2模拟 Pushgateway或通过带headers参数的输入接收数据时解析器会根据 HTTP 响应头Content-Type自动选择解码格式。测试用例 testcases/protobuf/telegraf.conf 展示了如何声明 protobuf delimited 编码[[inputs.test]] files [input.bin] data_format prometheus [inputs.test.additional_params] headers {Content-Type application/vnd.google.protobuf;protoio.prometheus.client.MetricFamily;encodingdelimited}对应源码逻辑在 parser.go当 Header 非空时通过expfmt.ResponseFormat判断格式对TypeProtoText/TypeProtoCompact做换行规整后回退到文本格式解码对未知类型仅记录 Debug 日志并继续尝试。解码流程与底层调用链Parser.Parse的完整流程parser.go如下依据p.Header选择格式默认expfmt.TypeTextPlain使用expfmt.NewDecoder创建解码器逐条解码dto.MetricFamilyPrometheus 的 protobuf 数据模型根据MetricVersion分发到extractMetricsV1metric_v1.go或extractMetricsV2metric_v2.go遇到io.EOF结束循环其余错误包装为decoding response failed: %w返回。ParseLineparser.go则要求单行数据恰好产生一个指标用于逐行处理场景。标签labels转换与类型映射分别由 common.go 中的getTagsFromLabelslabels 变为 tags空值标签被跳过并可与默认标签合并与mapValueTypeCOUNTER→Counter、GAUGE→Gauge、SUMMARY→Summary、HISTOGRAM→Histogram其余为Untyped实现。指标版本 v1 与 v2 的差异这是使用该解析器时最重要的决策点两种版本对同一输入产出完全不同的 Telegraf 指标结构。v1以原始指标名为 measurement多字段聚合extractMetricsV1为每个 Prometheus metric 生成一条 Telegraf 指标measurement 保持原始 Prometheus 指标名Gauge / Counter / Untyped字段名为gauge、counter或value值为数值NaN 值会被过滤见 metric_v1.goSummary字段包括count、sum以及每个分位点字段名为分位数值如0.5Histogram字段包括count、sum以及每个 bucket 上界字段名为le值如125000。以 valid_histogram/expected_v1.out 为例apiserver_request_latencies,_typehistogram,resourcebindings,verbPOST Inf2025,1250001994,1e062005,2500001997,2e062012,4e062017,5000002000,8e062024,count2025,sum102726334v2统一 measurement 为 prometheus一字段一指标extractMetricsV2将 measurement 统一为prometheus每条指标只含一个字段字段名即原始指标名Gauge / Counter / Untyped生成prometheusmeasurement字段{原始指标名}值Summary首先生成含{name}_count、{name}_sum的汇总指标再为每个分位点生成带quantile标签的指标Histogram首先生成含{name}_count、{name}_sum的汇总指标再为每个 bucket 生成带le标签、字段名为{name}_bucket的指标。以 valid_histogram/expected_v2.out 为例prometheus,_typehistogram,resourcebindings,verbPOST apiserver_request_latencies_count2025,apiserver_request_latencies_sum102726334 prometheus,_typehistogram,le125000,resourcebindings,verbPOST apiserver_request_latencies_bucket1994 prometheus,_typehistogram,leInf,resourcebindings,verbPOST apiserver_request_latencies_bucket2025而 valid_summary/expected_v2.out 则清晰展示了 summary 的分位点展开方式prometheus,_typesummary,handlerprometheus http_request_duration_microseconds_count9,http_request_duration_microseconds_sum18909097.205 prometheus,_typesummary,handlerprometheus,quantile0.5 http_request_duration_microseconds552048.506 prometheus,_typesummary,handlerprometheus,quantile0.99 http_request_duration_microseconds5876804.288v2 还有两个值得注意的行为metric_v2.goInfinity bucket 补全若输入 Histogram 缺少Inf上界的 bucketv2 会自动补一条leInf、值为总样本数的 bucket 指标以满足 Prometheus histogram 对 Inf bucket 的约定NaN 过滤值为 NaN 的指标会被整体跳过。如何选择版本若下游要求 measurement 与 Prometheus 指标名一致、希望字段聚合展示选用 v1prometheus_metric_version 1若希望保持一指标一字段的扁平结构、便于与 Prometheus 语义一一对应尤其用于 Histogram/Summary 的存储查询选用 v2默认即prometheus_metric_version 2或0。解析器测试 parser_test.go 会针对testcases下每个场景同时以 v1、v2 两种版本运行并比对预期输出expected_v1.out/expected_v2.out是观察两者差异的最佳素材。时间戳处理规则Prometheus 文本格式中指标行可携带毫秒级时间戳例如 metric_with_timestamp/input.txt# TYPE test_counter counter test_counter{labeltest} 1 1601830800000源码中的处理规则metric_v1.go 与 metric_v2.go 一致指标自带时间戳TimestampMs 0且IgnoreTimestamp为false时通过time.UnixMilli(ts)将毫秒时间戳还原为指标时间否则使用p.timeFunc()默认time.Now可通过SetTimeFunc注入见 parser.go作为当前时间。设置prometheus_ignore_timestamp true后所有指标统一使用本地采集时间。测试 parser_test.go 还会专门校验忽略时间戳后产出的指标时间晚于输入中的原始时间戳。默认标签合并解析器支持通过SetDefaultTagsparser.go注入默认标签与输入数据中的 labels 合并为 tags当某个默认标签与输入 label 同名时输入值覆盖默认值见 common.go。测试用例 testcases/default_tags 演示了这一点[[inputs.test]] files [input.txt] data_format prometheus [inputs.test.default_tag_defs] defaultTag defaultTagValue dockerVersion to_be_overridden输入中自带dockerVersion1.8.2标签最终解析出的指标dockerVersion标签为1.8.2输入覆盖默认值而defaultTag则保留默认值defaultTagValue。实战场景用 http_listener_v2 模拟 Pushgateway在原文档描述的典型用法中http_listener_v2 Prometheus 解析器可以充当轻量 Pushgateway外部应用将指标以 Prometheus 文本格式 POST 到 Telegraf 监听端口Telegraf 解析后写入输出。启用方式与上文的data_format配置一致[[inputs.http_listener_v2]] ## Address and port to host HTTP listener on service_address :8080 ## Data format to consume. data_format prometheus抓取型场景则直接使用 prometheus 输入插件该插件内部即复用此解析器并负责通过 Header 传递抓取响应的Content-Type支撑文本与 protobuf 两种编码的自动识别。验证与测试仓库为解析器提供了丰富的验证资产测试用例目录plugins/parsers/prometheus/testcases覆盖 gauge、counter、histogram、summary、带时间戳、忽略时间戳、默认标签、protobuf 编码、缺失 Inf buckethistogram_inf_bucket等场景每个场景均含telegraf.conf、输入数据与expected_v1.out/expected_v2.out预期输出单元测试parser_test.go以两种 metric version 分别跑通全部测试目录并对忽略时间戳场景做时间先后断言基准测试parser_test.go提供BenchmarkParsingMetricVersion1/BenchmarkParsingMetricVersion2基于 testcases/benchmark/input.txt 数据评估两种版本的解析性能。如需在实际环境中复现可将上述任意测试目录中的输入文件内容放入本地文件再以对应的telegraf.conf通过telegraf --test运行验证输出。小结Prometheus 解析器以极简的data_format prometheus接入方式将 Prometheus 文本格式及 protobuf delimited 编码无缝桥接到 Telegraf 的指标模型。理解prometheus_metric_version的 v1/v2 差异、时间戳取舍规则与标签合并语义是正确设计采集管线的关键仓库内 parser.go、metric_v1.go、metric_v2.go 与 testcases 提供了从源码到预期输出的完整参考链。【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegraf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Telegraf Prometheus 文本格式解析器（Parser）完整指南：配置、数据模型与源码原理
Telegraf Prometheus 文本格式解析器Parser完整指南配置、数据模型与源码原理【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegrafPrometheus Text-Based Format Parser 是 Telegraf 内置的数据解析器用于将 Prometheus 文本暴露格式 的 README、源码实现与测试用例讲解该解析器的配置方法、v1/v2 两种指标版本的数据模型差异、时间戳处理规则以及底层解码流程帮助你正确接入 Prometheus 生态数据。解析器概述从 Prometheus 指标到 Telegraf MetricPrometheus 解析器本身没有任何独立的配置参数它读取 Prometheus 文本格式的指标数据直接映射为 Telegraf 的telegraf.Metric。其典型使用场景有两个在 prometheus 输入插件 内部使用负责解析抓取到的/metrics响应体在 http_listener_v2 输入插件 中使用data_format prometheus让 Telegraf 充当一个 Pushgateway接收客户端通过 HTTP Push 过来的 Prometheus 格式数据。从源码看解析器在 parser.go 中通过AcceptsContent函数基于 HTTP 响应头expfmt.ResponseFormat判断内容类型并依赖 Prometheus 官方库github.com/prometheus/common/expfmt完成底层解码——因此它天然兼容 Prometheus 生态的文本格式与 protobufdelimited编码格式。配置方法与参数说明最小可用配置在任意支持data_format的输入插件中将data_format设为prometheus即可启用[[inputs.file]] files [example] ## Data format to consume. ## Each data format has its own unique set of configuration options, read ## more about them here: ## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md data_format prometheus仓库测试用例 testcases/valid_gauge/telegraf.conf 给出了同样的最小配置形态配合input.txt即可验证解析行为。两个可选配置项尽管 README 中声明没有额外配置选项但当前源码 parser.go 实际支持两个通过 TOML 注入的选项配置项TOML 字段默认值作用prometheus_ignore_timestampIgnoreTimestampfalse为true时忽略输入数据自带的时间戳使用解析时刻作为指标时间prometheus_metric_versionMetricVersion0等效 v2指定指标映射版本0或2为 v21为 v1例如 testcases/ignore_timestamp/telegraf.conf[[inputs.test]] files [input.txt] data_format prometheus prometheus_ignore_timestamp true若在配置中传入非法版本号Parse会返回错误unknown prometheus metric version %d见 parser.go。通过 Header 指定编码格式protobuf 场景当使用http_listener_v2模拟 Pushgateway或通过带headers参数的输入接收数据时解析器会根据 HTTP 响应头Content-Type自动选择解码格式。测试用例 testcases/protobuf/telegraf.conf 展示了如何声明 protobuf delimited 编码[[inputs.test]] files [input.bin] data_format prometheus [inputs.test.additional_params] headers {Content-Type application/vnd.google.protobuf;protoio.prometheus.client.MetricFamily;encodingdelimited}对应源码逻辑在 parser.go当 Header 非空时通过expfmt.ResponseFormat判断格式对TypeProtoText/TypeProtoCompact做换行规整后回退到文本格式解码对未知类型仅记录 Debug 日志并继续尝试。解码流程与底层调用链Parser.Parse的完整流程parser.go如下依据p.Header选择格式默认expfmt.TypeTextPlain使用expfmt.NewDecoder创建解码器逐条解码dto.MetricFamilyPrometheus 的 protobuf 数据模型根据MetricVersion分发到extractMetricsV1metric_v1.go或extractMetricsV2metric_v2.go遇到io.EOF结束循环其余错误包装为decoding response failed: %w返回。ParseLineparser.go则要求单行数据恰好产生一个指标用于逐行处理场景。标签labels转换与类型映射分别由 common.go 中的getTagsFromLabelslabels 变为 tags空值标签被跳过并可与默认标签合并与mapValueTypeCOUNTER→Counter、GAUGE→Gauge、SUMMARY→Summary、HISTOGRAM→Histogram其余为Untyped实现。指标版本 v1 与 v2 的差异这是使用该解析器时最重要的决策点两种版本对同一输入产出完全不同的 Telegraf 指标结构。v1以原始指标名为 measurement多字段聚合extractMetricsV1为每个 Prometheus metric 生成一条 Telegraf 指标measurement 保持原始 Prometheus 指标名Gauge / Counter / Untyped字段名为gauge、counter或value值为数值NaN 值会被过滤见 metric_v1.goSummary字段包括count、sum以及每个分位点字段名为分位数值如0.5Histogram字段包括count、sum以及每个 bucket 上界字段名为le值如125000。以 valid_histogram/expected_v1.out 为例apiserver_request_latencies,_typehistogram,resourcebindings,verbPOST Inf2025,1250001994,1e062005,2500001997,2e062012,4e062017,5000002000,8e062024,count2025,sum102726334v2统一 measurement 为 prometheus一字段一指标extractMetricsV2将 measurement 统一为prometheus每条指标只含一个字段字段名即原始指标名Gauge / Counter / Untyped生成prometheusmeasurement字段{原始指标名}值Summary首先生成含{name}_count、{name}_sum的汇总指标再为每个分位点生成带quantile标签的指标Histogram首先生成含{name}_count、{name}_sum的汇总指标再为每个 bucket 生成带le标签、字段名为{name}_bucket的指标。以 valid_histogram/expected_v2.out 为例prometheus,_typehistogram,resourcebindings,verbPOST apiserver_request_latencies_count2025,apiserver_request_latencies_sum102726334 prometheus,_typehistogram,le125000,resourcebindings,verbPOST apiserver_request_latencies_bucket1994 prometheus,_typehistogram,leInf,resourcebindings,verbPOST apiserver_request_latencies_bucket2025而 valid_summary/expected_v2.out 则清晰展示了 summary 的分位点展开方式prometheus,_typesummary,handlerprometheus http_request_duration_microseconds_count9,http_request_duration_microseconds_sum18909097.205 prometheus,_typesummary,handlerprometheus,quantile0.5 http_request_duration_microseconds552048.506 prometheus,_typesummary,handlerprometheus,quantile0.99 http_request_duration_microseconds5876804.288v2 还有两个值得注意的行为metric_v2.goInfinity bucket 补全若输入 Histogram 缺少Inf上界的 bucketv2 会自动补一条leInf、值为总样本数的 bucket 指标以满足 Prometheus histogram 对 Inf bucket 的约定NaN 过滤值为 NaN 的指标会被整体跳过。如何选择版本若下游要求 measurement 与 Prometheus 指标名一致、希望字段聚合展示选用 v1prometheus_metric_version 1若希望保持一指标一字段的扁平结构、便于与 Prometheus 语义一一对应尤其用于 Histogram/Summary 的存储查询选用 v2默认即prometheus_metric_version 2或0。解析器测试 parser_test.go 会针对testcases下每个场景同时以 v1、v2 两种版本运行并比对预期输出expected_v1.out/expected_v2.out是观察两者差异的最佳素材。时间戳处理规则Prometheus 文本格式中指标行可携带毫秒级时间戳例如 metric_with_timestamp/input.txt# TYPE test_counter counter test_counter{labeltest} 1 1601830800000源码中的处理规则metric_v1.go 与 metric_v2.go 一致指标自带时间戳TimestampMs 0且IgnoreTimestamp为false时通过time.UnixMilli(ts)将毫秒时间戳还原为指标时间否则使用p.timeFunc()默认time.Now可通过SetTimeFunc注入见 parser.go作为当前时间。设置prometheus_ignore_timestamp true后所有指标统一使用本地采集时间。测试 parser_test.go 还会专门校验忽略时间戳后产出的指标时间晚于输入中的原始时间戳。默认标签合并解析器支持通过SetDefaultTagsparser.go注入默认标签与输入数据中的 labels 合并为 tags当某个默认标签与输入 label 同名时输入值覆盖默认值见 common.go。测试用例 testcases/default_tags 演示了这一点[[inputs.test]] files [input.txt] data_format prometheus [inputs.test.default_tag_defs] defaultTag defaultTagValue dockerVersion to_be_overridden输入中自带dockerVersion1.8.2标签最终解析出的指标dockerVersion标签为1.8.2输入覆盖默认值而defaultTag则保留默认值defaultTagValue。实战场景用 http_listener_v2 模拟 Pushgateway在原文档描述的典型用法中http_listener_v2 Prometheus 解析器可以充当轻量 Pushgateway外部应用将指标以 Prometheus 文本格式 POST 到 Telegraf 监听端口Telegraf 解析后写入输出。启用方式与上文的data_format配置一致[[inputs.http_listener_v2]] ## Address and port to host HTTP listener on service_address :8080 ## Data format to consume. data_format prometheus抓取型场景则直接使用 prometheus 输入插件该插件内部即复用此解析器并负责通过 Header 传递抓取响应的Content-Type支撑文本与 protobuf 两种编码的自动识别。验证与测试仓库为解析器提供了丰富的验证资产测试用例目录plugins/parsers/prometheus/testcases覆盖 gauge、counter、histogram、summary、带时间戳、忽略时间戳、默认标签、protobuf 编码、缺失 Inf buckethistogram_inf_bucket等场景每个场景均含telegraf.conf、输入数据与expected_v1.out/expected_v2.out预期输出单元测试parser_test.go以两种 metric version 分别跑通全部测试目录并对忽略时间戳场景做时间先后断言基准测试parser_test.go提供BenchmarkParsingMetricVersion1/BenchmarkParsingMetricVersion2基于 testcases/benchmark/input.txt 数据评估两种版本的解析性能。如需在实际环境中复现可将上述任意测试目录中的输入文件内容放入本地文件再以对应的telegraf.conf通过telegraf --test运行验证输出。小结Prometheus 解析器以极简的data_format prometheus接入方式将 Prometheus 文本格式及 protobuf delimited 编码无缝桥接到 Telegraf 的指标模型。理解prometheus_metric_version的 v1/v2 差异、时间戳取舍规则与标签合并语义是正确设计采集管线的关键仓库内 parser.go、metric_v1.go、metric_v2.go 与 testcases 提供了从源码到预期输出的完整参考链。【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegraf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考