It makes sense to have a channel to communicate scheduled downtimes or any major code change affecting the responses and I agree it doesn't need to be the same outlet as automated alerts.

On Apr 15, 2013, at 8:03 PM, Diederik van Liere <dvanliere@wikimedia.org> wrote:

Hi Erik,

I have some hesitations; it makes it less clear who is supposed to troubleshoot UMAPI and probably nobody besides Ops can actually do anything. I do agree that we should think about setting up automatic monitoring and alerting, preferably using our existing Ganglia / Nagios infrastructure but I will leave it to Ottomata to comment on the technical implementations.

So yes to monitoring & alerts, not sure if a mailinglist is the best outlet.
D

On Mon, Apr 15, 2013 at 10:01 PM, Erik Moeller <erik@wikimedia.org> wrote:

As Ori put the EventLogging service into production he created an
eventlogging-alerts list to keep developers and users of EventLogging
data informed about any service or data quality issues.

The user metrics API is quickly becoming relevant to multiple teams in
the org who will likely also need to stay informed about similar kinds
of issues, whether through automatic notifications or manual emails.
Not all of them will want to be on analytics@, and not all folks on
this list will care about the nitty-gritty.

Would it make sense to setup umapi-alerts to serve the same purpose as
eventlogging-alerts, but for the user metrics API?

Cheers,
Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics

_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics