chukwa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CHUKWA-646) FileTailingAdaptor can't handle the file rotating rightly and the checkpoint size is wrong
Date Mon, 16 Jul 2012 04:14:33 GMT

    [ https://issues.apache.org/jira/browse/CHUKWA-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414840#comment-13414840
] 

Eric Yang commented on CHUKWA-646:
----------------------------------

Thanks Ivy.
                
> FileTailingAdaptor can't handle the file rotating rightly and the checkpoint size is
wrong
> ------------------------------------------------------------------------------------------
>
>                 Key: CHUKWA-646
>                 URL: https://issues.apache.org/jira/browse/CHUKWA-646
>             Project: Chukwa
>          Issue Type: Bug
>          Components: Data Collection
>    Affects Versions: 0.4.0, 0.5.0
>         Environment: OpenJDK 64-Bit 1.6.0-20
> Linux 2.6.18-308.1.1.el5
>            Reporter: IvyTang
>            Assignee: IvyTang
>              Labels: patch
>             Fix For: 0.6.0
>
>         Attachments: filetailing_trunk.patch, tailfile.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Our team has used chukwa CharFileTailingAdaptorUTF8 to collect the log4j rotated log
files for several months.It does help us to collect the logs from everywhere to our hadoop
center.
> During the work , we met several problems . And i have raised them in this mail list
, but i still haven't got a good solution.
> So we  read the source code , and did some changes
> Our log files are generated by the log4j ,and the log4j appender is org.apache.log4j.DailyRollingFileAppender.
> If you use log4j to generate the rotated log ,may this mail will help you.
> These two problems are the causes why we have to modify the source code.
> 1. The mismatching checkpoint size and file size.
>      I raised this problem in May 14 ,"the check point offset is bigger than the log
file size". And Ariel Rabkin  and Eric have answered my question , thanks for your replies.
>      When chukwa starts, it will read the the check point file , let the size be the
filereadoffset. The size in the checkpoint indicates how many bytes the adaptor has send .
>      If the log source is stream or a file won't rotate , this size is right ,it indeed
is the filereadoffset.But the file is rorated , the checkpoint size is often bigger than the
file size ,and this will cause chukwa resend all the log file.
>      So we add a "log.info("chunk seqID:"+c.getSeqID());" in ChukwaHttpSender:send.
>     The seqid is the offset of the send chunks in this log file.
>     So when we need to restart the chukwa, we just need to stop the chukwa , change the
size in checkpoint to the last chunk seqid in log and start chukwa.   
>       We also can directly apply the seqID to checkpoint size ,but we don't know if this
will cause other problems.
> 2. The method tailFile in FileTailingAdaptor is the core code of collecting the log.
The code use the fileReadOffset , file length to detect the rotated file.
>         RandomAccessFile newReader = new RandomAccessFile(toWatch, "r");
>         len = reader.length();
>         long newLength = newReader.length();
>         if (newLength < len && fileReadOffset >= len) {
>           if (reader != null) {
>             reader.close();
>           }
>           
>           reader = newReader;
>           fileReadOffset = 0L;
>           log.debug("Adaptor|"+ adaptorID + "| File size mismatched, rotating: "
>               + toWatch.getAbsolutePath());
>         } else {
>           try {
>             if (newReader != null) {
>               newReader.close();
>             }
>             newReader =null;
>           } catch (Throwable e) {
>             // do nothing.
>           }
>         }
>      This arithmetic does work in most cases. But there is a case ,that when chukwa starts
, the log file is 0 and it will be 0 untill it has been rotated. After it has been rotated
,becase its size is 0 ,this log will be removed. A new file has generated , and its size isn't
0.
>       But the len is still 0 ,newLength is > 0.So this contition  if (newLength <
len && fileReadOffset >= len)  will never be archived. The new log file will never
be detected.
>        So we changed the implemention of this method, we use timestamp to detect the
new log file.The lastSlurpTime is the timestamp of the last slurp ,it is been declared and
assigned in LWFTAdaptor .   
>        try {
>                 len = reader.length();
>                 if(lastSlurpTime == 0){
>                     lastSlurpTime = System.currentTimeMillis();
>                 }
>                 if (offsetOfFirstByte > fileReadOffset) {
>                     // If the file rotated, the recorded offsetOfFirstByte is greater
than
>                     // file size,reset the first byte position to beginning of the file.
>                     fileReadOffset = 0;
>                     offsetOfFirstByte = 0L;
>                     log.warn("offsetOfFirstByte>fileReadOffset, resetting offset to
0");
>                 }                    
>                 if (len == fileReadOffset) {
>                     File fixedNameFile = new File(toWatch.getAbsolutePath());
>                     long fixedNameLastModified = fixedNameFile.lastModified();
>                     if (fixedNameLastModified > lastSlurpTime) {
>                         // If len == fileReadOffset,the file stops rolling log or the
file has rotated.
>                         // But fixedNameLastModified > lastSlurpTime , this means
after the last slurping,the file has been written .
>                         // so the file has been rotated.
>                         boolean hasLeftData = true;
>                         while(hasLeftData){// read the possiblly generated log
>                             hasLeftData = slurp(len, reader);
>                         }
>                         RandomAccessFile newReader = new RandomAccessFile(toWatch, "r");
>                         if (reader != null) {
>                             reader.close();
>                         }
>                         reader = newReader;
>                         fileReadOffset = 0L;
>                         len = reader.length();
>                         log.debug("Adaptor|" + adaptorID + "| File size mismatched, rotating:
" + toWatch.getAbsolutePath());                                               
>                     }
>                     hasMoreData = slurp(len, reader);
>                 } else if (len < fileReadOffset) {
>                     // file has rotated and no detection
>                     if (reader != null) {
>                         reader.close();
>                     }
>                     reader = null;
>                     fileReadOffset = 0L;
>                     offsetOfFirstByte = 0L;
>                     hasMoreData = true;
>                     log.warn("Adaptor|" + adaptorID + "| file: " + toWatch.getPath()
>                             + ", has rotated and no detection - reset counters to 0L");
>                 } else {                              
>                     hasMoreData = slurp(len, reader);
>                 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message