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

snmp: Don't drop lines with an empty tag #1927

Closed
wants to merge 1 commit into from
Closed

snmp: Don't drop lines with an empty tag #1927

wants to merge 1 commit into from

Conversation

hahnjo
Copy link
Contributor

@hahnjo hahnjo commented Oct 23, 2016

Required for all PRs:

  • CHANGELOG.md updated (we recommend not updating this until the PR has been approved by a maintainer)
  • Sign CLA (if not already signed)

The changes in #1848 resulted in lines being dropped if they had an empty tag. So let's count empty tags as valid to take the right decision!

@sparrc
Copy link
Contributor

sparrc commented Oct 24, 2016

I don't think this is exactly the right solution, you should probably add the line but drop the empty tag.

@phemmer please also review

@hahnjo
Copy link
Contributor Author

hahnjo commented Oct 24, 2016

What does InfluxDB say to lines with less tags? I thought the Telegraf code was kind of ensuring InfluxDB's requirements are met...

If that's not the case, I'll happily rework the patch 👍

@sparrc
Copy link
Contributor

sparrc commented Oct 24, 2016

probably better to keep the PR as-is, IIRC empty tags get filtered out and ignored somewhere along the way anyways

@phemmer
Copy link
Contributor

phemmer commented Oct 24, 2016

Yes, we can't merge this. Empty tags were deliberately removed because influxdb does not accept them:

# influx -database test
> insert test,foo= value=1
ERR: {"error":"unable to parse 'test,foo= value=1': missing tag value"}

@sparrc
Copy link
Contributor

sparrc commented Oct 24, 2016

@phemmer telegraf isn't directly writing line-protocol from the tag/field maps provided to the accumulator, I'm fairly certain empty tags simply get dropped.

@phemmer
Copy link
Contributor

phemmer commented Oct 24, 2016

I thought I remember them not getting dropped. But in any case, you're saying the net result is the same, empty tags don't get sent to influxdb. So why a code change that results in no effective behavior change?

@sparrc
Copy link
Contributor

sparrc commented Oct 24, 2016

I believe this change allows the metric to get written, it will just get written without the empty tag. Whereas before we were dropping the metric altogether.

@hahnjo
Copy link
Contributor Author

hahnjo commented Oct 24, 2016

Right, that was the intention. I will do some tests what actually happens...

@hahnjo
Copy link
Contributor Author

hahnjo commented Oct 24, 2016

So, the current version of this works as intended, the tag will then be null in the database. However, I think it would indeed be cleaner to drop the empty tag. I will try this in the next few days...

@hahnjo hahnjo changed the title snmp: Don't ignore empty tags snmp: Don't drop lines with an empty tag Oct 25, 2016
The changes in #1848 resulted in lines being dropped if they had an empty
tag. So let's count empty tags as valid to take the right decision!
@hahnjo
Copy link
Contributor Author

hahnjo commented Oct 25, 2016

This should be cleaner and also moves the empty check to a single place...

@sparrc sparrc added this to the 1.2.0 milestone Oct 25, 2016
@hahnjo
Copy link
Contributor Author

hahnjo commented Dec 11, 2016

ping?

@sparrc
Copy link
Contributor

sparrc commented Dec 13, 2016

@phemmer can you review this change as well?

sparrc
sparrc previously approved these changes Dec 13, 2016
for _, r := range rows {
if len(r.Tags) < tagCount {
for i, r := range rows {
if len(r.Tags)+emptyTags[i] < tagCount {
// don't add rows which are missing tags, as without tags you can't filter
continue
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Effectively this change is saying that adding measurements that have no tags is OK. If were going to make that change, this check (and other related code above) should just go away. Meaning if we allow tagless measurements into influxdb, we should allow them no matter the cause, whether it was because snmp was configured for a tag that ended up being empty and thus omitted, or whether it just wasn't configured with any tags at all.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tagless measurements are already allowed into InfluxDB. I'm not sure I understand why the SNMP plugin would be asserting otherwise.

But if I understand correctly, @phemmer you're just saying that in that case this change is overly complicated? we can just remove any tag-checking at all rather than counting and incrementing this "emptyTags" map?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More or less. The emptyTags thing basically allows inserting measurements where the plugin was configured with a tag and the tag ended up being empty, but blocks measurements where there was no tag configured at all.
If we just allow tagless measurements period, then the emptyTags stuff goes away yes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so I've implemented this and I would doubt that we want it that way. Anyway, I don't have a very strong opinion as long as I get my measurements back :-)

https://github.com/hahnjo/telegraf/commit/9699fcac21706619ddd33124626f01f17fd43ce0 (look out for the test changes and especially rtr4 which is added although the tag doesn't even exist in SNMP)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so I've implemented this and I would doubt that we want it that way

What way? The new way being discussed?
I'd be interested in hearing your arguments.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really confused. The only difference between rtr4 and rtr3 is the missing myfield2 which isn't even a tag. If you are proposing that we drop based on a missing field, instead of dropping based on a missing tag, then both rtr3 and rtr4 would be dropped as they're both missing myfield4

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the main difference from my perspective is that the defined tag is either empty or does not exist:

https://github.com/hahnjo/telegraf/commit/9699fcac21706619ddd33124626f01f17fd43ce0#diff-a240fd60347435c7253f4238fae424efL61 defines the test data. .1.0.0.0.1.1.2 is just empty for rtr3 while .1.0.0.0.1.1.3 doesn't exist for rtr4. I'd consider the latter an error which should be filtered out...

Anyway, should I open a new pull request with the new branch if that's the way you prefer?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no need to create a new PR. You can force-push the changes onto this branch and that will update this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know, but that's now a somewhat different approach to fix this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I think I see what you're after now. I'm on the fence about whether we should treat missing tag differently from empty tag. In the end, both result in a data point getting inserted with no tag, and the original intent of the dropping was to prevent data from getting inserted and lumped into a single series (no ability to filter & separate them).
@sparrc What behavior would you prefer?

  1. Drop data point if a tag is missing or empty (current behavior)
  2. Drop data point if a tag is missing, but allow if empty, even though when it gets to influxdb, the tag will still be missing because empty tags are removed (this PR)
  3. Allow data points with both missing and empty tags (PR snmp: Allow lines with empty or missing tags #2172)

While I'm on the fence, I think I lean more towards # 3. I think I feel that if we want the behavior of # 2, it should be a generic telegraf option, similar to the tagpass/tagdrop options.

@sparrc sparrc dismissed their stale review December 13, 2016 19:37

need to re-review

Copy link
Contributor

@sparrc sparrc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see discussion above

@hahnjo
Copy link
Contributor Author

hahnjo commented Dec 16, 2016

Superseded by #2172

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

Successfully merging this pull request may close these issues.

3 participants