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

Re: Followup: Syslog



On Wednesday 18 April 2001 16:23, Andrew Pimlott wrote:
> I think they are not more widely used because they do not make
> understanding and managing logged information easier.  For most
> users, this is probably the only thing that would make them change.
So, if I made an alternative to the others, which actually /improved/ the 
value of logging, and made it easier to see what was going on, then there 
might be a reason for switching?

> Unfortunately, I think this would be very challenging.  First, you
Challenges are obstacles. Obstacles are there to be overcome :)

> are constrained by the syslog API.  For example, one of the items on
> your list was "user-defined facilities".  This cannot be done in any
> meaningful way without changing the API.  In my opinion, you'd like
Well, I've been thinking about that, too. Instead of /replacing/ the API, how 
about complementing it with /another/ API? Right now, you'd #include 
<sys/syslog.h>. If I made a complimentary API, then you could make #ifdef's, 
and use the extra logging features, if they're available on the system. This 
way, the program will be backwards compatible, but also use a new interface. 
It is the design of this interface that I'd like people to comment on, so I 
can make the most efficient and /clean/ all-round logging daemon.

> even more metadata on logged messages:  Is this about
> authentication, authorization, network problems, data corruption, a
> subsystem failure?  To what session, connection, or user does it
> apply?  It is difficult today to follow the strand of related
> messages.  Additional metadata could help.  But this requires a
> whole new API.
So the new API needs to mandate extra metadata. I'm just not sure of what 
exactly yet.

> Second, applications need to cooperate.  Many programs don't even
> document what facility they use, much less let you change it.  To
> really make use of their logs, you want to know what they do and (as
> importantly) don't log; the exact format of messages (for automatic
> analysis); and where to get more details about a message.  But this
> is a lot of work for a lot of applications, and logging tends to be
> a low priority item.
Which is why open-source is A Good Thing. This means that if I ever pull it 
off and make a superior logging daemon, I'll be able to do some of those 
things myself, until it catches on. Security Matters, and to make it more 
efficient, we need better logging. Not necessarily more logging, just better.
Also, I want it to be universal, so when I'm creating programs, I can make 
them log via the syslog'er, so I can send the logged messages to another host 
when I'm debugging low-level stuff, and log it to a regular file when just 
programming, etc. A good logging-daemon need not be limited to system 
logging. What do others think?


> I think we're going to be stuck with hard to understand logs for a
> long time.
Not if I have anything to say :)

But thanks for your comments! As always, they are appreciated.

> Andrew

Regards
Kenneth



Reply to: