Replace `host` and `port` metric tags with `hostAddress`?
dlmarion opened this issue · 4 comments
I'm not sure there is any utility in having a separate port
tag. If the tag is concatenated, then you could find all instances of a metric on the same host by using a tag query with a wildcard (hostAddress
LIKE localhost*
) or find the metric for a specific instance by using the host and port in the tag query.
I would be curious if we would lose any comparison functionality by having to query via regex/wildcard vs selecting an available tag value.
So, we might not need to do this. I wouldn't suggest anyone work on this yet.
Was curious if this could be done w/ a MeterFilter. So tried writing the following which seems like it may work, but have not tested. Just wanted to get some hands on experience w/ MeterFilters as I have never written one.
MeterFilter filter = new MeterFilter() {
@Override
public Meter.Id map(Meter.Id id) {
var hostVal = id.getTag("host");
var portVal = id.getTag("port");
if(hostVal != null && portVal != null) {
var newTags = id.getTags().stream()
.filter(tag->!tag.getKey().equals("host") && !tag.getKey().equals("port"))
.collect(Collectors.toList());
newTags.add(new ImmutableTag("hostPort", hostVal+":"+portVal));
return id.replaceTags(newTags);
} else {
return id;
}
}
};
Was just experimenting with this, we should make this change if its the best default. Not sure what the best default is. I can not think of an use case for the stand alone port tag. As mentioned earlier there may be a case for having a drop down of available severs w/o ports to choose from, which the standalone host tag would support.
I think that the standalone host tag provides value. The port tag seems extraneous.
I agree with @keith-turner that there would be a valid use-case for having a drop-down list of hostnames that a user could select.
That's a pretty common pattern with grafana dashboards that show cross-application metrics filtered down to a single host.