> > I would, however, like to extend the core syslog format to > support > [...] needs to send a larger message > > Syslog does "support" this already. All the programmers has > to to is call > syslog(...) several times (or any other function that is part > of the API.
Well, not talking about API, but if you mean I can send several lines in several messages this is not what I am looking for. I would like to have a single large message - in the rare occasions there is need for it... > > Even for a limit of 1024, this means that line becomes 10 or > more line on your editor! If You need that frequently, > probably a support function, or macro is used. That that > macro can be used to send that "long" line in several > messages, each on contain a kind of fragment counter. This is exactly what I am asking for. I don't intend to do something very complex. Just build a *standard* way of sending oversize messages if there is need for this. In the -international-00, there is a way to do so, in case you would like to comment. The way it is in -international right now needs to be revised, but I hope it will convey the spirit. > > But that is about programming/API's, back to the protocol. > > When "long lines" are needed, probably the output of the log > isn't meant for human reading, but for "a script" or tool. > Then, this is site or application specific. And so, NO > general standard is needed. Actually, if I look at almost all larger installations, all of them use some kind of automatted log watchers. It is hard to envision that admins will dig through a view millions of log lines each day. So I think the protocol must enable automatic processing... > > At least, I can't think of any reason. But maybe a counter > example can be given... (which used "long lines" AND needs a > "generic solution.) Well, I know Microsoft does not necessarily do it smartly. Many customers ask for forwarding Windows event log data to their central syslogd. Now lets look at some message from the log: ------- BEING LOG ENTRY ;) ----- DNS Server has updated its own host (A) records. In order to insure that its DS-integrated peer DNS servers are able to replicate with this server, an attempt was made to update them with the new records through dynamic update. An error was encountered during this update, the record data is the error code. If this DNS server does not have any DS-integrated peers, then this error should be ignored. If this DNS server's ActiveDirectory replication partners do not have the correct IP address(es) for this server, they will be unable to replicate with it. To insure proper replication: 1) Find this server's ActiveDirectory replication partners that run the DNS server. 2) Open DnsManager and connect in turn to each of the replication partners. 3) On each server, check the host (A record) registration for THIS server. 4) Delete any A records that do NOT correspond to IP addresses of this server. 5) If there are no A records for this server, add at least one A record corresponding to an address on this server, that the replication partner can contact. (In other words, if there multiple IP addresses for this DNS server, add at least one that is on the same network as the ActiveDirectory DNS server you are updating.) 6) Note, that is not necessary to update EVERY replication partner. It is only necessary that the records are fixed up on enough replication partners so that every server that replicates with this server will receive (through replication) the new data. -------- END LOG ENTRY ------ Of course, you can argue that this should be truncated or detected or whatever. The plain truth is that it is less error-prone to forward them as they are to the central syslogd (especially as the text can and has change with service packs or hot fixes). We can do that with our products, but wouldn't it be nice if there were a standard way to do this so that a customer must not necessarily use Adiscon products both on client and collector? Another example is international character sets. As some pointed out, messages may get longer. As other have (correctly) pointed out, multibyte character sets do not necessarily mean that will, but anyhow, it would be nice if we need not to be afraid if it will happen. Again, I do not intend to do something complex here - just a standard way to say "this is message 1 of 2", so that the collector (if he decides to do so) can defragment these two messages into a single one. If you don't like it, you can safely ignore this feature. In fact, I think it should only be used if you know the transport is reliable, in-order - otherwise you should expect to loose some fragment. Still objections? Rainer
