Github user revans2 commented on the issue:
https://github.com/apache/storm/pull/2203
So to parse these pieces of information back out I would need to do
something like remove "storm.topology." from the beginning.
Then everything up to the next "." would be the topology-ID because "." is
not allowed in the name. I could go even further and parse out the topology
name too.
Now I am kind of in trouble, because I have two different fields that can
be anything on both ends of the name. So my best bet is to look for something
that looks like `\.(\d+)-` and hope that neither the component name nor the
metric name happens to have used something that matches that pattern.
My concern here is that most of what we are truly encoding in the name is
metadata. All of the examples that graphite and ganglia show use the name as a
hierarchy to make finding the metric I want simpler, i.e.
'system.memory.memory_allocated', or perhaps subdividing the metrics by
application, 'app1.memory.memory_allocated'. Metadata like the host name,
port, component, etc, are really supported through tags. The collectors are
not attempting to pull out the metadata and then turn it back into tags. So
for example lets start with a simple use case. I want to know how many tuples
component B has emitted. Currently that would require me to combine N separate
metrics together, one per port.
storm.topology.MYTOPO-1-1000.B.6700-emitted
storm.topology.MYTOPO-1-1000.B.6701-emitted
...
storm.topology.MYTOPO-1-1000.B.N-emitted
and then rewrite if I launch my topology again I now have to rewrite all of
my queries to match. I personally think everyone would be a lot happier if we
could find a good way to translate these into tags.
Additionally the built in metrics that mostly @abellina, and me a tiny bit,
have been working on wants these to be metadata. Simply because we cannot
reproduce what is happening on the UI in any other clean way. I am fine with
us using the metric name to store some of this metadata (sadly drop-wizard
gives us no other option), but we really need to parse it out before sending it
on. I am not sure how simple that would be, seeing how they already come with
built in reporters which was a lot of what we wanted them for. If it is not
going to be simple to do, then perhaps dropwizard was the wrong choice for a
metrics library.
---
