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

Filtering on measurements #77

Open
bryannaegele opened this issue Jul 24, 2020 · 5 comments
Open

Filtering on measurements #77

bryannaegele opened this issue Jul 24, 2020 · 5 comments

Comments

@bryannaegele
Copy link
Contributor

I'm currently logging a debug "skipping event due to missing measurement" which is helpful for identifying an issue but is sometimes an unavoidable thing, such as :idle being nil in an Ecto query.

I could add a "report once" check but that would require another ets lookup on something that could be very frequent. Not a huge deal. Or we could enable filtering on measurements here, which we discussed during the addition of filtering on metadata.

Thoughts?

@arkgil
Copy link
Contributor

arkgil commented Jul 28, 2020

How about adding an option to disable logging for specific events? Although that is mostly equivalent to filtering, but tailored to only that specific use-case.

If we add filtering, I think it needs to be implemented via keep, drop, to avoid adding new options.

@bryannaegele
Copy link
Contributor Author

If we added it here then it would just be adding a second arg to keep/drop with the measurement values.

The other alternative is I just silently drop events with nil measurement values but warn on missing measurement keys. 🤷🏻

@josevalim
Copy link
Contributor

I want to ship v1.0 and this is an open issue which may require breaking changes. How do we feel about this 3 years later? Wouldn't you be able to discard idle=nil events using keep/drop?

@bryannaegele
Copy link
Contributor Author

We don't currently accept measurements as an arg to the predicates. If we wanted to add it later, it wouldn't be a breaking change, so not a blocker for 1.0

@josevalim
Copy link
Contributor

Ah, we could easily make it a two arity function with measurement, metadata, so it sounds good to me. I can work on a PR for this. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants