Add /tags/terms query to get counts of tag values

[shanson7]

If the interface / behavior is approved, I'll update the HTTP docs.

Fix #1573

[shanson7]

Example:

curl -s 'http://localhost:6060/tags/terms?expr=namespace=ossh&tags=name'
{
  "totalSeries": 15387,
  "terms": {
    "name": {
      "disk.average.latency.g": 925,
      "disk.average.service.time.g": 927,
      "disk.io.current.g": 961,
      "disk.io.time.g": 875,
      "disk.io.time.weighted.g": 928,
      "disk.reads.completed.g": 921,
      "disk.reads.merged.g": 946,
      "disk.reads.time.g": 985,
      "disk.sectors.read.g": 963,
      "disk.sectors.written.g": 921,
      "disk.writes.completed.g": 970,
      "disk.writes.merged.g": 924,
      "disk.writes.time.g": 953,
      "interrupt.g": 553,
      "network.softnet.cpu.collisions.g": 848,
      "network.softnet.cpu.packets.dropped.g": 899,
      "network.softnet.cpu.time.squeeze.g": 888
    }
  }
}

[Dieterbe]

looks pretty good, though i didn't go to deep in the index. i'll defer to mauro or robert on that.

[Dieterbe]

maybe personal preference, but i think elsewhere we somewhat try to order args by the order in which they're used.
if we first execute the query, then look at its result based on tags, we should probably put tags after the query.

[shanson7]

Looking at the other functions, this query seems to come later. In fact, I actually do use tags first (meaningfully, at least). I switched the order of use in the implementation, so §tags§ is used first for real.

[Dieterbe]

let's make up our mind. is it something to do (when?), or is this something we're deciding not to support for now?

[shanson7]

Yes, this TODO was meant to spark discussion (forgot to include it when entering the PR). We don't have a need for meta tags in this spot, but maybe it should be supported anyway?

[Dieterbe]

How much work would it be to enrich here? cc @replay

[replay]

would be easy and relatively fast, basically just this needs to be done:

metrictank/idx/memory/memory.go

Line 1095 in 1735500

byPath[nameWithTags].MetaTags = mtr.getMetaTagsByRecordIds(enricher.enrich(def.Id.Key))

[shanson7]

I think this is the only remaining point. I'm not entirely sure when we would want to include meta tags for this endpoint, since, as @robert-milan mentions, meta tags are really just tied to other tags (albeit in a non-trivial way). Does anyone have any strong preference?

[replay]

Looks good to me. Once we have a conclusion regarding whether meta tags should be included in the result it's fine for me to merge it.

[robert-milan]

Aside from the other comments it looks fine.

[robert-milan]

Looks good to me. Once we have a conclusion regarding whether meta tags should be included in the result it's fine for me to merge it.

I feel like meta tags is a separate concept and should not be included in the results. Since meta tags themselves are just collections of tags I think it might confuse things a bit.

[Dieterbe]

ok so let's not do meta tags then yet.
when docs are updated, we can merge.

[Dieterbe]

splendid