Fabian Groffen
Fabian Groffen
The aggregator should in an ideal case not drop metrics. It records metrics to be dropped if: - a metric was received with a timestamp too far in the past...
can you share your aggregation rule you use?
just an observation: ``` match ^agg\. send to radar122 ; match ^agg\. send to blackhole stop; ``` this can be done in one statement: ``` match ^agg\. send to radar122...
So in terms of busyness, how does the cpu-usage of the relay look like? I would be interested if you could test the latest master branch, it contains an aggregator...
if you run the relay in "debug" mode (`-d`) you should get a message in the log about "aggregator: dropping metric too far in the future" Unfortunately in this mode...
That's 14 minutes (!) ahead. Are the clocks synced? The timestamps that is reported as exceeded is translated to human time matching the log record time, which seems to suggest...
the load clogs it up, this is still an issue
I need to find a way in which to do aggregations in parallel.
Can you give an example of what your mean with fnv1a_ch key as hostname? To produce the metrics like you suggest, an aggregation has to be made, since the collection...
I see, you want a cluster-oriented stats thing. The collector doesn't really know about topologies or anything, so it's hard to do this.