Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Log management options?



On 03/17/2012 10:31 AM, Scott Ehrlich wrote:
> On Sat, Mar 17, 2012 at 1:40 AM, Scott Ehrlich <srehrlich at gmail.com> wrote:
>> I'm looking for log management options for a network of Windows and
>> Linux hosts on an isolated network.
>>
>> I need tcp communication (vs udp) to ensure messages successfully get
>> passed from client to log server.
>>
>> Encryption of the message, too, between client to server would be
>> great.    TCP alone would just provide plain-text.
>>
>> I've been in touch with Intersect Alliance, and they've been extremely
>> helpful with a myriad of questions I've posed, but I just learned that
>> their server product requires its own Linux OS, provided by them.   A
>> bit of a bummer.
>>
>> Solarwinds, owner of Kiwi, won't return my emails.
>>
>> Corner Bowl is Windows-centric.
>>
>> Envision is just way too expensive.
>>
>> What other products are out there?
>>
>> Thanks.
>>
>> Scott
> Someone asked me what my goal was -
>
> I want to have a central location (database/file on a server) where
> successful and failed login attempts, objects accessed, system events
> such as discs inserted and data copied, are stored, machine powered
> up/down, media added/removed (usb devices, etc) along with machine
> name/ip and user, and an easy way to sort by user, date, time, status
> (success/failure), etc, for a given period of time, that period
> defined by the auditor.
>
> All events in the central database should mirror the events stored on
> the respective local machine they are sent from - thus the log server
> would have just a copy of what the local machine has.
>
This is essentially the goal of SNMP. Also, have you looked at Splunk.
Rajiv gave a talk on Splunk in 2007 at the BLU.  I've had a few requests
on it.
As I mentioned, before, UDP is tends to be more widely used for network
monitoring because it is connectionless. Today, with
multi-core/multi-thread systems, the timeout associated with the use of
TCP for network monitoring is less of an issue, but it still adds some
overhead you don't have with UDP. For instance, with TCP, for each host,
you have to establish a connection. This takes time. Once you have
established the connection, if the host dies, there will be a timeout
before your application gets a disconnect. With UDP, you send out
messages to all your hosts being monitored. Those that respond are good.
Those that don't are bad. Everything is dependent upon the network
monitoring software. If you want to encrypt, it is up to the
application. You can use UDP to measure latency as well as TCP, or your
app can use ICMP. In any case, based on my experience, connectionless is
better for network monitoring. Additionally, TCP requires takes up 1
port for each connection. It is a dynamically assigned port, but when
you are monitoring thousands of hosts, it becomes significant where UDP
requires 1 port to listen on. All of what you want is available to
monitor systems. Maybe we could have someone talk about Splunk in April,
July or August.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org