WIP: Feature/extra template context

[Skeen]

This PR introduces a new pre-defined label variable, namely extra, which contains the entire JSON object parsed from the input, when using input type webhook with format being either json_single or json_bulk.

It is flexible enough to be utilized by any input, which may want to provide a map as extra context for the label templating step.

The majority of changes has been made in the initial commit 6ee14ae, and simply involves changing the type of additionalFields from map[string]string to map[string]interface{} in order to support proper recursive data structures as extra context.

An argument could have been made to go all the way to data interface{} as this is the type utilized for the Execute method's data argument on the Template type, however map[string]interface{} seemed like a good compromise.

[Skeen]

I have tested the change using:

global:
  config_version: 3
input:
  type: webhook
  webhook_path: /webhook
  webhook_format: json_single
  webhook_json_selector: .message
  webhook_text_bulk_separator: "\n\n"
metrics:
- type: counter
  name: user_logins
  help: Total number of user logins, by user and ip.
  match: 'Login occured'
  labels:
    user: '{{ index .extra "user" }}'
    ip: '{{ index .extra "ip" }}'
server:
  host: "[::]"
  port: 9144

Started as:

go run grok_exporter.go -config example/config_context_json.yml

With the following log messages being posted:

curl localhost:9144/webhook --data '{"message": "Login occured", "user": "Skeen", "ip": "1.1.1.1"}'

And this as output:

# HELP user_logins Total number of user logins, by user and ip.
# TYPE user_logins counter
user_logins{ip="1.1.1.1",user="Skeen"} 1

[Skeen]

Assuming this is something you'll consider merging, I will fix the broken tests, get the build to succeed, and then remove the WIP: prefix on the PR.

[fstab]

Thanks a lot for this! I'll look into this in the next couple of days and get back to you.

[fstab]

Thanks a lot, this sounds like a useful feature for users of the webhook users. I'm happy to merge it once it's finalized.

[Skeen]

Cool, I'll finish the work on it.

[Skeen]

I don't seem to be able to reproduce the failing test in the appveyor/pr check.

skeen@ibuprofen ~/p/grok_exporter (feature/extra_template_context)> go clean -testcache
skeen@ibuprofen ~/p/grok_exporter (feature/extra_template_context)> go test ./...
?   	github.com/fstab/grok_exporter	[no test files]
ok  	github.com/fstab/grok_exporter/config	0.003s
ok  	github.com/fstab/grok_exporter/config/v2	0.011s
ok  	github.com/fstab/grok_exporter/config/v3	0.015s
ok  	github.com/fstab/grok_exporter/exporter	0.681s
ok  	github.com/fstab/grok_exporter/oniguruma	0.010s
ok  	github.com/fstab/grok_exporter/tailer	23.284s
?   	github.com/fstab/grok_exporter/tailer/fswatcher	[no test files]
ok  	github.com/fstab/grok_exporter/tailer/glob	0.003s
ok  	github.com/fstab/grok_exporter/template	0.004s

Can you assist me with finding out what is going afoul here?

[coveralls]

Coverage increased (+0.01%) to 67.231% when pulling e4e0ccc on magenta-aps:feature/extra_template_context into 58c93fb on fstab:master.

[fstab]

Unfortunately, the Windows file tailor tests are flaky:

fswatcher_test.go:652: C:\Users\appveyor\AppData\Local\Temp\1\grok_exporter807922133\logdir still contains file logfile.log after mv.

The test is simulating logrotate moving the logfile away, but after the mv operation the file is still in the directory. I have no idea why this happens, because the os.Rename(...) call does not return an error. You can ignore this. Re-running the test manually in Appveyor helps, but I think you need to log in to do that. As it is test code that fails and not production code, I don't think it's a big risk to ignore this.

If you have any idea how os.Rename(...) can be successful but the file is still there after that, I'd be grateful, but this has nothing to do with your changes.

[fstab]

Thanks a lot!!!

[fstab]

P.S.: After the merge Appveyor built without error again without any code change https://ci.appveyor.com/project/fstab/grok-exporter/builds/32644306

[Skeen]

...

If you have any idea how os.Rename(...) can be successful but the file is still there after that, I'd be grateful, but this has nothing to do with your changes.

Are we sure that os.rename(...) is indeed atomic on Windows?

I don't believe that is the case in general, as Python calls MoveFileW() on Windows, which is atomic in specific cases, but not as a general case (such as with network mounted file-systems).
On Windows to ensure atomic renaming, you'd have to create a transaction with CreateTransaction() followed by a call to MoveFileTransacted(), and finally a commit.

So in general, I would not assume a os.rename call to be atomic on Windows.

Potential solutions:

1. Find a library which does transactional file-moves, and accept that the tests will only pass on Windows Vista and higher.
2. Add a sleep / busy wait loop, continuously checking whether the file has actually been moved yet, and leaving the loop after that happens.