¿Cómo puedo limitar la velocidad de los correos electrónicos a Logback SMTPAppender, para que me envíe un correo electrónico como máximo una vez cada n minutos?Logback SMTPAppender Limiting Rate
He configurado mi registro según el Logback appender, pero no veo cómo se configurará o subclasificará para implementarlo.
¿Hay una función oculta? ¿Alguien desarrolló una subclase para manejar esto?
Según la documentación, parece que la forma de hacerlo es escribir un EventEvaluator (ver ejemplo 4.14 y 4.15) que mira la marca de tiempo de cada evento para aceptar un evento solo cuando haya pasado "suficiente tiempo" desde el último evento fue aceptado.
Puede usar System.currentTimeMillis para obtener un número que puede usar para calcular las diferencias de tiempo. http://java.sun.com/javase/6/docs/api/java/lang/System.html#currentTimeMillis%28%29
Sugiero que se archive un artículo de jira solicitando esta función. Es probable que se implemente si solo se le pregunta.
Como Thorbjørn, es fácil crear un EventEvaluator que limite la velocidad con la que un appender dispara un mensaje.
Sin embargo, encontré Logback para admitir DuplicateMessageFilter, que resuelve mi problema probablemente de una manera amarga: "DuplicateMessageFilter merece una presentación por separado. Este filtro detecta mensajes duplicados, y más allá de cierto número de repeticiones, elimina mensajes repetidos".
BTW,
Logback v0.9.26 permite ahora para establecer el tamaño de memoria intermedia de mensajes SMTPAppender. Hasta ayer, enviaba los contenidos actuales del búfer, que eran hasta 256 mensajes, lo cual era un dolor de cabeza porque quería mostrar solo el último en el correo electrónico. Por lo tanto, ahora es posible implementar periódicamente advertencias de correo electrónico periódicas que solo conllevan un error en particular según mi interpretación de esta pregunta.
http://logback.qos.ch/manual/appenders.html#cyclicBufferSize
divertirse.
Para resolver el mismo problema he escrito un evaluador personalizado. Extiende ch.qos.logback.classic.boolex.OnMarkerEvaluator, pero puede usar cualquier otro evaluador como base. Si hay muchos mensajes aceptables en el intervalo de silencio, el evaluador los descartará. Para mi caso de uso, está bien, pero si necesita un comportamiento diferente, simplemente agregue verificaciones adicionales al segundo si.
public class LimitingOnMarkerEvaluator extends OnMarkerEvaluator {
private long lastSend = 0, interval = 0;
@Override
public boolean evaluate(ILoggingEvent event) throws EvaluationException {
if (super.evaluate(event)) {
long now = System.currentTimeMillis();
if (now - lastSend > interval) {
lastSend = now;
return true;
}
}
return false;
}
public long getInterval() {
return interval;
}
public void setInterval(long interval) {
this.interval = interval;
}
}
Config para enviar un máximo de un mensaje cada 1.000 segundo (unos 17 minutos):
<evaluator class="package.LimitingOnMarkerEvaluator">
<marker>FATAL</marker>
<interval>1000000</interval>
</evaluator>
Esta herramienta haría exactamente lo que quiere, pero no es threadsafe en absoluto: http://code.google.com/p/throttled-smtp-appender/wiki/Usage
He escrito una versión de rosca pero todavía no la he abierto.
La razón por la que tendría problemas para encontrar buenas herramientas para esto es que SMTP no es un punto final real. Use un servicio como loggly, airbrake o docenas de otros, o ejecute su propio servidor usando algo como logstash.
Eche un vistazo al nuevo apilador Whisper. Hace supresión inteligente. Disponible a través de Maven y github here
Exención de responsabilidad legal: soy el autor.
La limitación de velocidad es uno de esos problemas frustrantemente difíciles de resolver. Me sorprendería si logback tuviera una solución simple para esto. – skaffman
@skaffman, ¿puedes explicar la complejidad? Entiendo que esto puede ocultar algunos fallos, en caso de que ocurra un error crítico ligeramente después de un error menos crítico. – notnoop