Telegraf 输入数据格式Input Data Formats完全指南从 parser 注册表到 20 种解析器实战【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegrafTelegraf 的许多通用型输入插件如exec、file、kafka_consumer、tail、socket_listener等本身并不关心收到的字节流是什么样而是通过一个可配置的 parser解析器将任意输入数据转换为统一的 metric 模型。本文以仓库中的 docs/DATA_FORMATS_INPUT.md 为骨架结合 plugins/parsers 目录下的真实实现与各解析器 README系统讲解如何用data_format选择解析器、20 种内置格式的适用场景与核心配置、解析器插件的注册与加载机制以及选型与排错思路。读完本文你将掌握① 哪些输入插件支持data_format以及如何配置② 每一种输入数据格式的定位、关键参数与配置示例③ 从 plugins/parsers/registry.go 到 config/config.go 的解析器解析与装配链路④ 如何为自己的数据选对解析器并快速定位解析问题。一、解析器机制通用输入插件的可插拔数据消费层Telegraf 的核心设计之一是采集与解析分离输入插件负责获取原始数据读文件、订阅消息队列、监听端口、执行命令而数据格式的解析工作交给独立的 parser。这种解耦带来了极大的灵活性——例如 kafka_consumer 输入插件可以消费同一主题中的消息并按需以 InfluxDB Line Protocol、JSON、Avro 等任意格式解析。任何包含data_format配置项的输入插件都可以使用该选项来选择解析器。仓库中这类插件数量众多覆盖了文件file、命令exec、消息队列kafka_consumer、mqtt_consumer、amqp_consumer、网络监听socket_listener、http_listener_v2、influxdb_listener以及tail、statsd等场景。一个典型的配置如下取自 docs/DATA_FORMATS_INPUT.md[[inputs.exec]] ## Commands array commands [/tmp/test.sh, /usr/bin/mycollector --foobar] ## measurement name suffix (for separating different commands) name_suffix _mycollector ## Data format to consume. data_format json解析器从配置到实例的装配链路从源码结构看解析器通过一个全局注册表挂载见 plugins/parsers/registry.go// Creator is the function to create a new parser type Creator func(defaultMetricName string) telegraf.Parser // Parsers contains the registry of all known parsers (following the new style) var Parsers make(map[string]Creator) // Add adds a parser to the registry. Usually this function is called in the plugins init function func Add(name string, creator Creator) { Parsers[name] creator }每个解析器在自己的init()函数中调用parsers.Add(json, ...)之类的注册逻辑然后在配置加载阶段config/config.go框架读取输入插件表中的data_format字符串从parsers.Parsers注册表中找到对应的Creator工厂函数实例化出具体的telegraf.Parser并注入到输入插件中。data_format的值不区分大小写之外的任何附加语义直接作为注册表 key 使用。二、内置输入数据格式总览当前仓库的 plugins/parsers 目录下共包含 20 种输入解析器对应data_format的取值如下data_format取值解析器适用数据avroAvroApache Avro 序列化数据binaryBinary自定义二进制协议需配置编码规则collectdCollectdcollectd 网络协议二进制csvCSV逗号分隔的表格文本dropwizardDropwizardDropwizard 指标 JSONform_urlencodedForm URL Encoded表单编码的键值对a1b2graphiteGraphiteGraphite 纯文本协议grokGrok基于正则模板的日志行influxInfluxDB Line ProtocolInfluxDB 行协议jsonJSONJSON 对象 / 对象数组json_v2JSON v2基于路径精确提取的 JSONlogfmtLogfmtkeyvalue格式的日志行nagiosNagiosNagios 插件输出openmetricsOpenMetricsOpenMetrics 文本格式opentsdbOpenTSDBOpenTSDBtelnet/http写协议parquetParquetApache Parquet 列式文件prometheusPrometheusPrometheus 文本格式prometheusremotewritePrometheusRemoteWritePrometheus Remote Write 二进制valueValue单个裸值如45或booyahwavefrontWavefrontWavefront 文本格式xml/xpath_json/xpath_msgpack/xpath_protobuf/xpath_cborXPathXML、JSON、MessagePack、Protocol Buffers、CBOR通过 XPath 表达式提取说明上述data_format取值与 docs/DATA_FORMATS_INPUT.md 中的格式列表一一对应其中 XPath 一族在配置中用data_format xml等具体值区分底层数据格式。从 registry 到 all 包的无侵入注册解析器全部通过parsers.Add(name, creator)注册。为了控制二进制体积Telegraf 支持自定义构建custom builder是否导入某个解析器的init()由构建时决定——这也解释了为什么 plugins/parsers/all 目录中有一组聚合导入文件它们是默认构建时批量引入各解析器的总开关。三、最常用的文本格式解析器详解1. JSON把任意 JSON 结构摊平成 metricJSON 解析器把 JSON 对象或对象数组解析为 metric 字段见 plugins/parsers/json/README.md。关键行为所有 JSON 数字都会转换为 float 字段JSON 字符串与布尔值默认被忽略除非在tag_keys或json_string_fields中显式指定。核心配置项[[inputs.file]] files [example] data_format json ## 当 strict 为 true 且解析 JSON 数组时数组内所有对象必须合法 json_strict true ## GJSON 路径指定解析文档中的某个子块未指定则解析整个文档 json_query ## 应作为 tag 的 key 列表匹配到的 key 不再作为字段保存支持通配符 glob tag_keys [my_tag_1, my_tag_2, tags_*, tag*] ## 应作为字符串字段的 keyglob 模式或布尔 key json_string_fields [] ## 用作 measurement 名称的 key json_name_key ## 包含时间戳的 key需配合 json_time_format 使用 json_time_key json_time_format # unix / unix_ms / unix_us / unix_ns 或 Go 参考时间格式 json_timezone # 默认 UTC可填 Local 或 IANA 时区名json_query使用 GJSON 路径语法在任何其他选项之前先对文档做一次投影查询结果应是 JSON 对象或对象数组随后对投影结果执行常规解析。json_time_keyjson_time_format组合可以把文档内的时间戳变成 metric 时间时间格式可以是unix、unix_ms、unix_us、unix_ns或 Go 语言参考时间Mon Jan 2 15:04:05 MST 2006的排列形式。不带时区的时间按 UTC 处理可通过json_timezone改为Local或具体 IANA 时区。实战示例——利用json_name_key、tag_keys与json_string_fields[[inputs.file]] files [example] json_name_key name tag_keys [my_tag_1] json_string_fields [b_my_field] data_format json输入{ a: 5, b: {c: 6, my_field: description}, my_tag_1: foo, name: my_json }输出嵌套字段被展开为b_c等扁平名my_json,my_tag_1foo a5,b_c6,b_my_fielddescription数组与时间解析示例当 JSON 是数组时数组内每个对象都会按相同配置生成一条 metric配合json_time_key/json_time_format可逐条带上文档内时间[[inputs.file]] files [example] data_format json json_time_key b_time json_time_format 02 Jan 06 15:04 MST输入数组两条对象时输出大致为file a5,b_c6 1136387040000000000 file a7,b_c8 11685278400000000002. JSON v2面向复杂 JSON 的路径式精确提取当 JSON 结构嵌套深、字段名不固定或只需提取部分字段时使用 JSON v2。它通过[[inputs.file.json_v2]]子表逐字段声明提取路径、类型与时间适合对数据形状有强控制需求的场景。与 v1 的整体摊平 少量键指定思路不同v2 的每个字段、标签、时间都可由 JSONPath 表达式显式定义。3. CSV表格式数据的行列映射CSV 解析器 将含逗号分隔值的文档解析为 metric每一行生成一条 metric列作为字段字段类型根据内容自动推断。常用配置项[[inputs.file]] files [example] data_format csv csv_header_row_count 0 # 表头行数0 表示无表头首行即数据 csv_column_names [] # 自定义列名header_row_count0 时必填 csv_column_types [] # 显式列类型int / float / bool / string按列顺序给出 csv_skip_rows 0 # 解析表头前跳过的行数 csv_metadata_rows 0 # 表头前的元数据行数键值对默认作为 tag 加入 csv_metadata_separators [:, ] csv_metadata_trim_set # 元数据值的修剪字符集 csv_skip_columns 0 # 跳过开头 N 列表头同样跳过 csv_delimiter , # 字段分隔符 csv_comment # 注释行起始字符注释行整行跳过 csv_trim_space false # 是否去除字段前导空白 csv_tag_columns [] # 作为 tag 的列 csv_tag_overwrite false # 列 tag 是否覆盖元数据/默认 tag csv_measurement_column # 取 measurement 名的列该列不再作为字段 csv_timestamp_column # 取时间的列 csv_timestamp_format # 同 JSON 的时间格式规则unix* 或 Go 参考时间 csv_timezone # 无时区信息时的 IANA 时区 csv_skip_values [] # 命中这些值的字段整体跳过 csv_skip_errors false # 无法解析的行是否直接跳过 csv_reset_mode none # none / always是否每次调用都重置解析器状态多行表头与元数据csv_header_row_count 1时多行表头会逐行拼接列名csv_metadata_rows 0时表头前的若干行按csv_metadata_separators拆出(key, value)默认作为 tag 注入每条 metric若想转成字段可使用 converter 处理器。示例来自 plugins/parsers/csv/README.md[[inputs.file]] files [example] data_format csv csv_metadata_rows 2 csv_metadata_separators [:, ] csv_metadata_trim_set # csv_header_row_count 1 csv_tag_columns [Version,cpu] csv_timestamp_column time csv_timestamp_format 2006-01-02T15:04:05Z07:00输入# Version1.1 # File Created: 2021-11-17T07:02:4510:00 Version,measurement,cpu,time_user,time_system,time_idle,time 1.2,cpu,cpu0,42,42,42,2018-09-13T13:03:28Z输出cpu,cpucpu0,File\ Created2021-11-17T07:02:4510:00,Version1.1 time_user42,time_system42,time_idle42 1536869008000000000若将csv_tag_overwrite设为true列值1.2会覆盖元数据中的Version1.1。此外 CSV 解析器还支持通过 metric filtering 跳过特定列和行。4. Grok用正则模板解析任意日志行Grok 解析器 使用类 Logstash 的正则模板语言解析行分隔文本。模式语法为%{capture_syntax[:semantic_name][:modifier]}capture_syntax用于匹配输入的 grok 模式如NUMBER、COMMON_LOG_FORMATsemantic_name捕获结果对应的字段或 tag 名modifier控制数据类型转换或特殊处理。默认所有具名捕获都会变成字符串字段没有semantic_name的模式不会被捕获每行至少捕获一个字段。可用修饰符string默认、int、floatduration如5.23ms转为纳秒整数tag转成 tag、drop丢弃该字段measurement把匹配文本作为 measurement 名时间戳修饰符ts系列可把捕获内容作为 metric 时间若不解析时间则使用当前时间修饰符对应时间格式ts自动学习时间格式ts-ansicMon Jan _2 15:04:05 2006ts-unixMon Jan _2 15:04:05 MST 2006ts-rubyMon Jan 02 15:04:05 -0700 2006ts-rfc82202 Jan 06 15:04 MSTts-rfc822z02 Jan 06 15:04 -0700ts-rfc850Monday, 02-Jan-06 15:04:05 MSTts-rfc1123Mon, 02 Jan 2006 15:04:05 MSTts-rfc1123zMon, 02 Jan 2006 15:04:05 -0700ts-rfc33392006-01-02T15:04:05Z07:00ts-rfc3339nano2006-01-02T15:04:05.999999999Z07:00ts-httpd02/Jan/2006:15:04:05 -0700ts-epochUnix 秒可含小数ts-epochnanoUnix 纳秒ts-epochmilliUnix 毫秒ts-syslogJan 02 15:04:05年份取当前年ts-CUSTOM自定义布局基于 Go 参考时间需加引号例如%{TIMESTAMP:timestamp:ts-2006-01-02 15:04:05.000}可匹配2018-01-02 15:04:05,000用.匹配小数点。注意Go 正则不支持前瞻/后顾断言依赖这些特性的 Logstash 模式可能无法直接使用。Grok 配置示例[[inputs.file]] files [/var/log/apache/access.log] data_format grok ## 待匹配模式列表模式越多处理越慢单个模式效率最高 ## 常见内置模式%{COMMON_LOG_FORMAT}apache/nginx 访问日志、%{COMBINED_LOG_FORMAT} grok_patterns [%{COMBINED_LOG_FORMAT}] ## 自定义模式文件完整路径 grok_custom_pattern_files [] ## 也可以在这里逐行定义自定义模式 grok_custom_patterns ## 无时区信息时间戳的时区默认 UTC可填 Local 或 IANA 时区 grok_timezone Canada/Eastern ## 设为 disable 时重复时间戳不再递增 # grok_unique_timestamp auto ## 开启多行消息处理 # grok_multiline false自定义时间戳示例解析Wed Apr 12 13:10:34 PST 2017 value42[[inputs.file]] grok_patterns [%{TS_UNIX:timestamp:ts-unix} value%{NUMBER:value:int}] grok_custom_patterns TS_UNIX %{DAY} %{MONTH} %{MONTHDAY} %{HOUR}:%{MINUTE}:%{SECOND} %{TZ} %{YEAR} TOML 转义陷阱grok 语法本身需要转义如|是特殊字符TOML 字符串又要二次转义因此多层转义极易出错。官方建议能用多行字面量字符串就用它例如匹配|42|\uD83D\uDC2F|telegraf|可写成[[inputs.file]] grok_patterns [ \|%{NUMBER:value:int}\|%{UNICODE_ESCAPE:escape}\|%{WORD:name}\| ] grok_custom_patterns UNICODE_ESCAPE (?:\\u[0-9A-F]{4})模式调试与性能建议调试时可单独配置[[outputs.file]] files [stdout]并禁用其他输出从单行输入开始、一次只加一个 token 逐步验证。性能上避免使用%{DATA}这类永远能匹配的模式尽量给模式加^和$锚点如grok_patterns [^%{COMBINED_LOG_FORMAT}$]。5. Value解析单个裸值Value 解析器 处理一行就是一个值的输入例如45或booyah。典型场景是脚本或命令直接输出一个数字。它通常配合data_format value使用值会被放入默认字段中可通过输入插件的字段命名选项调整。6. InfluxDB Line ProtocolTelegraf 的母语Influx 解析器 使用 InfluxDB 行协议解析 metric。由于行协议是 Telegraf 的内部表示语言见 docs/METRICS.mdinflux是许多管道场景如kafka_consumer消费 Telegraf 序列化消息、influxdb_listener接收写入的默认选择。配置项[[inputs.file]] files [example] data_format influx ## internal 为默认解析器upstream 是更新、更快且更省内存的实现 # influx_parser_type internal ## 时间戳精度默认 1ns可设为 1s / 1ms / 1us # influx_timestamp_precision 1nsinflux_timestamp_precision用于声明输入数据的时间戳精度默认为纳秒1ns当上游输出的是秒、毫秒或微秒时间戳时必须显式指定否则时间会被错误放大或缩小。7. 更多面向特定生态的格式Graphiteplugins/parsers/graphite解析metric.path value timestamp纯文本协议适合直接接入现有 Graphite 数据流。Collectdplugins/parsers/collectd解析 collectd 二进制网络协议需要网络鉴权配置security_level、auth_file。OpenTSDBplugins/parsers/opentsdb支持telnet与http两种写协议格式。Nagiosplugins/parsers/nagios解析 Nagios 插件标准输出OK|WARNING|...与性能数据自动生成nagios_state等字段。Prometheus与OpenMetricsplugins/parsers/prometheus、plugins/parsers/openmetrics分别解析 Prometheus 文本格式与 OpenMetrics 文本格式可直接消费/metrics端点输出或抓取到的指标文本prometheusremotewrite则解析 Prometheus Remote Write 的 protobuf 二进制。Wavefrontplugins/parsers/wavefront解析 Wavefront 文本格式含 delta counter 支持。Logfmtplugins/parsers/logfmt解析keyvalue风格的结构化日志行。Form URL Encodedplugins/parsers/form_urlencoded解析a1b2表单编码数据。Dropwizardplugins/parsers/dropwizard解析 Dropwizard 指标 JSON支持json_query、tag_keys等类似 JSON 的配置。Binaryplugins/parsers/binary为自定义二进制协议提供声明式配置字节序、编码、位宽等。Avro与Parquetplugins/parsers/avro、plugins/parsers/parquet分别解析 Avro 二进制记录与 Parquet 列式文件适用于大数据生态的指标数据。四、XPath 一族XML / JSON / MessagePack / Protobuf / CBOR 的统一抽象XPath 解析器 用 XPath 表达式把多种数据格式统一映射为 metric 字段data_format的具体取值决定底层数据格式底层数据格式data_format取值XMLxmlJSONxpath_jsonMessagePackxpath_msgpackProtocol Buffersxpath_protobufCBORxpath_cbor字段类型由 XPath 转换函数number()、boolean()、string()指定唯一例外是整数字段必须写在fields_int子表中XPath 没有整数转换函数。Protocol Buffers 专属配置使用xpath_protobuf时必须指定xpath_protobuf_files必填.proto定义文件名列表xpath_protobuf_type必填顶层消息全限定名通常为package name.message namexpath_protobuf_import_paths可选import的其他.proto文件搜索路径默认只在当前工作目录.查找xpath_protobuf_skip_bytes可选跳过报文头部 N 字节再解析。已知场景GRPC 的 Length-Prefixed-Messages 需要跳 5 字节PowerDNS 日志消息有 2 字节长度头。示例[[inputs.file]] files [example.dat] data_format xpath_protobuf xpath_protobuf_files [A.proto] xpath_protobuf_type foo.Measurement xpath_protobuf_import_paths [., /data/my_proto_files] xpath_protobuf_skip_bytes 0CBOR 的数值键规则CBOR 支持数值键而 XML 要求节点名以字母开头因此解析器会把数值节点名前缀n并转成字符串CBOR 中的键123需用n123在 XPath 中查询。显式配置模式逐字段声明[[inputs.file]] files [example.xml] data_format xml # xpath_protobuf_files [sparkplug_b.proto] # xpath_protobuf_type org.eclipse.tahu.protobuf.Payload # xpath_protobuf_import_paths [.] # xpath_protobuf_skip_bytes 0 ## 调试以 debug 日志打印内部 XML 文档对非 XML 格式尤其有用 # xpath_print_document false ## 允许某个解析段落的结果为空 # xpath_allow_empty_selection false ## 对含类型信息的格式CBOR/protobuf/msgpack/JSON启用原生类型 # xpath_native_types false [[inputs.file.xpath]] # metric_selection /Bus/child::Sensor # metric_name string(example) # timestamp /Gateway/Timestamp # timestamp_format 2006-01-02T15:04:05Z # timezone UTC # fields_bytes_as_hex [] # fields_bytes_as_base64 [] [inputs.file.xpath.tags] name substring-after(Sensor/name, ) device string(the ultimate sensor) [inputs.file.xpath.fields_int] consumers Variable/consumers [inputs.file.xpath.fields] temperature number(Variable/temperature) power number(Variable/power) frequency number(Variable/frequency) ok Mode ! ok要点metric_selection可选用 XPath 选中一组节点每个节点生成一条 metric后续相对查询都以选中节点为基准绝对路径需以/开头不指定时相对查询以文档根节点为基准。metric_name可选用查询结果覆盖 measurement 名。timestamp/timestamp_format/timezone可选默认使用当前时间timestamp_format可取unix、unix_ms、unix_us、unix_ns或 Go 参考时间格式缺省按unix秒处理timezone用于给无时区信息的时间定位时区含时区偏移的格式如 RFC3339 不受影响unix 系列格式忽略该设置。tags子表tag名 XPath查询查询结果一律转成字符串。fields_int子表查询结果必须可转为 int64否则转换失败。fields子表类型由查询中的number()/boolean()/string()转换函数决定不做转换时字段为字符串。批量选择模式field_selection当节点名事先未知或字段数量很大时可以用选择器批量生成字段[[inputs.file.xpath]] metric_selection /Bus/child::Sensor metric_name string(sensors) timestamp /Gateway/Timestamp timestamp_format 2006-01-02T15:04:05Z field_selection child::Variable field_name name(*[1]) field_value number(*[1]) [inputs.file.xpath.tags] name substring-after(name, )field_selection选中构成字段的一组节点每个节点生成一个字段field_name/field_value分别决定字段名与值缺省时用节点名和节点内容。二者仅在指定了field_selection时才生效。field_name_expansion为true时字段名展开为相对选中节点的路径适用于被选节点存在重名的情况。对应的tag_selection/tag_name/tag_value/tag_name_expansion规则相同。批量模式下产生的字段始终是字符串类型显式声明的字段/tag 与批量选择重名时显式定义优先。XPath 解析实战示例对如下example.xml含Gateway与两个以上Bus节点结构?xml version1.0? Gateway NameMain Gateway/Name Timestamp2020-08-01T15:04:03Z/Timestamp Sequence12/Sequence Statusok/Status /Gateway Bus Sensor nameSensor Facility A Variable temperature20.0/ Variable power123.4/ Variable frequency49.78/ Variable consumers3/ Modebusy/Mode /Sensor ... /Bus多节点选择生成多条 metric[[inputs.file]] files [example.xml] data_format xml [[inputs.file.xpath]] metric_selection /Bus/child::Sensor metric_name string(sensors) timestamp /Gateway/Timestamp timestamp_format 2006-01-02T15:04:05Z [inputs.file.xpath.tags] name substring-after(name, ) [inputs.file.xpath.fields_int] consumers Variable/consumers [inputs.file.xpath.fields] temperature number(Variable/temperature) power number(Variable/power) frequency number(Variable/frequency) ok Mode ! error输出sensors,hostHugin,nameFacility\ A consumers3i,frequency49.78,oktrue,power123.4,temperature20 1596294243000000000 sensors,hostHugin,nameFacility\ B consumers1i,frequency49.78,oktrue,power14.3,temperature23.1 1596294243000000000 sensors,hostHugin,nameFacility\ C consumers0i,frequency49.78,okfalse,power0.02,temperature19.7 1596294243000000000五、输入格式Parsing与输出格式Serializing的对称设计理解输入数据格式时可以顺带建立一张对偶地图输入侧由 parser 把外部字节流转成 metric输出侧则由 serializer 把 metric 转成外部字节流。仓库中这两套体系分别位于 plugins/parsers 与 plugins/serializers且 docs/DATA_FORMATS_OUTPUT.md 记载了输出侧支持的格式清单InfluxDB Line Protocol、Binary、Carbon2、CloudEvents、CSV、Graphite、JSON、MessagePack、Prometheus、Prometheus Remote Write、ServiceNow Metrics、SplunkMetric、Template、Wavefront。输入插件通过data_format选 parser输出插件同样通过data_format选 serializer。例如[[outputs.file]] ## Files to write to, stdout is a specially handled file. files [stdout] ## Data format to output. data_format influx因此同一套数据如 kafka 中的行协议消息可以被kafka_consumer用data_format influx解析也可以由outputs.kafka用对应 serializer 写出实现原样搬运式的管道。六、如何为你的数据选择正确的解析器一个实用的选型决策流程数据是否本身就是 Telegraf 生态的 metric 表示是 →influx行协议或prometheus/openmetrics文本指标。数据是半结构化文本日志、配置、命令输出键值对风格 →logfmt或form_urlencoded表格 →csv复杂自由文本 →grok。数据是 JSON结构规整、需要整体摊平 →json嵌套深、需精确提取 →json_v2或xpath_json。数据是二进制 / 序列化协议Avro →avroParquet →parquetProtobuf / MessagePack / CBOR / XML → 对应xpath_*自定义二进制 →binary。数据是一个裸值→value。面向特定监控生态Graphite →graphiteOpenTSDB →opentsdbWavefront →wavefrontcollectd →collectdNagios →nagiosPrometheus Remote Write →prometheusremotewrite。七、排错与验证技巧先确认插件支持data_format大多数通用输入插件file、exec、tail、kafka_consumer、mqtt_consumer、socket_listener、http_listener_v2等都带该选项若插件没有此配置项说明它内部固定使用自己的解析方式例如部分专用监听器。用file插件 stdout 输出做最小复现将待解析数据放入测试文件配置[[inputs.file]]与[[outputs.file]] files [stdout]运行 Telegraf 观察解析结果file输出每个flush_interval打印一次耐心等待即可。关注时间戳精度与时区行协议、JSON、CSV、Grok、XPath 都涉及时间解析先确认输入时间戳是 unix 秒/毫秒/微秒/纳秒还是格式化字符串、是否含时区信息再决定*_timestamp_precision、*_time_format、*_timezone等配置。利用 debug 日志xpath_print_document可以把非 XML 格式的内部文档打印出来方便推导 XPath 表达式Grok 可开启逐 token 增量的调试法见第三节。阅读对应解析器的 README 与测试每个解析器目录如 plugins/parsers/json/parser_test.go都带有输入→输出的测试样例是理解该格式解析行为的最权威参考。参考与延伸阅读Input Data Formats 官方文档本文骨架Metrics 数据模型解析器产出的 metric 结构定义Output Data Formats输出序列化器的对称清单CONFIGURATION.mdmetric filtering 等通用配置plugins/parsers全部 20 种解析器的源码、README 与测试plugins/parsers/registry.go解析器注册表实现config/config.godata_format到 parser 实例的装配逻辑【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegraf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Telegraf 输入数据格式（Input Data Formats）完全指南：从 parser 注册表到 20 种解析器实战
Telegraf 输入数据格式Input Data Formats完全指南从 parser 注册表到 20 种解析器实战【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegrafTelegraf 的许多通用型输入插件如exec、file、kafka_consumer、tail、socket_listener等本身并不关心收到的字节流是什么样而是通过一个可配置的 parser解析器将任意输入数据转换为统一的 metric 模型。本文以仓库中的 docs/DATA_FORMATS_INPUT.md 为骨架结合 plugins/parsers 目录下的真实实现与各解析器 README系统讲解如何用data_format选择解析器、20 种内置格式的适用场景与核心配置、解析器插件的注册与加载机制以及选型与排错思路。读完本文你将掌握① 哪些输入插件支持data_format以及如何配置② 每一种输入数据格式的定位、关键参数与配置示例③ 从 plugins/parsers/registry.go 到 config/config.go 的解析器解析与装配链路④ 如何为自己的数据选对解析器并快速定位解析问题。一、解析器机制通用输入插件的可插拔数据消费层Telegraf 的核心设计之一是采集与解析分离输入插件负责获取原始数据读文件、订阅消息队列、监听端口、执行命令而数据格式的解析工作交给独立的 parser。这种解耦带来了极大的灵活性——例如 kafka_consumer 输入插件可以消费同一主题中的消息并按需以 InfluxDB Line Protocol、JSON、Avro 等任意格式解析。任何包含data_format配置项的输入插件都可以使用该选项来选择解析器。仓库中这类插件数量众多覆盖了文件file、命令exec、消息队列kafka_consumer、mqtt_consumer、amqp_consumer、网络监听socket_listener、http_listener_v2、influxdb_listener以及tail、statsd等场景。一个典型的配置如下取自 docs/DATA_FORMATS_INPUT.md[[inputs.exec]] ## Commands array commands [/tmp/test.sh, /usr/bin/mycollector --foobar] ## measurement name suffix (for separating different commands) name_suffix _mycollector ## Data format to consume. data_format json解析器从配置到实例的装配链路从源码结构看解析器通过一个全局注册表挂载见 plugins/parsers/registry.go// Creator is the function to create a new parser type Creator func(defaultMetricName string) telegraf.Parser // Parsers contains the registry of all known parsers (following the new style) var Parsers make(map[string]Creator) // Add adds a parser to the registry. Usually this function is called in the plugins init function func Add(name string, creator Creator) { Parsers[name] creator }每个解析器在自己的init()函数中调用parsers.Add(json, ...)之类的注册逻辑然后在配置加载阶段config/config.go框架读取输入插件表中的data_format字符串从parsers.Parsers注册表中找到对应的Creator工厂函数实例化出具体的telegraf.Parser并注入到输入插件中。data_format的值不区分大小写之外的任何附加语义直接作为注册表 key 使用。二、内置输入数据格式总览当前仓库的 plugins/parsers 目录下共包含 20 种输入解析器对应data_format的取值如下data_format取值解析器适用数据avroAvroApache Avro 序列化数据binaryBinary自定义二进制协议需配置编码规则collectdCollectdcollectd 网络协议二进制csvCSV逗号分隔的表格文本dropwizardDropwizardDropwizard 指标 JSONform_urlencodedForm URL Encoded表单编码的键值对a1b2graphiteGraphiteGraphite 纯文本协议grokGrok基于正则模板的日志行influxInfluxDB Line ProtocolInfluxDB 行协议jsonJSONJSON 对象 / 对象数组json_v2JSON v2基于路径精确提取的 JSONlogfmtLogfmtkeyvalue格式的日志行nagiosNagiosNagios 插件输出openmetricsOpenMetricsOpenMetrics 文本格式opentsdbOpenTSDBOpenTSDBtelnet/http写协议parquetParquetApache Parquet 列式文件prometheusPrometheusPrometheus 文本格式prometheusremotewritePrometheusRemoteWritePrometheus Remote Write 二进制valueValue单个裸值如45或booyahwavefrontWavefrontWavefront 文本格式xml/xpath_json/xpath_msgpack/xpath_protobuf/xpath_cborXPathXML、JSON、MessagePack、Protocol Buffers、CBOR通过 XPath 表达式提取说明上述data_format取值与 docs/DATA_FORMATS_INPUT.md 中的格式列表一一对应其中 XPath 一族在配置中用data_format xml等具体值区分底层数据格式。从 registry 到 all 包的无侵入注册解析器全部通过parsers.Add(name, creator)注册。为了控制二进制体积Telegraf 支持自定义构建custom builder是否导入某个解析器的init()由构建时决定——这也解释了为什么 plugins/parsers/all 目录中有一组聚合导入文件它们是默认构建时批量引入各解析器的总开关。三、最常用的文本格式解析器详解1. JSON把任意 JSON 结构摊平成 metricJSON 解析器把 JSON 对象或对象数组解析为 metric 字段见 plugins/parsers/json/README.md。关键行为所有 JSON 数字都会转换为 float 字段JSON 字符串与布尔值默认被忽略除非在tag_keys或json_string_fields中显式指定。核心配置项[[inputs.file]] files [example] data_format json ## 当 strict 为 true 且解析 JSON 数组时数组内所有对象必须合法 json_strict true ## GJSON 路径指定解析文档中的某个子块未指定则解析整个文档 json_query ## 应作为 tag 的 key 列表匹配到的 key 不再作为字段保存支持通配符 glob tag_keys [my_tag_1, my_tag_2, tags_*, tag*] ## 应作为字符串字段的 keyglob 模式或布尔 key json_string_fields [] ## 用作 measurement 名称的 key json_name_key ## 包含时间戳的 key需配合 json_time_format 使用 json_time_key json_time_format # unix / unix_ms / unix_us / unix_ns 或 Go 参考时间格式 json_timezone # 默认 UTC可填 Local 或 IANA 时区名json_query使用 GJSON 路径语法在任何其他选项之前先对文档做一次投影查询结果应是 JSON 对象或对象数组随后对投影结果执行常规解析。json_time_keyjson_time_format组合可以把文档内的时间戳变成 metric 时间时间格式可以是unix、unix_ms、unix_us、unix_ns或 Go 语言参考时间Mon Jan 2 15:04:05 MST 2006的排列形式。不带时区的时间按 UTC 处理可通过json_timezone改为Local或具体 IANA 时区。实战示例——利用json_name_key、tag_keys与json_string_fields[[inputs.file]] files [example] json_name_key name tag_keys [my_tag_1] json_string_fields [b_my_field] data_format json输入{ a: 5, b: {c: 6, my_field: description}, my_tag_1: foo, name: my_json }输出嵌套字段被展开为b_c等扁平名my_json,my_tag_1foo a5,b_c6,b_my_fielddescription数组与时间解析示例当 JSON 是数组时数组内每个对象都会按相同配置生成一条 metric配合json_time_key/json_time_format可逐条带上文档内时间[[inputs.file]] files [example] data_format json json_time_key b_time json_time_format 02 Jan 06 15:04 MST输入数组两条对象时输出大致为file a5,b_c6 1136387040000000000 file a7,b_c8 11685278400000000002. JSON v2面向复杂 JSON 的路径式精确提取当 JSON 结构嵌套深、字段名不固定或只需提取部分字段时使用 JSON v2。它通过[[inputs.file.json_v2]]子表逐字段声明提取路径、类型与时间适合对数据形状有强控制需求的场景。与 v1 的整体摊平 少量键指定思路不同v2 的每个字段、标签、时间都可由 JSONPath 表达式显式定义。3. CSV表格式数据的行列映射CSV 解析器 将含逗号分隔值的文档解析为 metric每一行生成一条 metric列作为字段字段类型根据内容自动推断。常用配置项[[inputs.file]] files [example] data_format csv csv_header_row_count 0 # 表头行数0 表示无表头首行即数据 csv_column_names [] # 自定义列名header_row_count0 时必填 csv_column_types [] # 显式列类型int / float / bool / string按列顺序给出 csv_skip_rows 0 # 解析表头前跳过的行数 csv_metadata_rows 0 # 表头前的元数据行数键值对默认作为 tag 加入 csv_metadata_separators [:, ] csv_metadata_trim_set # 元数据值的修剪字符集 csv_skip_columns 0 # 跳过开头 N 列表头同样跳过 csv_delimiter , # 字段分隔符 csv_comment # 注释行起始字符注释行整行跳过 csv_trim_space false # 是否去除字段前导空白 csv_tag_columns [] # 作为 tag 的列 csv_tag_overwrite false # 列 tag 是否覆盖元数据/默认 tag csv_measurement_column # 取 measurement 名的列该列不再作为字段 csv_timestamp_column # 取时间的列 csv_timestamp_format # 同 JSON 的时间格式规则unix* 或 Go 参考时间 csv_timezone # 无时区信息时的 IANA 时区 csv_skip_values [] # 命中这些值的字段整体跳过 csv_skip_errors false # 无法解析的行是否直接跳过 csv_reset_mode none # none / always是否每次调用都重置解析器状态多行表头与元数据csv_header_row_count 1时多行表头会逐行拼接列名csv_metadata_rows 0时表头前的若干行按csv_metadata_separators拆出(key, value)默认作为 tag 注入每条 metric若想转成字段可使用 converter 处理器。示例来自 plugins/parsers/csv/README.md[[inputs.file]] files [example] data_format csv csv_metadata_rows 2 csv_metadata_separators [:, ] csv_metadata_trim_set # csv_header_row_count 1 csv_tag_columns [Version,cpu] csv_timestamp_column time csv_timestamp_format 2006-01-02T15:04:05Z07:00输入# Version1.1 # File Created: 2021-11-17T07:02:4510:00 Version,measurement,cpu,time_user,time_system,time_idle,time 1.2,cpu,cpu0,42,42,42,2018-09-13T13:03:28Z输出cpu,cpucpu0,File\ Created2021-11-17T07:02:4510:00,Version1.1 time_user42,time_system42,time_idle42 1536869008000000000若将csv_tag_overwrite设为true列值1.2会覆盖元数据中的Version1.1。此外 CSV 解析器还支持通过 metric filtering 跳过特定列和行。4. Grok用正则模板解析任意日志行Grok 解析器 使用类 Logstash 的正则模板语言解析行分隔文本。模式语法为%{capture_syntax[:semantic_name][:modifier]}capture_syntax用于匹配输入的 grok 模式如NUMBER、COMMON_LOG_FORMATsemantic_name捕获结果对应的字段或 tag 名modifier控制数据类型转换或特殊处理。默认所有具名捕获都会变成字符串字段没有semantic_name的模式不会被捕获每行至少捕获一个字段。可用修饰符string默认、int、floatduration如5.23ms转为纳秒整数tag转成 tag、drop丢弃该字段measurement把匹配文本作为 measurement 名时间戳修饰符ts系列可把捕获内容作为 metric 时间若不解析时间则使用当前时间修饰符对应时间格式ts自动学习时间格式ts-ansicMon Jan _2 15:04:05 2006ts-unixMon Jan _2 15:04:05 MST 2006ts-rubyMon Jan 02 15:04:05 -0700 2006ts-rfc82202 Jan 06 15:04 MSTts-rfc822z02 Jan 06 15:04 -0700ts-rfc850Monday, 02-Jan-06 15:04:05 MSTts-rfc1123Mon, 02 Jan 2006 15:04:05 MSTts-rfc1123zMon, 02 Jan 2006 15:04:05 -0700ts-rfc33392006-01-02T15:04:05Z07:00ts-rfc3339nano2006-01-02T15:04:05.999999999Z07:00ts-httpd02/Jan/2006:15:04:05 -0700ts-epochUnix 秒可含小数ts-epochnanoUnix 纳秒ts-epochmilliUnix 毫秒ts-syslogJan 02 15:04:05年份取当前年ts-CUSTOM自定义布局基于 Go 参考时间需加引号例如%{TIMESTAMP:timestamp:ts-2006-01-02 15:04:05.000}可匹配2018-01-02 15:04:05,000用.匹配小数点。注意Go 正则不支持前瞻/后顾断言依赖这些特性的 Logstash 模式可能无法直接使用。Grok 配置示例[[inputs.file]] files [/var/log/apache/access.log] data_format grok ## 待匹配模式列表模式越多处理越慢单个模式效率最高 ## 常见内置模式%{COMMON_LOG_FORMAT}apache/nginx 访问日志、%{COMBINED_LOG_FORMAT} grok_patterns [%{COMBINED_LOG_FORMAT}] ## 自定义模式文件完整路径 grok_custom_pattern_files [] ## 也可以在这里逐行定义自定义模式 grok_custom_patterns ## 无时区信息时间戳的时区默认 UTC可填 Local 或 IANA 时区 grok_timezone Canada/Eastern ## 设为 disable 时重复时间戳不再递增 # grok_unique_timestamp auto ## 开启多行消息处理 # grok_multiline false自定义时间戳示例解析Wed Apr 12 13:10:34 PST 2017 value42[[inputs.file]] grok_patterns [%{TS_UNIX:timestamp:ts-unix} value%{NUMBER:value:int}] grok_custom_patterns TS_UNIX %{DAY} %{MONTH} %{MONTHDAY} %{HOUR}:%{MINUTE}:%{SECOND} %{TZ} %{YEAR} TOML 转义陷阱grok 语法本身需要转义如|是特殊字符TOML 字符串又要二次转义因此多层转义极易出错。官方建议能用多行字面量字符串就用它例如匹配|42|\uD83D\uDC2F|telegraf|可写成[[inputs.file]] grok_patterns [ \|%{NUMBER:value:int}\|%{UNICODE_ESCAPE:escape}\|%{WORD:name}\| ] grok_custom_patterns UNICODE_ESCAPE (?:\\u[0-9A-F]{4})模式调试与性能建议调试时可单独配置[[outputs.file]] files [stdout]并禁用其他输出从单行输入开始、一次只加一个 token 逐步验证。性能上避免使用%{DATA}这类永远能匹配的模式尽量给模式加^和$锚点如grok_patterns [^%{COMBINED_LOG_FORMAT}$]。5. Value解析单个裸值Value 解析器 处理一行就是一个值的输入例如45或booyah。典型场景是脚本或命令直接输出一个数字。它通常配合data_format value使用值会被放入默认字段中可通过输入插件的字段命名选项调整。6. InfluxDB Line ProtocolTelegraf 的母语Influx 解析器 使用 InfluxDB 行协议解析 metric。由于行协议是 Telegraf 的内部表示语言见 docs/METRICS.mdinflux是许多管道场景如kafka_consumer消费 Telegraf 序列化消息、influxdb_listener接收写入的默认选择。配置项[[inputs.file]] files [example] data_format influx ## internal 为默认解析器upstream 是更新、更快且更省内存的实现 # influx_parser_type internal ## 时间戳精度默认 1ns可设为 1s / 1ms / 1us # influx_timestamp_precision 1nsinflux_timestamp_precision用于声明输入数据的时间戳精度默认为纳秒1ns当上游输出的是秒、毫秒或微秒时间戳时必须显式指定否则时间会被错误放大或缩小。7. 更多面向特定生态的格式Graphiteplugins/parsers/graphite解析metric.path value timestamp纯文本协议适合直接接入现有 Graphite 数据流。Collectdplugins/parsers/collectd解析 collectd 二进制网络协议需要网络鉴权配置security_level、auth_file。OpenTSDBplugins/parsers/opentsdb支持telnet与http两种写协议格式。Nagiosplugins/parsers/nagios解析 Nagios 插件标准输出OK|WARNING|...与性能数据自动生成nagios_state等字段。Prometheus与OpenMetricsplugins/parsers/prometheus、plugins/parsers/openmetrics分别解析 Prometheus 文本格式与 OpenMetrics 文本格式可直接消费/metrics端点输出或抓取到的指标文本prometheusremotewrite则解析 Prometheus Remote Write 的 protobuf 二进制。Wavefrontplugins/parsers/wavefront解析 Wavefront 文本格式含 delta counter 支持。Logfmtplugins/parsers/logfmt解析keyvalue风格的结构化日志行。Form URL Encodedplugins/parsers/form_urlencoded解析a1b2表单编码数据。Dropwizardplugins/parsers/dropwizard解析 Dropwizard 指标 JSON支持json_query、tag_keys等类似 JSON 的配置。Binaryplugins/parsers/binary为自定义二进制协议提供声明式配置字节序、编码、位宽等。Avro与Parquetplugins/parsers/avro、plugins/parsers/parquet分别解析 Avro 二进制记录与 Parquet 列式文件适用于大数据生态的指标数据。四、XPath 一族XML / JSON / MessagePack / Protobuf / CBOR 的统一抽象XPath 解析器 用 XPath 表达式把多种数据格式统一映射为 metric 字段data_format的具体取值决定底层数据格式底层数据格式data_format取值XMLxmlJSONxpath_jsonMessagePackxpath_msgpackProtocol Buffersxpath_protobufCBORxpath_cbor字段类型由 XPath 转换函数number()、boolean()、string()指定唯一例外是整数字段必须写在fields_int子表中XPath 没有整数转换函数。Protocol Buffers 专属配置使用xpath_protobuf时必须指定xpath_protobuf_files必填.proto定义文件名列表xpath_protobuf_type必填顶层消息全限定名通常为package name.message namexpath_protobuf_import_paths可选import的其他.proto文件搜索路径默认只在当前工作目录.查找xpath_protobuf_skip_bytes可选跳过报文头部 N 字节再解析。已知场景GRPC 的 Length-Prefixed-Messages 需要跳 5 字节PowerDNS 日志消息有 2 字节长度头。示例[[inputs.file]] files [example.dat] data_format xpath_protobuf xpath_protobuf_files [A.proto] xpath_protobuf_type foo.Measurement xpath_protobuf_import_paths [., /data/my_proto_files] xpath_protobuf_skip_bytes 0CBOR 的数值键规则CBOR 支持数值键而 XML 要求节点名以字母开头因此解析器会把数值节点名前缀n并转成字符串CBOR 中的键123需用n123在 XPath 中查询。显式配置模式逐字段声明[[inputs.file]] files [example.xml] data_format xml # xpath_protobuf_files [sparkplug_b.proto] # xpath_protobuf_type org.eclipse.tahu.protobuf.Payload # xpath_protobuf_import_paths [.] # xpath_protobuf_skip_bytes 0 ## 调试以 debug 日志打印内部 XML 文档对非 XML 格式尤其有用 # xpath_print_document false ## 允许某个解析段落的结果为空 # xpath_allow_empty_selection false ## 对含类型信息的格式CBOR/protobuf/msgpack/JSON启用原生类型 # xpath_native_types false [[inputs.file.xpath]] # metric_selection /Bus/child::Sensor # metric_name string(example) # timestamp /Gateway/Timestamp # timestamp_format 2006-01-02T15:04:05Z # timezone UTC # fields_bytes_as_hex [] # fields_bytes_as_base64 [] [inputs.file.xpath.tags] name substring-after(Sensor/name, ) device string(the ultimate sensor) [inputs.file.xpath.fields_int] consumers Variable/consumers [inputs.file.xpath.fields] temperature number(Variable/temperature) power number(Variable/power) frequency number(Variable/frequency) ok Mode ! ok要点metric_selection可选用 XPath 选中一组节点每个节点生成一条 metric后续相对查询都以选中节点为基准绝对路径需以/开头不指定时相对查询以文档根节点为基准。metric_name可选用查询结果覆盖 measurement 名。timestamp/timestamp_format/timezone可选默认使用当前时间timestamp_format可取unix、unix_ms、unix_us、unix_ns或 Go 参考时间格式缺省按unix秒处理timezone用于给无时区信息的时间定位时区含时区偏移的格式如 RFC3339 不受影响unix 系列格式忽略该设置。tags子表tag名 XPath查询查询结果一律转成字符串。fields_int子表查询结果必须可转为 int64否则转换失败。fields子表类型由查询中的number()/boolean()/string()转换函数决定不做转换时字段为字符串。批量选择模式field_selection当节点名事先未知或字段数量很大时可以用选择器批量生成字段[[inputs.file.xpath]] metric_selection /Bus/child::Sensor metric_name string(sensors) timestamp /Gateway/Timestamp timestamp_format 2006-01-02T15:04:05Z field_selection child::Variable field_name name(*[1]) field_value number(*[1]) [inputs.file.xpath.tags] name substring-after(name, )field_selection选中构成字段的一组节点每个节点生成一个字段field_name/field_value分别决定字段名与值缺省时用节点名和节点内容。二者仅在指定了field_selection时才生效。field_name_expansion为true时字段名展开为相对选中节点的路径适用于被选节点存在重名的情况。对应的tag_selection/tag_name/tag_value/tag_name_expansion规则相同。批量模式下产生的字段始终是字符串类型显式声明的字段/tag 与批量选择重名时显式定义优先。XPath 解析实战示例对如下example.xml含Gateway与两个以上Bus节点结构?xml version1.0? Gateway NameMain Gateway/Name Timestamp2020-08-01T15:04:03Z/Timestamp Sequence12/Sequence Statusok/Status /Gateway Bus Sensor nameSensor Facility A Variable temperature20.0/ Variable power123.4/ Variable frequency49.78/ Variable consumers3/ Modebusy/Mode /Sensor ... /Bus多节点选择生成多条 metric[[inputs.file]] files [example.xml] data_format xml [[inputs.file.xpath]] metric_selection /Bus/child::Sensor metric_name string(sensors) timestamp /Gateway/Timestamp timestamp_format 2006-01-02T15:04:05Z [inputs.file.xpath.tags] name substring-after(name, ) [inputs.file.xpath.fields_int] consumers Variable/consumers [inputs.file.xpath.fields] temperature number(Variable/temperature) power number(Variable/power) frequency number(Variable/frequency) ok Mode ! error输出sensors,hostHugin,nameFacility\ A consumers3i,frequency49.78,oktrue,power123.4,temperature20 1596294243000000000 sensors,hostHugin,nameFacility\ B consumers1i,frequency49.78,oktrue,power14.3,temperature23.1 1596294243000000000 sensors,hostHugin,nameFacility\ C consumers0i,frequency49.78,okfalse,power0.02,temperature19.7 1596294243000000000五、输入格式Parsing与输出格式Serializing的对称设计理解输入数据格式时可以顺带建立一张对偶地图输入侧由 parser 把外部字节流转成 metric输出侧则由 serializer 把 metric 转成外部字节流。仓库中这两套体系分别位于 plugins/parsers 与 plugins/serializers且 docs/DATA_FORMATS_OUTPUT.md 记载了输出侧支持的格式清单InfluxDB Line Protocol、Binary、Carbon2、CloudEvents、CSV、Graphite、JSON、MessagePack、Prometheus、Prometheus Remote Write、ServiceNow Metrics、SplunkMetric、Template、Wavefront。输入插件通过data_format选 parser输出插件同样通过data_format选 serializer。例如[[outputs.file]] ## Files to write to, stdout is a specially handled file. files [stdout] ## Data format to output. data_format influx因此同一套数据如 kafka 中的行协议消息可以被kafka_consumer用data_format influx解析也可以由outputs.kafka用对应 serializer 写出实现原样搬运式的管道。六、如何为你的数据选择正确的解析器一个实用的选型决策流程数据是否本身就是 Telegraf 生态的 metric 表示是 →influx行协议或prometheus/openmetrics文本指标。数据是半结构化文本日志、配置、命令输出键值对风格 →logfmt或form_urlencoded表格 →csv复杂自由文本 →grok。数据是 JSON结构规整、需要整体摊平 →json嵌套深、需精确提取 →json_v2或xpath_json。数据是二进制 / 序列化协议Avro →avroParquet →parquetProtobuf / MessagePack / CBOR / XML → 对应xpath_*自定义二进制 →binary。数据是一个裸值→value。面向特定监控生态Graphite →graphiteOpenTSDB →opentsdbWavefront →wavefrontcollectd →collectdNagios →nagiosPrometheus Remote Write →prometheusremotewrite。七、排错与验证技巧先确认插件支持data_format大多数通用输入插件file、exec、tail、kafka_consumer、mqtt_consumer、socket_listener、http_listener_v2等都带该选项若插件没有此配置项说明它内部固定使用自己的解析方式例如部分专用监听器。用file插件 stdout 输出做最小复现将待解析数据放入测试文件配置[[inputs.file]]与[[outputs.file]] files [stdout]运行 Telegraf 观察解析结果file输出每个flush_interval打印一次耐心等待即可。关注时间戳精度与时区行协议、JSON、CSV、Grok、XPath 都涉及时间解析先确认输入时间戳是 unix 秒/毫秒/微秒/纳秒还是格式化字符串、是否含时区信息再决定*_timestamp_precision、*_time_format、*_timezone等配置。利用 debug 日志xpath_print_document可以把非 XML 格式的内部文档打印出来方便推导 XPath 表达式Grok 可开启逐 token 增量的调试法见第三节。阅读对应解析器的 README 与测试每个解析器目录如 plugins/parsers/json/parser_test.go都带有输入→输出的测试样例是理解该格式解析行为的最权威参考。参考与延伸阅读Input Data Formats 官方文档本文骨架Metrics 数据模型解析器产出的 metric 结构定义Output Data Formats输出序列化器的对称清单CONFIGURATION.mdmetric filtering 等通用配置plugins/parsers全部 20 种解析器的源码、README 与测试plugins/parsers/registry.go解析器注册表实现config/config.godata_format到 parser 实例的装配逻辑【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegraf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考