Using bulk metrics for the log counters reduces largely the likelihood
of blocking the Heka pipeline. Instead of injecting (x services
* y levels) metric messages, the filter injects only one big message.
This changes also updates the configuration of the metric_collector
service to deserialize the bulk metric to support alarms on log
counters.
Change-Id: Icb71fd6faa4191795c0470ecc24aeafd25794f42
Closes-Bug: #1643280
Since AFD and GSE filters use intensively the timer_event function it's
relevant to collect TimerEventAvgDuration and TimerEventSamples.
The memory used by decoders and filters is also collected.
Change-Id: Ib82eb57985a0eb2709ccd1eb5ec2e65e5810669e
This change introduces a new type of Heka message called 'bulk_metric'.
A bulk metric message can be emitted by any filter plugin using the
add_to_metric() and inject_bulk_metric() function from the lma_utils
module:
local ts = read_message('Timestamp')
utils.add_to_metric('foo', 1, {tag1 = value1})
utils.add_to_metric('bar', 2, {})
utils.inject_bulk_metric(ts, 'node-1', 'custom_filter')
The structure of the message injected in the Heka pipeline will be:
Timestamp: <ts>
Severity: INFO
Hostname: node-1
Payload: >
[{"name":"foo","value":1,"tags":{"tag1":"value1"}},
{"name":"bar","value":2,"tags":[]}]
Fields:
- source: custom_filter
- hostname: node-1
Eventually the bulk metric message is caught by the InfluxDB
accumulator filter and encoded using the InfluxDB line protocol.
Change-Id: I96986fd8287d65ae018c7636f9dd745dba2fc761
Implements: blueprint upgrade-influxdb-grafana
This change adds information about the number of messages that are
processed by every decoder and filter of the LMA collector and also
the average time it takes to process these messages.
Change-Id: Iad122336fe8fcb6fa3f4d8ed666b276f6db70a43
Andreas Jaeger