You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consul's runtime metrics place the hostname in the middle of metric names. Typically these take the form of namespace.subsystem.measurement, so in a way these runtime metrics are making the namespace also include the hostname of the current system. Ideally, the host should be identified by a label so users can more easily perform aggregates to get answers like: find the highest sum of gc pauses across the cluster with max(). With the host in the name rather than the label, an operator of a modern metrics pipeline would have to update this query individually for every host that enters the cluster. In modern systems this information is now expected to come in from the scraping or receiving backend like Prometheus or Datadog, though we can still include a host label for compatibility with systems that don't support labels.
This would be a breaking change, so we ought to deprecate the previous behavior and double-emit. Then, if we can get this in within 1.9.x point releases, we can flag the old behavior behind {telemetry = { disable_compat_1.9 = true }}.
The text was updated successfully, but these errors were encountered:
Feature Description
Consul's runtime metrics place the hostname in the middle of metric names. Typically these take the form of
namespace.subsystem.measurement
, so in a way these runtime metrics are making the namespace also include the hostname of the current system. Ideally, the host should be identified by a label so users can more easily perform aggregates to get answers like: find the highest sum of gc pauses across the cluster with max(). With the host in the name rather than the label, an operator of a modern metrics pipeline would have to update this query individually for every host that enters the cluster. In modern systems this information is now expected to come in from the scraping or receiving backend like Prometheus or Datadog, though we can still include a host label for compatibility with systems that don't support labels.This would be a breaking change, so we ought to deprecate the previous behavior and double-emit. Then, if we can get this in within 1.9.x point releases, we can flag the old behavior behind
{telemetry = { disable_compat_1.9 = true }}
.The text was updated successfully, but these errors were encountered: