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