P. Taylor Goetz created STORM-2169:
--------------------------------------

             Summary: Define Naming Convention for Metric Namespaces
                 Key: STORM-2169
                 URL: https://issues.apache.org/jira/browse/STORM-2169
             Project: Apache Storm
          Issue Type: Sub-task
            Reporter: P. Taylor Goetz


Code Hale's metrics library allows you to define names for metrics and the 
ability to group metrics in separate {{MetricRegistry}}s.

One important consideration, particularly when it comes to aggregating metrics, 
is the naming convention and metrics hierarchy.

One approach would be to have a high-level grouping based on the 
service/process a metric belongs to (similar to how Storm's configuration keys 
are namespaced). For example:

*Topology Metrics*
{{storm.topology.*}}

*Worker Metrics*
{{storm.worker.*}}

Building on that naming convention would allow for implicit hierarchy that 
would enable metric aggregation at various levels. For example, if an "emitted" 
metric were named such that it identifies the path to the individual component, 
e.g.:

{{storm.topology.$topology_name.$worker_host.$worker_port.$component_id.emitted}}

Then when the metric hit the metric store, various levels of aggregation could 
be achieved by parsing the metric name and iterating right to left over the 
tokens in the path and updating the value in the database.

For the example above, this would yield the following aggregated metrics:

*Component Level (not aggregated)*
{{storm.topology.$topology_name.$worker_host.$worker_port.$component_id.emitted}}

*Worker Level*
{{storm.topology.$topology_name.$worker_host.$worker_port.emitted}}

*Host Level*
{{storm.topology.$topology_name.$worker_host.emitted}}

*Topology Level*
{{storm.topology.$topology_name.emitted}}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to