Re: [logs] Central Log Server

afort@private

Jason Haar wrote:

> On Thu, Oct 02, 2003 at 01:13:15PM +1000, Philip Webster wrote:
> 
>>network saturation.  Has anyone encountered and solved these solutions 
>>before whilst still maintaining a central log host setup?
> 
> As far as reliability when network outages occur, syslog-ng specifically
> allows you to configure a FIFO - which basically means it'll cache up to "n"
> records when the TCP channel blocks or dies, and will flow those cached
> records through when the other end is up again.
> 
> Obviously there are limits (there always are): how many records you allow it
> to cache impacts how much memory you allocate to the syslog-ng client, this
> cache is in-memory, so will be lost if the syslog-ng client dies for some
> reason, etc.
> 
> We run a three-tier'ed syslog-ng environment. Each site points its syslog
> clients (Unix, Routers, Switches, Windows+ntsyslog, printers) at its
> central syslog server (i.e. over UDP), and the central syslog servers
> replicate their data to a "corporate" central syslog server (over TCP). 
> 
> i.e. each site has a central syslog server, and the corporation has a
> central syslog server containing (most) of the entire companies syslog data.

Hi folks (my first post here),

On this topic (I'm designing a similar environment presently), I'm 
wondering:

Have you (or other readers) used anycasting of the 'regional' log 
collector service address (i.e., the IP address receiving logs from the 
UDP-only capable loggers such as network elements) to perform automated 
failover in case of loghost or link failure?  I've tested this and it 
works in the lab, but wonder about any issues I might see in production 
and would appreciate any advice from others who've done this.

This is how I'm doing it (cisco ios configs):

router1 has loghost-a directly connected.
router2 has loghost-b directly connected.
logip is the logging address
(only one box servicing the logip can be connected to each router, due 
to the address duplication).

router1 config:

interface fa1/1
  ! loghost-a "real" address = 172.16.0.2/30
  ip address 172.16.0.1 255.255.255.252
  ! logip = 172.16.255.2
  ip address 172.16.255.1 255.255.255.252 secondary
!

router ospf 1
  network 172.16.0.0 0.0.0.3 area 100
  network 172.16.255.0 0.0.0.3 area 100
  passive-interface default
!
logging 172.16.255.2
end

router2 config:

interface fa1/4
  ! loghost-a "real" address = 172.16.0.6/30
  ip address 172.16.0.5 255.255.255.252
  ! logip = 172.16.255.2
  ip address 172.16.255.1 255.255.255.252 secondary
!

router ospf 1
  network 172.16.0.4 0.0.0.3 area 100
  network 172.16.255.0 0.0.0.3 area 100
  passive-interface default
!
logging 172.16.255.2
end

Now, each device logging to 172.16.255.2 will have its logs arrive at 
the  regional loghost 'closest' to it (by IGP metric).  Setting 'ip ospf 
cost' on the interface could make the loghost more or less preferable to 
others.

The only issues I see are:

1. Logs arriving at the central loghost may arrive at different times, 
out of order?  (With ciscos, my major source of syslog clients, this is 
less of an issue since I can tag a sequence number).  Can the original 
timestamps be preserved on the TCP leg?

2. Avoiding multipath routes to the logip - this is straightforward to 
avoid.

Am I over-engineering this problem?  I'd really like to be able to 
promote and remove regional loghosts from action by removing the logging 
service address from their port and, primarily I'd like loghosts if they 
are rebooted/crash to cause minimal log drops.

-Andrew

_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis