2016-09-25 4 views
2

ログファイルが回転するたびにアプリケーションスレッドが停止し、APIの待ち時間が急増する 私は非同期アペンダーを使用していますが、待っている。私たちは、Dropwizardログの非同期ログの回転によりアプリケーションスレッドが待機する

<property name="async.discardingThreshold" value="0"/> 

を指定している

logback.xml当社logback.xmlで

<configuration debug="true"> 
<property name="async.discardingThreshold" value="0"/> 
<property name="async.queueSize" value="500"/> 
<property name="log.dir" value="/var/log"/> 
<property name="log.pattern" value="%highlight(%-5level) [%date] [%thread] [%X{id}] [%cyan(%logger{0})]: %message%n"/> 
<property name="errorLog.pattern" value="%highlight(%-5level) [%date] [%thread] [%X{id}] [%red(%logger{0})]: %message%n"/> 
<property name="log.maxHistory" value="200"/> 
<property name="log.default.maxFileSize" value="100MB"/> 
<property name="log.error.maxFileSize" value="10MB"/> 


<appender name="INFO" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
    <File>${log.dir}/default.log</File> 
    <Append>true</Append> 
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> 
     <fileNamePattern>${log.dir}/default.%i.log.gz</fileNamePattern> 
     <maxIndex>${log.maxHistory}</maxIndex> 
    </rollingPolicy> 
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> 
     <maxFileSize>${log.default.maxFileSize}</maxFileSize> 
    </triggeringPolicy> 
    <encoder> 
     <pattern>%replace(${log.pattern}){'"pin":"\d+"','"pin":"XXXX"'}%n</pattern> 
    </encoder> 
</appender> 

<appender name="ASYNC-INFO" class="ch.qos.logback.classic.AsyncAppender"> 
    <discardingThreshold>${async.discardingThreshold}</discardingThreshold> 
    <queueSize>${async.queueSize}</queueSize> 
    <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> 
     <OnMismatch>DENY</OnMismatch> 
     <OnMatch>NEUTRAL</OnMatch> 
    </filter> 
    <appender-ref ref="INFO"/> 
</appender> 

<appender name="ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
    <file>${log.dir}/error.log</file> 
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> 
     <fileNamePattern>${log.dir}/error.%i.log.gz</fileNamePattern> 
     <maxIndex>${log.maxHistory}</maxIndex> 
    </rollingPolicy> 
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> 
     <maxFileSize>${log.error.maxFileSize}</maxFileSize> 
    </triggeringPolicy> 
    <encoder> 
     <pattern>%replace(${errorLog.pattern}){'"pin":"\d+"','"pin":"XXXX"'}%n</pattern> 
    </encoder> 
</appender> 

<appender name="ASYNC-ERROR" class="ch.qos.logback.classic.AsyncAppender"> 
    <discardingThreshold>${async.discardingThreshold}</discardingThreshold> 
    <queueSize>${async.queueSize}</queueSize> 
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> 
     <level>ERROR</level> 
    </filter> 

    <appender-ref ref="ERROR"/> 
</appender> 


<root level="INFO"> 
    <appender-ref ref="ASYNC-ERROR"/> 
    <appender-ref ref="ASYNC-INFO"/> 
</root> 

答えて

2

は今のソースコードで簡単に見にある、おそらくそれが起こってかもしれないものを示しています回転時に遅れが生じる。

@Override 
    protected void append(E eventObject) { 
    if (isQueueBelowDiscardingThreshold() && isDiscardable(eventObject)) { 
     return; 
    } 
    preprocess(eventObject); 
    put(eventObject); 
    } 
    private boolean isQueueBelowDiscardingThreshold() { 
    return (blockingQueue.remainingCapacity() < discardingThreshold); 
    } 

blockingQueue.remainingCapacity()< discardingThresholdの場合、廃棄しきい値が0の場合、この条件は評価されません。つまり、async-appenderスレッドはすでに完全なブロックキューにプッシュしようとします。それを待ってアプリケーションスレッドも待機させます。 この値を0以上に設定すると、タイムアウトは発生しませんが、一部のイベントが失われる可能性があります。 破棄せずにすべてのイベントを保持するもう1つのオプションは、ファイルのローテーションの瞬間にキューのキューサイズを大きくすることです。この場合、async-appenderスレッドはブロッキングキューで待機しません。

だから私の発見は、メッセージの着信率がキュー消費率を超え、廃棄率は0

ある場合logback AsyncAppenderは非同期ので ではありません