[STORM-2169] Define Naming Convention for Metric Namespaces

• Type: Task
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: P. Taylor Goetz
• Created: 20/Oct/16 18:22
• Updated: 20/Oct/16 18:27

Description

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

Issue Links

• Is contained by: STORM-2153 New Metrics Reporting API