Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] add a input data syntax check filter. #142

Closed
toni-moreno opened this issue Jan 27, 2016 · 6 comments
Closed

[Feature Request] add a input data syntax check filter. #142

toni-moreno opened this issue Jan 27, 2016 · 6 comments

Comments

@toni-moreno
Copy link

Could be interesting if c-relay could add a syntax filter avoiding sending malformed data:

"metric-name value timestamp"

to the graphite backend.

A logfile with this errors and the IP origin will be wellcomed also.

Thank you very much.

@grobian
Copy link
Owner

grobian commented Jan 28, 2016

I think this request is similar to PR #87 right?

@toni-moreno
Copy link
Author

Hi @grobian . This issue is similar but not exactly the same.

in #87 , you will log "unwanted" this is metrics that you don't have any "match" rule.

In this issue what I need is a syntax check for valid metrics.

These metrics are valid metrics to graphite in "PlainText Format"

system.cpu.wait  80 1454056517
system.disk.io  25.0 1454056517

and these other are invalid to graphite

system.cpu.wait  OK 1454056517              #bad value
system.cpu.wait  OK 12343                   #bad timestamp
system.cpu.wait  25 OK                      #bad timestamp
system   cpu  wait  25.0 1454056517         #bad number of parameters

Right now carbon-c-relay is relaying invalid metrics if a correct match rule found. I need to stop these invalid metrics before to reach the graphite backend.

@piotr1212
Copy link
Contributor

I'm not sure if I understand, that is exactly what is requested in #87
And partially implemented in https://github.com/piotr1212/carbon-c-relay/commits/filter2
@grobian made some changes since then and suggested to use a regex which is a much better idea than the ugly parsing I did...

@grobian
Copy link
Owner

grobian commented Jan 29, 2016

@toni-moreno do you mean #78 (iso #87)? It's all a bit confusing right now :)

@toni-moreno
Copy link
Author

Hi @grobian what @piotr1212 have been done at #87 is exactly what we need.

Thank you !!!

grobian added a commit that referenced this issue Nov 11, 2016
This implements a solution for issue #228, issue #142, #issue #121,
pull #227 and pull #87.

Introduce new `validate <regexp> else <drop | log>` construct in match
rules to do checks on the data part of the message.
@grobian
Copy link
Owner

grobian commented Nov 11, 2016

I've introduced a validate clause to match rules

@grobian grobian closed this as completed Nov 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants