Page MenuHomePhabricator

replace txstatsd
Closed, ResolvedPublic

Description

txstatsd is maxed out on graphite1001, this is to track its replacement with something more performant/efficient. note this is different than the long-term plan for statsd in T89857

Related Objects

Event Timeline

fgiunchedi claimed this task.
fgiunchedi raised the priority of this task from to High.
fgiunchedi updated the task description. (Show Details)
fgiunchedi added projects: Graphite, acl*sre-team.
fgiunchedi added subscribers: fgiunchedi, mark, Aklapper.
fgiunchedi added a subscriber: ori.Feb 20 2015, 4:29 PM

one candidate to replace txstatsd is https://github.com/armon/statsite . Looking at what txstatsd types we are using it seems statsite doesn't support meter type in https://github.com/armon/statsite/issues/77 so we'll need to switch metrics from meter to counter (related to https://gerrit.wikimedia.org/r/#/c/191854/ too which @ori proposed)

so far it seems eventlogging and jobrunner are using meters, and the mw hierarchy which I don't where it comes from. I have a full list of metrics available too if needed.

did some tests by piping statsd-tg into both txstatsd and statsite and compare outputs:

txstatsd

c.000000.count 3 1424692011
ms.000002.999percentile 1022.0 1424692011
ms.000002.99percentile 1011.0 1424692011
ms.000002.count 92635.0 1424692011
ms.000002.max 1024.0 1424692011
ms.000002.mean 510.559339 1424692011
ms.000002.min 1.0 1424692011
ms.000002.rate 863.4 1424692011
ms.000002.stddev 295.404869 1424692011
g.000004.value -24.0 1424692011
statsd.filippo-test-trusty.destinations.localhost_2004_None.attemptedRelays.value 37.0 1424692011
statsd.filippo-test-trusty.destinations.localhost_2004_None.sent.value 37.0 1424692011
.statsd.filippo-test-trusty.numStats 8 1424692011
.statsd.filippo-test-trusty.flush.counter.count 2 1424692011
.statsd.filippo-test-trusty.flush.counter.duration 0.23889541626 1424692011
.statsd.filippo-test-trusty.flush.gauge.count 4 1424692011
.statsd.filippo-test-trusty.flush.gauge.duration 0.192880630493 1424692011
.statsd.filippo-test-trusty.flush.meter.count 0 1424692011
.statsd.filippo-test-trusty.flush.meter.duration 0.00381469726562 1424692011
.statsd.filippo-test-trusty.flush.timer.count 2 1424692011
.statsd.filippo-test-trusty.flush.timer.duration 1.66416168213 1424692011
.statsd.filippo-test-trusty.flush.plugin.count 0 1424692011
.statsd.filippo-test-trusty.flush.plugin.duration 0.00214576721191 1424692011
.statsd.filippo-test-trusty.receive.c.count 102454 1424692011
.statsd.filippo-test-trusty.receive.c.duration 355.430841446 1424692011
.statsd.filippo-test-trusty.receive.ms.count 103242 1424692011
.statsd.filippo-test-trusty.receive.ms.duration 2078.74321938 1424692011
.statsd.filippo-test-trusty.receive.g.count 102861 1424692011
.statsd.filippo-test-trusty.receive.g.duration 452.476978302 1424692011

statsite

c.000000 3152672.000000 1424692660
numStats 5604462.000000 1424692660
ms.000002.sum 358707110.000000 1424692660
ms.000002.sum_sq 244904447370.000000 1424692660
ms.000002.mean 512.164355 1424692660
ms.000002.lower 1.000000 1424692660
ms.000002.upper 1024.000000 1424692660
ms.000002.count 700375 1424692660
ms.000002.stdev 295.573964 1424692660
ms.000002.median 513.000000 1424692660
ms.000002.p95 966.000000 1424692660
ms.000002.p99 1024.000000 1424692660
ms.000002.rate 5978451.833333 1424692660
g.000005 -25.000000 1424692660
s.000006 128 1424692660

this is missing extended_counters from statsite which adds more stats to counters:

c.000000.count 617687 1424693131
c.000000.mean 4.495380 1424693131
c.000000.stdev 2.290765 1424693131
c.000000.sum 2776738.000000 1424693131
c.000000.sum_sq 15723864.000000 1424693131
c.000000.lower 1.000000 1424693131
c.000000.upper 8.000000 1424693131
c.000000.rate 46278.966667 1424693131

so notably missing from statsite are a bunch of self-report metrics broken down by type, plus some metrics about graphite flushing which we belong to the graphite sink and it is easy to change anyway

GWicke added a subscriber: GWicke.EditedFeb 23 2015, 7:38 PM

It would be great if the replacement supported multi-metric packets as in
statsd. This can help to reduce the load on clients and the server whenever several metrics are sent at once (which is fairly common).

Generally, we should be able to scale out whatever statsd daemon we are using with load balancing (i.e.: LVS, iptables, statsd proxy). This should work fine as long as

  • the flush period of those statsd instances is shorter than the aggregation period in graphite (1/5?), and
  • storage aggregation in graphite is set up as described in these docs.
  • the flush period of those statsd instances is shorter than the aggregation period in graphite (1/5?)

Why?

btw this is strictly to replace txstatsd with something more performant but keep things otherwise the same, there's a related discussion in T89857 about broader changes

  • the flush period of those statsd instances is shorter than the aggregation period in graphite (1/5?)

Why?

If the statsd flush period is longer, then there will be gaps in graphite data as not all aggregation periods will receive input from statsd.

  • the flush period of those statsd instances is shorter than the aggregation period in graphite (1/5?)

Why?

If the statsd flush period is longer, then there will be gaps in graphite data as not all aggregation periods will receive input from statsd.

I'm thinking by 1/5 you mean: For every aggregation "bucket" in graphite, say 50 seconds, we should flush statsd to it 5 times? You are going to be getting smaller actual aggregate periods than reported, and you are going to be clobbering any gauge data especially. Part of a healthy statsd/graphite setup is that the time to flush the data is taken into account usually as a matter of being less than one interval.

Say we collect and flush data every 10 seconds. That means we are creating 10 second aggregates, and at the end of this the "last gauge" wins. But all in all we are 'thinking' in 10 second increments. If we store this as something other than 10 second increments in graphite by saying "well we want to flush every 10 seconds but only store every 50 seconds of granularity by default". We are not getting value here we are just wasting cycles. Graphite overwrites the old data with the new every time it receives it but posterity will get the value of the last flushed data only. It will not represent the actual aggregation period marked for the bucket. When averaging is done to move the data out into larger sample sizes it will not be 50 second averages turned into hour averages, it will be 50 second averages of the last 10 second average who "won" turned into 1 hour averages. There are various functions in graphite that count on this being sane and in this situation it would not be. In my experience it will create misunderstanding, and is really misleading as well as just generally not being useful.

A flush needs to take less than the aggregation period. You collect for 10 seconds, and then flush, and that flush has to finish before the next one starts. This is the hallmark of a healthy system.

GWicke added a comment.EditedFeb 23 2015, 10:38 PM

You are going to be getting smaller actual aggregate periods than reported, and you are going to be clobbering any gauge data especially.

Not with the aggregation settings I linked to. They explicitly replace 'last write wins' with min, max, summing or averaging.

You are going to be getting smaller actual aggregate periods than reported, and you are going to be clobbering any gauge data especially.

Not with the aggregation settings I linked to. They explicitly replace 'last write wins' with min, max, summing or averaging.

The last write wins idea here "... posterity will get the value of the last flushed data only" I didn't mean the averaging logic within Graphite. I do understand what you are saying here I think, but it doesn't have to do with what I mean. If you store 1 minute granularity in Graphite, and then flush 10 second granularity from Statsd. Outside of any aggregation logic at all you are telling Graphite you only care about a minutes worth of data. Say I flush at 10s and then 20s. Only the 20s dataset will survive because we told Graphite we only care about the larger bucket. When that 1 minute bucket expires the last dataset flushed within the boundary is saved as 1 minute of data. We can say to sum this, or average it, or take some certain percentile or whatever. But if we sum 3 minutes of 10 second averages, we only have 30 seconds worth of total data. When we then use http://graphite.readthedocs.org/en/latest/functions.html#graphite.render.functions.perSecond or some other function that assumes the data has been normalized sanely we will get results that are far from the source system reality.

The link there only matters when downsampling data?

What I am talking about is the inherent badness of saving small averages inside of large buckets because we are going to operate on them as if they were representative of whatever actual increment in Graphite they will appear to be.

GWicke added a comment.EditedFeb 23 2015, 11:06 PM

Hmm, if I understand you correctly you are saying that it's not possible to aggregate several flushes in graphite. That would indeed be a bummer, as it would make it hard to parallelize statsds feeding into graphite. The aggregation-rules.conf docs seem to suggest that per-time-period aggregation on the way in is possible though. It seems to be pattern-based, so at first sight it looks like it could handle similar suffix patterns as described for storage aggregation in the statsd docs.

Hmm, if I understand you correctly you are saying that it's not possible to aggregate several flushes in graphite. That would indeed be a bummer, as it would make it hard to parallelize statsds feeding into graphite. The aggregation-rules.conf docs seem to suggest that per-time-period aggregation on the way in is possible though. It seems to be pattern-based, so at first sight it looks like it could handle similar suffix patterns as described for storage aggregation in the statsd docs.

This is where it gets weird.

So the first article is not referring to in-flight metrics at all. So when we say "...replace 'last write wins' with min, max, summing or averaging." in the context of not-yet-disk-written metrics this is not correct. But the article on the pre-cache aggregator sort of does a version of what you are thinking, yes. Graphite has a way to take a.b.you and a.b.me and drop an a.b.us onto disk. It's not especially lovable in terms of maintenance since every relationship has to be defined with a output_template (frequency) = method input_pattern style parameter. I have seen this used to pretty decent effect, yes, but that isn't (as far as I know) the primary intention for a proposed staggered deployment of statsd. I haven't seen anyone do it, but you can use this same logic to do the a.b.c from me, a.b.c from you, and a.b.c from us. That is more or less what you have in mind I think. But this makes little sense unless you doing a straight SUM in graphite terms or a SET in Statsd terms. If we submit "Counters" to Statsd with no sampling rate it will be divided by the flush time. We submit 10 1's and we get a 1 out the other end. If we then average that in Graphite by submitting the metrics more often we will be getting averages, of averages, which are then averaged again when they are rolled up on disk. Or we could get sums of averages that are then summed or averaged again. If we say that any Counter has a SUM operation performed in Graphite, so as we are flushing 1@0.1c as 10 we we are still getting an equivalent number over multiple flushes for common metric paths. But in that case are not gaining anything by separating the logic between multiple systems, we are just making things harder to debug. It doesn't make any sense. More to the point, it doesn't add any value.

If we send a "Gauge" to Statsd, and then flush those every 10 seconds for a 1 minute bucket in Graphite, we will be doing an average of a set of Gauges. This is explicitly contrary to the Gauge data type chosen at the source on submission to Statsd. This also doesn't make any sense.

If we allocate a Statsd instance horizontally (by service or team or whatever) and flush for a batch of metrics once per interval that matches the smallest Graphite increment, and then track to ensure that the actual flush time does not exceed that interval we will be doing the most sane and deterministic thing.

GWicke added a comment.EditedFeb 24 2015, 10:37 PM

@Chase, we do have a need to aggregate global stats per service, with many service instances feeding into the same value. We can indeed manually assign statsd instances per service, but if there was a solution to solve this generically with LVS or the like that'd be a cleaner abstraction. I am still not sure there is such a solution though.

Re output_template (frequency) = method input_pattern style parameters: The idea was to use this as input_template (frequency) = method input_template, with method and pattern basically matching the aggregation settings in the statsd docs. I haven't tried it though, so maybe there's a catch I'm overlooking.

The effect would basically be the same as with staggered statsds, except that there would be no SPOF with a single master statsd feeding into graphite.

btw T89857 contains an alternative approach/solution, can we discuss it there please? :)

Change 192791 had a related patch set uploaded (by Filippo Giunchedi):
graphite: do not aggregate counters by sum

https://gerrit.wikimedia.org/r/192791

Change 192792 had a related patch set uploaded (by Filippo Giunchedi):
graphite: extend aggregation for statsite extended counters

https://gerrit.wikimedia.org/r/192792

so talking a bit more with @ori about meters vs counters it turns out that for the most part we are interested in rates, so even using counters would work, except that the effective rate is per flush interval instead of per second (so per minute in our case) like in this graph (shows also switching to different rates by sleeping 1 or 10) and also the difference between statsd extended counters and simple (biggest difference is that extended counters export 6x more metrics related to the counter)

#!/usr/bin/env python

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

while True:
   try:
       s.sendto("counter.extended:1|c", ('localhost', 8135) )
       s.sendto("counter.simple:1|c", ('localhost', 8145) )
   except socket.error:
       pass
   print "sent 1 sample, sleeping"
   time.sleep(1)

so to migrate to statsite we'd need to:

  • change aggregation policy for .count metrics to average, see https://gerrit.wikimedia.org/r/#/c/192791/
  • adjust aggregation policy to consider .lower and .upper to be the same as .min and .max for extended counters, see https://gerrit.wikimedia.org/r/#/c/192792/
  • rename metrics from txstatsd names to statsite names
    • this means shutting graphite down
    • gauges lose their .value postfix
    • timers have percentiles renamed from XXXpercentile to pXXX
    • timers have min / max renamed to lower / upper
  • replace txstatsd with statsite
    • so we won't be able to accept meter metrics anymore
  • change applications pushing meters to push counters instead, namely:
    • eventlogging
    • mediawiki (via wgStatsFormatString)
    • puppet:modules/mediawiki/files/monitoring/mwerrors.py
    • puppet:modules/webperf/files/deprecate.py
    • ocg

I've counted ~5.7k meters at the moment on graphite1001, using extended counters pushes 6 more metrics (lower, mean, stddev, sum, sum_sq, upper) so at 1MB each that means +35GB of storage

GWicke added a comment.EditedFeb 25 2015, 6:04 PM

change aggregation policy for .count metrics to average

Averaging .count metrics should be incorrect no matter what model statsite is using.

If it follows what we are doing so far & what etsy statsd is doing, then .count would be a monotonically growing counter, optionally enriched with a computed .rate metric:

"Statsd will send both the rate as well as the count at each flush."

Either way, aggregation for .count should to be sum, not average. For .rate it's more complicated as the time base needs to be taken into account. If multiple statsite daemons can send reports in a single aggregration period, then sum with an optional time base adjustment factor would probably be the right thing to do. For storage otoh averaging should be fine.

Change 192791 abandoned by Filippo Giunchedi:
graphite: do not aggregate counters by sum

Reason:
agreed it doesn't seem the right thing to do

https://gerrit.wikimedia.org/r/192791

Change 192792 merged by Ori.livneh:
graphite: extend aggregation for statsite extended counters

https://gerrit.wikimedia.org/r/192792

Change 193095 had a related patch set (by Filippo Giunchedi) published:
import upstream 0.7.0

https://gerrit.wikimedia.org/r/193095

Change 193096 had a related patch set (by Filippo Giunchedi) published:
import debian directory

https://gerrit.wikimedia.org/r/193096

Change 193097 had a related patch set (by Filippo Giunchedi) published:
add debian patches to upstream

https://gerrit.wikimedia.org/r/193097

I've published a first iteration on statsite debian package in the last three gerrit changes above

Change 193117 had a related patch set uploaded (by Filippo Giunchedi):
txstatsd: collect udp stats

https://gerrit.wikimedia.org/r/193117

Change 193117 merged by Filippo Giunchedi:
txstatsd: collect udp stats

https://gerrit.wikimedia.org/r/193117

Change 193095 merged by Filippo Giunchedi:
import upstream 0.7.0

https://gerrit.wikimedia.org/r/193095

Change 193096 merged by Filippo Giunchedi:
import debian directory

https://gerrit.wikimedia.org/r/193096

Change 193097 merged by Filippo Giunchedi:
add debian patches to upstream

https://gerrit.wikimedia.org/r/193097

fgiunchedi reopened this task as Open.Mar 25 2015, 11:10 AM

reopening, still need to replace txstatsd with statsite

Change 199599 had a related patch set uploaded (by Filippo Giunchedi):
statsite: new module

https://gerrit.wikimedia.org/r/199599

Change 199600 had a related patch set uploaded (by Filippo Giunchedi):
statsdlb: replace txstatsd with statsite

https://gerrit.wikimedia.org/r/199600

ok so ignoring for now mediawiki and eventlogging meters these are the ones that will stop working:

graphite1001:~$ grep 'txstatsd meter' rename-all.log | grep -v -e /whisper/jobrunner/ -e /whisper/eventlogging/ -e /whisper/MediaWiki/ -e /whisper/mw/ | less
/var/lib/carbon/whisper/ocg/pdf/backend/restarts is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/frontend/request_errors is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/frontend/requests/download is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/frontend/requests/download_file is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/frontend/requests/health is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/frontend/requests/render is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/frontend/requests/render/cached is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/frontend/requests/render_status is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/frontend/restarts is interesting, txstatsd meter
/var/lib/carbon/whisper/ocg/pdf/gc/restarts is interesting, txstatsd meter
/var/lib/carbon/whisper/parsoid/wt2html/parse/wt/count is interesting, txstatsd meter
/var/lib/carbon/whisper/parsoid/wt2html/parse/pageWithOldid/count is interesting, txstatsd meter
/var/lib/carbon/whisper/parsoid/wt2html/parse/redirectToOldid/count is interesting, txstatsd meter
/var/lib/carbon/whisper/parsoid/wt2html/redirectToOldid is interesting, txstatsd meter
/var/lib/carbon/whisper/parsoid/html2wt/serialize/selser/count is interesting, txstatsd meter
/var/lib/carbon/whisper/parsoid/html2wt/serialize/none/count is interesting, txstatsd meter
/var/lib/carbon/whisper/parsoid/html2wt/serialize/full/count is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/zotero/req/200 is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/zotero/req/501 is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/zotero/req/504 is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/zotero/req/500 is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/zotero/req/400 is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/zotero/req/300 is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/input/url is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/input/doi is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/input/pmcid is interesting, txstatsd meter
/var/lib/carbon/whisper/citoid/input/pmid is interesting, txstatsd meter
GWicke added a comment.EditedMar 26 2015, 6:05 PM

Which changes do you expect in computed metrics like rate, percentiles, mean / median etc? Will the keys be the same, so that dashboards keep working?

Edit: Filippo pointed me to his earlier post. It seems that quite a few the derived metric names will change:

  • percentiles
  • min/max

It doesn't seem to be easy to get statsite to use the same names as (tx)statsd.

My main worry is that the custom metric names will break quite a few dashboards, and will also make it hard to move away from statsite later.

the basic steps of the transition including renaming are here: https://phabricator.wikimedia.org/T90111#1065553

essentially:

  • rename metrics from txstatsd names to statsite names
    • this means shutting graphite down
    • gauges lose their .value postfix
    • timers have percentiles renamed from XXXpercentile to pXXX
    • timers have min / max renamed to lower / upper

or in other words, this

#!/usr/bin/env python
import sys
import os

def rename_gauge(path):
    src_file = os.path.join(path, 'value.wsp')
    dst_file = path + '.wsp'
    print "os.rename(%s, %s)" % (src_file, dst_file)
    print "os.rmmdir(%s)" % path
    #os.rename(src_file, dst_file)
    #os.rmmdir(path)


def rename_timer(path):
    TIMER_RENAMES = {
        '999percentile': 'p999',
        '99percentile': 'p99',
        'max': 'upper',
        'min': 'lower',
    }
    for src, dst in TIMER_RENAMES.iteritems():
        src_file = os.path.join(path, src + '.wsp')
        dst_file = os.path.join(path, dst + '.wsp')
        if os.path.exists(src_file):
            print "os.rename(%s, %s)" % (src_file, dst_file)


# XXX only if _not_ using extended counters in statsite, otherwise noop
def rename_counter(path):
    src_file = os.path.join(path, 'count.wsp')
    dst_file = path + '.wsp'
    print "os.rename(%s, %s)" % (src_file, dst_file)
    print "os.rmmdir(%s)" % path
    #os.rename(src_file, dst_file)
    #os.rmmdir(path)


def process_path(path):
    TXSTATS_TIMERS = set(['count.wsp', 'mean.wsp', 'min.wsp', 'rate.wsp',
                          '99percentile.wsp', '999percentile.wsp',
                          'stddev.wsp', 'max.wsp'])

    for dirpath, dirnames, filenames in os.walk(path):
        if filenames == ['value.wsp']:
            print "%s is interesting, txstatsd gauge" % dirpath
            rename_gauge(dirpath)
        elif filenames == ['count.wsp']:
            print "%s is interesting, txstatsd counter" % dirpath
            rename_counter(dirpath)
        elif TXSTATS_TIMERS.issubset(set(filenames)):
            print "%s is interesting, txstatsd timer" % dirpath
            rename_timer(dirpath)
        elif set(filenames) == set(['count.wsp', 'rate.wsp']):
            print "%s is interesting, txstatsd meter" % dirpath
        elif filenames:
            print "%s type unknown: %r" % (dirpath, filenames)
        elif not filenames:
            print "%s empty dir, skipping" % dirpath
        else:
            print "%s unknown" % dirpath


def main():
    dirs = sys.argv[1:]
    for d in dirs:
        process_path(d)


if __name__ == '__main__':
    sys.exit(main())

For the record, it looks like statsite and statsd actually agree on lower/upper (txstatsd is the odd one out with min/max), but none of those agree on percentiles. So, +1 for going with native statsite names.

Change 202701 had a related patch set uploaded (by Filippo Giunchedi):
statsite: replace ::txstatsd class and role calls

https://gerrit.wikimedia.org/r/202701

Change 199599 merged by Filippo Giunchedi:
statsite: new module

https://gerrit.wikimedia.org/r/199599

Change 199600 merged by Filippo Giunchedi:
statsdlb: replace txstatsd with statsite

https://gerrit.wikimedia.org/r/199600

Change 202701 merged by Filippo Giunchedi:
statsite: replace ::txstatsd class and role calls

https://gerrit.wikimedia.org/r/202701

Seems to generally work well. Thank you, Filippo!

One issue I noticed is T95596: Urgent: Statsite changes semantics of timer rate metrics, need metric rename.

Change 203289 had a related patch set uploaded (by Krinkle):
Update graphs for property renames in Graphite

https://gerrit.wikimedia.org/r/203289

Change 203289 merged by jenkins-bot:
Update graphs for property renames in Graphite

https://gerrit.wikimedia.org/r/203289

Change 203829 had a related patch set uploaded (by Filippo Giunchedi):
varnishkafka: fix spurious UNKNOWN alert

https://gerrit.wikimedia.org/r/203829

Change 203829 merged by Filippo Giunchedi:
varnishkafka: fix spurious UNKNOWN alert

https://gerrit.wikimedia.org/r/203829

Change 203839 had a related patch set uploaded (by Filippo Giunchedi):
deprecate statsd meters

https://gerrit.wikimedia.org/r/203839

Change 203843 had a related patch set uploaded (by Filippo Giunchedi):
mediawiki: deprecate meters in mwerrors.py

https://gerrit.wikimedia.org/r/203843

Change 203844 had a related patch set uploaded (by Filippo Giunchedi):
webperf: deprecate statsd meters

https://gerrit.wikimedia.org/r/203844

Change 203847 had a related patch set uploaded (by Filippo Giunchedi):
deprecate statsd meters

https://gerrit.wikimedia.org/r/203847

Change 203843 merged by Ori.livneh:
mediawiki: deprecate meters in mwerrors.py

https://gerrit.wikimedia.org/r/203843

Change 203844 merged by Ori.livneh:
webperf: deprecate statsd meters

https://gerrit.wikimedia.org/r/203844

Change 203847 merged by jenkins-bot:
deprecate statsd meters

https://gerrit.wikimedia.org/r/203847

Change 203839 merged by Ori.livneh:
deprecate statsd meters

https://gerrit.wikimedia.org/r/203839

Change 204237 had a related patch set uploaded (by Filippo Giunchedi):
eventlogging: adjust counters thresholds

https://gerrit.wikimedia.org/r/204237

Change 204237 merged by Filippo Giunchedi:
eventlogging: adjust counters thresholds

https://gerrit.wikimedia.org/r/204237

fgiunchedi closed this task as Resolved.Apr 16 2015, 8:49 AM

this is completed, txstatsd has been replaced by statsite