I agree it makes sense to co-own statsv. I think it
also needs to have a
primary maintainer/point of contact if issues beside basic
operational
monitoring come up (e.g. general >maintenance and updates). What do you
think?
Sounds fine. Also, probably performance team doesn't mind to contribute to
its maintenance as long as they are not in on the hook for ops.
I have created a page to ducument operational tasks, linked from :
https://wikitech.wikimedia.org/wiki/Graphite#statsv
https://wikitech.wikimedia.org/wiki/Analytics/statsv
On Mon, Nov 14, 2016 at 11:57 AM, Filippo Giunchedi <
fgiunchedi(a)wikimedia.org> wrote:
I agree it makes sense to co-own statsv. I think it
also needs to have a
primary maintainer/point of contact if issues beside basic operational
monitoring come up (e.g. general maintenance and updates). What do you
think?
thanks,
Filippo
On Mon, Nov 14, 2016 at 8:21 AM, Andrew Otto <otto(a)wikimedia.org> wrote:
+ops
Analytics (Otto & Luca) probably have the most experience with python
kafka clients, and also are the most likely to cause statsv problems, (due
to analytics kafka broker restarts, etc.). So it makes sense for us to be
at least partially responsible.
On the other hand, statsv is for operational/performance metrics, so it’d
be good if ops/performance folks had their eyes on it too. Can ops
monitoring (Filippo?) and analytics co-own this service? I can do some
work soon to update the Kafka client, but we should all know how it works
and be ready and willing to modify or restart it.
_______________________________________________
Ops mailing list
Ops(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops
_______________________________________________
Ops mailing list
Ops(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops