-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-10-25 at 15:46 +0200, Per Jessen wrote:
Anton Aylward wrote:
In a enterprise setting this is normally handled by a central syslog mechanism for the enterprise and there is some very sophisticated software supporting this.
In the enterprise, SNMP is by far the preferred method for real-time alerts, failing that email. The syslog is primarily for auditing and post-mortem purposes. If the syslog was really so central in enterprise real-time monitoring of Linux systems, it's difficult to understand why popular monitoring tools typically provide an email option, very often also an SNMP MIB, but usually no plain syslog option. (ex: mdadm, smartd, HPs Proliant Support pack tools).
I think I can perhaps explain why telcos use syslog as core in their monitoring and alerting systems. Basically, tradition. I have worked for telcos and for one of the big exchange makers. This machine is big, very expensive, and the design must be from the seventies or eighties, with updates. It's Unix. It doesn't have network: I mean, no tcp/ip. It has a main dumb terminal on a serial port, and also a serial port printer. These two connect to a dual card, like a computer having two serial port cards connected to the same device via a switch. Very, very reliable. And privileged, some operations can only be done from this terminal. There are also other type of "secondary" serial port cards, each handling 4 terminals or printers. There is usually a secondary terminal and printer on the site. The card may control instead an X.25 connection, which can be used for file transfers (not FTP) and some more terminals (remote). And a tape r/w unit. Ah! The internal Unix has mail. I wasn't allowed to test it, understandably. Pity! These machines were controlled locally; they used to have 24h/7d personnel on shifts. The main printer was used for a kind of syslog: the exchange is continuously printing status messages, alarms, audits, exceptions, output of some commands... all the outputs have a very strict formatting that allows differentiating each report or alarm. The secondary printer dumped periodically traffic reports. Now comes tcp/ip. They want to use networking to do remote management of the exchanges, with a central core of trained personnel for the entire network, and maybe no permanent personnel on sites. What they did was connect the main terminal and printer to a special router or PC that converts the serial port into telnet, and transmit the data to the central control center. Maybe they connect the rest of the terminals (8) and leave none on site. So, on the central operation center (NOC) they get the output that was pushed to the two printers years before. It is collected and saved to log files. They have Unix machines with expensive proprietary software that collect each report, save them into a database record, do some analysis, raise alerts based on importance... these things display into nice displays into the technicians computers (you need training to use them); the alarms go to a wall display. The room may have dozens of technicians and engineers... kind like the NASA control center on movies. A director may assign an alert to be handled by a technician of his choice, etc. See an alert, take or assign it, open a telnet to the site, solve the problem or escalate, report it... Cute! :-) :-p Now, complicate all that if they have exchanges from different manufacturers, and of different models. It is a very complex setup, I assure you. Mine was one model only and relatively small. So, for this people, syslog is core to their way of thinking. Although it is not a real syslog as in Linux. And, even if it makes sense for that setup, that doesn't mean that we have to use the same on Linux setups. Let us have our syslog, our email, and our SNMP, and whatever they invent >:-) HTH. :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkFAFcACgkQtTMYHG2NR9W5cACeKzmNhns9xr45DPZkP3nRrnM6 jZUAnj43mwvILzFq1mZ5099rxnbh5oiw =29Q0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org