As much as I like the idea, I tried to find any real life use case for it. Biggest issue for me is that such subsystem will spam my email/jabber account with too much messages and that will make it unusable.
* in case of application internal errors it's much better to use tools like airbrake/errbit, not on I will be notified much less frequently, I will alway have much more usefull information about the issue * in case of 404 or other events that are not directly errors that needs to be resolved, but rather pointers that suggest that there might be an error (for example if number of 404 per second spikes up, it might mean that there is invalid css or js file linked in my app) IMHO it's better to use log analyzer tools like graylog2, I can create a stream there and set some limits for number of logs that contains some pattern But one thing that I could use it for is tracking harakiri with errbit, I could hookup log-alarm with some handler that would push harakiri backtrace to errbit so that I could analyze if I'm have the same issue all the time, or is it random view that is causing harakiri. But I'm not sure if I could do this with log-alarm since it works per log line and backtrace is logged as multiple log lines, so the only thing I can get using it is the url on which harakiri occured. To get around this harakiri would need to push whole backtrace as single log message or log-alarm would need to be able to extract more lines from log, not only one, for example: --log-alarm handler,"some text that triggers alarm":"text that ends alarm log collection" Once alarm subsystem notices first pattern in logs it starts collecting log messages until it finds second pattern (or some log lines count limit). Once all log messages are collected than we trigger alarm handler. -- Łukasz Mierzwa _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
