>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@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@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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops

_______________________________________________
Ops mailing list
Ops@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops