Changes between Version 4 and Version 5 of tipimaid

Show
Ignore:
Timestamp:
10/21/09 20:56:18 (9 years ago)
Author:
walter
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • tipimaid

    v4 v5  
    5959 
    6060 
    61 ''' Please set the buffertime value of `tipimaid_sender` to exactly the same as the value for buffertime in `tipimaid` itself! ''' 
     61''' Please set the `buffertime` value of `tipimaid_sender` to exactly the same as the value for `buffertime` in `tipimaid` itself! ''' 
    6262 
    6363 
    64  In addition all lines which are buffered like this, are also sorted. So, if you have two Apaches serving the same virtual host and both of them send their logs to one logging computer you don't have to fear latency if you set buffertime to, say, a minute. If computer1 sends loglines for 10:30:10, 10:30:14 and 10:30:18 and computer2 has loglines for 10:30:12 and 10:30:13 but for some reason these two hits arrive later (but not later than 60 seconds) this is no problem at all, they are simply written away, neatly sorted after they have been in the buffer for 60 seconds. But back to the bad things. Of course you can set the buffertime to 10 or even 30 minutes. If the connection between the Apache computer and the logging computer dies, `tipimaid_sender` buffers these loglines in memory. It then periodically checks, whether it can establish a connection to the logging computer. If this is successful and the oldest buffered loglines (buffered by `tipimaid_sender`) are not older than "buffertime" then they are simply sent to the logging computer because it is no problem to sort them into the buffer of the logging computer and everything is fine. If the duration of the connection loss is, however, longer than "buffertime", the loglines which are too old are written to local recovery log ("local" means the Apache computer here). To keep you notified, `tipimaid_sender` will tell you about this step in Apache's error log. In any case, `tipimaid_sender` tries to re-establish the connection to its server and will send any new loglines. 
     64 In addition all lines which are buffered like this, are also sorted. So, if you have two Apaches serving the same virtual host and both of them send their logs to one logging computer you don't have to fear latency if you set `buffertime` to, say, a minute. If computer1 sends loglines for 10:30:10, 10:30:14 and 10:30:18 and computer2 has loglines for 10:30:12 and 10:30:13 but for some reason these two hits arrive later (but not later than 60 seconds) this is no problem at all, they are simply written away, neatly sorted after they have been in the buffer for 60 seconds. But back to the bad things. Of course you can set `buffertime` to 10 or even 30 minutes. If the connection between the Apache computer and the logging computer dies, `tipimaid_sender` buffers these loglines in memory. It then periodically checks whether it can establish a connection to the logging computer. If this is successful and the oldest buffered loglines (buffered by `tipimaid_sender`) are not older than "buffertime" then they are simply sent to the logging computer because it is no problem to sort them into the buffer of the logging computer and everything is fine. If the duration of the connection loss is, however, longer than `buffertime`, the loglines which are too old are written to local recovery log ("local" means the Apache computer here). To keep you notified, `tipimaid_sender` will tell you about this step in Apache's error log. In any case, `tipimaid_sender` tries to re-establish the connection to its server and will send any new loglines. 
    6565 
    66 If the really bad stuff happened (you had a connection loss which was longer than buffertime), you have two logs now: One processed logfile at the logging computer and a recovery log at the Apache computer. Both of them are sorted, thus we can use `tipimaid_mergelogs` which, well, merges (already sorted) logs to one log. If you use virtual hosts, you might want to pipe the recovery log through `tipimaid`, first (to split entries) and use `tipimaid_mergelogs` afterwards.  
     66If the really bad stuff happened (you had a connection loss which was longer than `buffertime`), you have two logs now: One processed logfile at the logging computer and a recovery log at the Apache computer. Both of them are sorted, thus we can use `tipimaid_mergelogs` which, well, merges (already sorted) logs to one log. If you use virtual hosts, you might want to pipe the recovery log through `tipimaid`, first (to split entries) and use `tipimaid_mergelogs` afterwards.  
    6767 
    6868=== That was too much text - what were `tipimaid_sender`'s options? ===