[
https://issues.apache.org/jira/browse/STORM-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
P. Taylor Goetz updated STORM-2169:
-----------------------------------
Issue Type: Task (was: Sub-task)
Parent: (was: STORM-2153)
> Define Naming Convention for Metric Namespaces
> ----------------------------------------------
>
> Key: STORM-2169
> URL: https://issues.apache.org/jira/browse/STORM-2169
> Project: Apache Storm
> Issue Type: 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)
