Read with value = num filter gives incorrect empty results

[dmehra]

Despite the wording of the error message Only AND and '=' operators with string values are supported in the optimized filter expression. that you get when trying currently unsupported read filters (see #13 ), it is possible to do value = N matching. However, it will always return an empty set.

juttle> read opentsdb -from :2016-01-01: -name "df.bytes.used" | head 1
┌────────────────────────────────────┬────────────────────┬─────────────────┬──────────┬──────────────────┬───────────────┐
│ time                               │ name               │ value           │ fstype   │ host             │ mount         │
├────────────────────────────────────┼────────────────────┼─────────────────┼──────────┼──────────────────┼───────────────┤
│ 2016-02-12T07:34:04.000Z           │ df.bytes.used      │ 13029310464     │ ext4     │ f5796f87a78f     │ /etc/hosts    │
└────────────────────────────────────┴────────────────────┴─────────────────┴──────────┴──────────────────┴───────────────┘
juttle> read opentsdb -from :2016-01-01: -name "df.bytes.used" value = 13029310464
└───────────┴───────────┘

Fwiw the same happens when trying to filter on time:

juttle> read opentsdb -from :2016-01-01: -name "df.bytes.used" time = :2016-02-12T07:34:04.000Z:
└───────────┴───────────┘

The time filter is not too useful and less likely, of course, but filtering on numeric fields is a likely use case.

If we truly cannot support filtering on non-string fields like value, let's error out, rather than silently returning nothing.

[dmehra]

Tangentially related - note this additional behavior which isn't a bug, per se, but I wanted to confirm it's intentional: if a tag was written with a value that's a number, but formatted as string (because write opentsdb would not otherwise accept it), then it's possible to filter on it as tagname = N without quoting the number, and results come back.

juttle> emit -points [ { time: '2016-01-01T01:01:01.111Z', name: 'dm.my.test', value: 41, tag1: 'mytag1.11', tag2: 'mytag2.11', tag3: '51' } ] | write opentsdb 

juttle> read opentsdb -from :2016-01-01: -name 'dm.my.test' tag3 = 51
┌────────────────────────────────────┬───────────────┬──────────┬──────────────┬──────────────┬──────────┐
│ time                               │ name          │ value    │ tag1         │ tag2         │ tag3     │
├────────────────────────────────────┼───────────────┼──────────┼──────────────┼──────────────┼──────────┤
│ 2016-01-01T01:01:01.111Z           │ dm.my.test    │ 41       │ mytag1.11    │ mytag2.11    │ 51       │
└────────────────────────────────────┴───────────────┴──────────┴──────────────┴──────────────┴──────────┘

The read also works if i quote tag3 = '51'. I'm ambivalent on whether filter without quoting the numeric string should work; if that was accidental behavior, it would fine to remove it.

[VladVega]

• I think in Opentsdb all tags must be strings.
• filtering by time: I'm not sure we should support this anywhere since we have to and from: We actually talked about this a couple of months back with @demmer

[dmehra]

Value is not a tag is it? The issue is specifically about value = 123 filter. Perhaps we should error out if the user tries that?