电报间歇性 processor.regex

Telegraf intermittent processor.regex

我的电报出现间歇性问题 processors.regex(至少这是我最好的猜测)

我们正在使用以下电报配置

inputs.conf

[[inputs.http]]
  urls = [
    "http://myserver.mycompany.com:8080/some/rest/api",
  ]

  username = "user"
  password = "password"

  name_override = "monitor"

  interval = "600s"
  timeout = "3s"

  data_format = "json"
  json_query = "rows"
  json_string_fields = [ "size" ]
  tagexclude = ["host"]

outputs.conf

[[outputs.influxdb]]
  database = "metrics"
  urls = ["http://influxdb.mycompany.com:8086"]

processors.conf

[[processors.converter]]
  [processors.converter.fields]
    integer = [ "size" ]


# Process order is VERY important here
# Rename the url tag to target
[[processors.rename]]
  [[processors.rename.replace]]
    tag = "url"
    dest = "target"

# Extract the target name from the url (I know we just renamed it ... weird)
[[processors.regex]]
  [[processors.regex.tags]]
    key = "url"
    pattern='^http://(?P<target>[^:/]+).+'
    replacement = "${target}"

当我运行:

telegraf --config telegraf.conf --config-directory telegraf.d --test --debug --input-filter http

我取回了我期望的数据,url 已被正则表达式 target 替换,即

monitor,target=myserver.mycompany.com size=123456789i 1627647959000000000

问题出在我创建的 grafana 图中,我看到的是原始的完整 url http://myserver.mycompany.com:8080/some/rest/api 而不是处理后的 myserver.mycompany.com。另外 非常 偶尔,当我 运行 电报测试时,我会看到 target return 编辑了完整的未处理 url 即

monitor,target=http://myserver.mycompany.com:8080/some/rest/api size=123456789i 1627647959000000000

数据正确且已处理,即 json 中的 size 字符串 return 始终转换为 int,而 url 始终重命名为 target.

更奇怪的是,我已经将此配置(根据地区在 inputs.http 中使用不同的 url)推送到多个服务器,其中大多数都按预期工作,只是一些有这种行为。我已经检查并确保每台服务器上的所有 telegraf 版本都匹配 (1.19.1),并且它们在 Centos 7 上都是 运行ning。我还尝试从 influxdb 中清除数据。

目标中 return url 的少数服务器总是这样做,即使当我 运行 对它们进行 telegraf 测试时,它们显示主机已按应有的方式剥离.

关于下一步要看哪里的任何提示?

找到原因了!

来自telegraf docs.

The following config parameters are available for all processors:

order: This is the order in which the processor(s) get executed. If this is not specified then processor execution order will be random.

甚至我的评论也揭示了为什么这是一个问题

# Process order is VERY important here
# Rename the url tag to target
# Extract the target name from the url (I know we just renamed it ... weird)

是的,这很奇怪,但那是因为我碰巧在我的测试中一直有相同的 50:50 机会,但其他顺序的可能性相同。当顺序错误时,密钥被重命名并且正则表达式没有任何可处理的。

解决方法是使用order.

processors.conf

[[processors.converter]]
  [processors.converter.fields]
    integer = [ "size" ]

# Extract the target name from the url
[[processors.regex]]
  order = 1
  [[processors.regex.tags]]
    key = "url"
    pattern='^http://(?P<target>[^:/]+).+'
    replacement = "${target}"

# Rename the url tag to target
[[processors.rename]]
  order = 2
  [[processors.rename.replace]]
    tag = "url"
    dest = "target"

现在正则表达式总是 运行 在重命名之前。