luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity
open-consul/agent/consul/usagemetrics/usagemetrics_oss.go

61 lines
1.2 KiB
Go
Raw Normal View History

Report node/service usage metrics from every server Using the newly provided state store methods, we periodically emit usage metrics from the servers. We decided to emit these metrics from all servers, not just the leader, because that means we do not have to care about leader election flapping causing metrics turbulence, and it seems reasonable for each server to emit its own view of the state, even if they should always converge rapidly.
2020-09-02 15:24:17 +00:00
// +build !consulent
package usagemetrics
Emit service usage metrics with correct labeling strategy (#8856) Previously, we would emit service usage metrics both with and without a namespace label attached. This is problematic in the case when you want to aggregate metrics together, i.e. "sum(consul.state.services)". This would cause services to be counted twice in that aggregate, once via the metric emitted with a namespace label, and once in the metric emited without any namespace label.
2020-10-09 16:01:45 +00:00
import (
"github.com/armon/go-metrics"
state: partition the usage metrics subsystem (#10867)
2021-08-18 14:27:15 +00:00
"github.com/hashicorp/serf/serf"
Emit service usage metrics with correct labeling strategy (#8856) Previously, we would emit service usage metrics both with and without a namespace label attached. This is problematic in the case when you want to aggregate metrics together, i.e. "sum(consul.state.services)". This would cause services to be counted twice in that aggregate, once via the metric emitted with a namespace label, and once in the metric emited without any namespace label.
2020-10-09 16:01:45 +00:00
"github.com/hashicorp/consul/agent/consul/state"
)
Report node/service usage metrics from every server Using the newly provided state store methods, we periodically emit usage metrics from the servers. We decided to emit these metrics from all servers, not just the leader, because that means we do not have to care about leader election flapping causing metrics turbulence, and it seems reasonable for each server to emit its own view of the state, even if they should always converge rapidly.
2020-09-02 15:24:17 +00:00
state: partition the usage metrics subsystem (#10867)
2021-08-18 14:27:15 +00:00
func (u *UsageMetricsReporter) emitNodeUsage(nodeUsage state.NodeUsage) {
metrics.SetGaugeWithLabels(
[]string{"consul", "state", "nodes"},
float32(nodeUsage.Nodes),
u.metricLabels,
)
}
func (u *UsageMetricsReporter) emitMemberUsage(members []serf.Member) {
var (
servers int
clients int
)
for _, m := range members {
switch m.Tags["role"] {
case "node":
clients++
case "consul":
servers++
}
}
metrics.SetGaugeWithLabels(
[]string{"consul", "members", "clients"},
float32(clients),
u.metricLabels,
)
metrics.SetGaugeWithLabels(
[]string{"consul", "members", "servers"},
float32(servers),
u.metricLabels,
)
}
Emit service usage metrics with correct labeling strategy (#8856) Previously, we would emit service usage metrics both with and without a namespace label attached. This is problematic in the case when you want to aggregate metrics together, i.e. "sum(consul.state.services)". This would cause services to be counted twice in that aggregate, once via the metric emitted with a namespace label, and once in the metric emited without any namespace label.
2020-10-09 16:01:45 +00:00
func (u *UsageMetricsReporter) emitServiceUsage(serviceUsage state.ServiceUsage) {
metrics.SetGaugeWithLabels(
[]string{"consul", "state", "services"},
float32(serviceUsage.Services),
u.metricLabels,
)
metrics.SetGaugeWithLabels(
[]string{"consul", "state", "service_instances"},
float32(serviceUsage.ServiceInstances),
u.metricLabels,
)
}