Showing posts with label monitoring. Show all posts
Showing posts with label monitoring. Show all posts

Sunday, October 7, 2007

FreeBSD system beep and dual monitor setup

I am using PCBSD on my R60 laptop, and turning off system beep was even easier than using kbdcontrol -b off or sysctl.

I simply used the Bell Settings from the KDE menu, and setted volume to 0, simple and effective! The sound system still works like a charm.

I have giving up on setting up dual monitor, with our TV, as everything I found so far points toward a lot of xorg.conf tweaking, something I just dont want to spend my time on!
I have decided that my next laptop must have dual output, eg. a VGA or DVI, and then I just might give it a shot.

I still hope to find a way to change back and forth with the R60 VGA output from laptop to TV. That would be nice to have!

Sunday, September 30, 2007

Edge based network management and Event tracing for Windows

Reading another great post from TaoSecurity, this time about Microsofts Anemone project which is an abitious network and systems monitoring system, using network end points.
Anemone is investigating network and systems management from the edges of the network, initially focusing on enterprise network management. It aims to build a network management platform based around two main components: (i) endsystem flow monitoring, providing the inputs to the system; and (ii) monitoring of the network routeing protocols, providing current system configuration. By aggregating and querying these data sources in a distributed fashion, Anemone will provide a platform on which network management applications can be built to provide tools for visualization, what-if analysis, and control of the network.

While edge based approach seems interesting, it is research and out of my leage. I leave it to experts like to give a review at a later time :-) A review I will read with much interest if and when it arrives!

Anyway, the original post mentioned use of event tracing for Windows:
To evaluate the per-endsystem CPU overhead we constructed a prototype flow capture system using the ETW event system [Event Tracing for Windows]. ETW is a low overhead event posting infrastructure built into the Windows OS, and so a straightforward usage where an event is posted per-packet introduces overhead proportional to the number of packets per second processed by an endsystem.
It sounded intesting, going on to the Microsoft website explanation:
Event tracing is a technique for obtaining diagnostic information about running code without the overhead of a checked build or use of a debugger. An event represents any discrete activity that is of interest, especially with respect to performance.

Developers can implement event tracing in a driver by using the Microsoft Windows software trace preprocessor (WPP). WPP software tracing in kernel-mode drivers supplements and enhances Windows Management Instrumentation (WMI) event tracing by adding conventions and mechanisms that simplify tracing the operation of a driver. WPP event tracing is implemented by adding certain C preprocessor directives and WPP macro calls to the driver source code. During an event tracing session, WPP logs real-time binary messages that can subsequently be converted to a human-readable trace of driver operations.

This is interesting, but for the developer, with source code access.

I dont see how Event tracing can help an administrator trace and debug events on servers or clients. Perhaps I am mistaken?

Friday, September 28, 2007

IRC bots and announcements

I am still in some IRC channels where it would make sense to have announces from work related stuff, eg:
  • Nagios monitoring alerts.
  • Subversion commit messages. And other post/pre-commit hooks.
In an ONLamp article about subversion and traq on FreeBSD, there is also an example with a irc announce using RSS feeds, which is implemented with http://supybot.com/. This seems interesting, maybe it is useful for my other needs, I will have to check it out.

On top of the Nagios alert messages, it would be nice to be able to send a query from an IRC bot to the Nagios service to get current state of a service monitor.