 |
 |
 |
 |
 |
 |
 |
|
|
2005-02-22 - Ethan GalstadNagiosAn interview conducted by FOSDEM & the LinuxFR readersFOSDEM - First and traditional question: please present yourself ! Ethan Galstad - I am 30 years old and live in Saint Paul, Minnesota (U.S.). Originally from Wisconsin, I moved to Minnesota for college in 1992 and ending up staying after I graduated. My intention was to study aerospace engineering, but after a few semesters of calculus and physics, I decided a change to computer science might be a better choice. I've worked doing desktop support, network administration, web development, and other similar jobs over the past 10 years. In addition to my work on Nagios, some of my interests include the study of paranormal phenomenon, archaeology, scientific discoveries, conspiracy theories, and world religions. They may seem like disparate subjects, but there are certainly common threads that bind them together. Recently, I've been putting my energy towards building a company I recently started (Ayamon, LLC) to help promote Open Source software and solutions that can be provided with it. FOSDEM - How did you start working on Nagios ? Ethan Galstad - Back in 1999, a friend of mine and I were looking into starting a company that would offer network monitoring services to small businesses and school districts in our local area. A quick investigation revealed that using commercial network monitoring software packages would have been too expensive to offer services at reasonable rates. In my opinion, the free and Open Source monitoring applications that were available at the time lacked some features I needed and either had nonexistant or unsatisfactory web interfaces. That prompted me to start writing my own monitoring application. I should mention that, for several reasons, I nearly didn't release the code when I first started. First, I was fairly confident that the initial version would fit my immediate needs and that there wasn't much need for external input or assistance. Second, I wasn't sure I wanted to give away (as I saw it) any competitive advantage I had with providing network monitoring services. Lastly, I wasn't sure I wanted to let the world scrutinize my coding style and abilities. I had been introduced to Linux and other Open Source apps a year or so prior, and was astounded by the possibilities they offered me. The fact that I could have access to a free C compiler was truly a wonderful thing to me. The more I thought about it, the more I wanted to offer something back to the Open Source community. After spending time weighing the pros and cons of releasing the code under an Open Source license, I decided to go ahead with it. When I first released the code, I thought I'd be absolutely thrilled if 20 or so individuals or organizations used it. As it turned out, releasing the code triggered something that spiralled out of control. Let that be fair warning to anyone considering starting to work a new Open Source project. :-) FOSDEM - Where does the Nagios name come from ? Ethan Galstad - Development originally started under the name “NetSaint” in 1999. In 2001 I was contacted by a company (actually, their attorneys) that claimed ownership of a trademark that was similar to NetSaint. After working with an attorney on the matter, I decided that the cost (both in terms of time and money) of defending my use of the name "NetSaint" was simply not worthwhile. Although we were able to eventually reach an amicable agreement on my future use of the name “NetSaint”, I felt it was prudent to change the name in order to prevent any future mishaps. It was at that time that I changed the name to “Nagios”, which is a recursive acronym: N.A.G.I.O.S. = “Nagios Ain't Gonna Insist On Sainthood”. Once the project was renamed, I sought and received a trademark registration for "Nagios", so as to help avoid future complications of a similiar nature. FOSDEM - What are the advantages of Nagios compared to proprietary products ? Ethan Galstad - Other than the obvious benefit of having access to the source code for customization and bug fixes, its flexibility is likely responsible for its popularity. Nagios can be integrated with other applications very easily - most tasks performed by Nagios are handed off to external commands and third-party applications can send control commands and data to Nagios very easily. In addition, the seperation of the interface from the monitoring logic makes it fairly simple for people to write their own front-ends for Nagios. This type of modular design gives people a great deal of flexibility when integrating Nagios into their environment. As an example, they can write plugins (check commands) to monitor almost any kind of system or service they might have in production - no matter how arcane or customized it may be. Nagios does not limit what they can monitor. FOSDEM - When do you plan to release v2.0, which is already in beta stage ? Ethan Galstad - I don't usually project dates for stable releases of Nagios. I feel its better to lets the bugs be found and fixed in their own time, rather than force a pre-determined schedule into the development process. That said, I imagine a stable version 2.0 will be released by early summer. That should provide adequate time to work out any problems that are discovered and document the new event broker API. FOSDEM - What are the new features of the upcoming version compare to the 1.2 one ? Ethan Galstad - Several performance enhancements have been made which will hopefully benefit large installations with thousands of monitored services. Passive and regularly-scheduled host checks are now supported, which will benefit some users with distributed and failover monitoring setups. I've started to clean up some of the design mistakes I made in previous versions, although cleanup won't be complete until at least 3.0. There have been a number of other minor features added in 2.0 as well, but two big additions (in my mind) are the adaptive monitoring features and the new event broker API. Adaptive monitoring allows users to modify some attributes of host and service monitoring on-the-fly. Examples of things that can be changed during runtime include check commands, event handlers, check interval, etc. While it may seem like a minor feature enhancement, adaptive monitoring will allow for greater flexibility in more advanced setups. The event broker API allows third-party compiled modules to be loaded into the Nagios daemon during runtime. These modules become part of the Nagios process itself and are able to process various types of event data in near realtime as they occur. This is particularly useful for enhancing Nagios' feature set without having to customize the Nagios daemon code itself. One example of what can be done with the API is adding support for logging event data and alerts to a MySQL database. In fact, an event broker module that is capable of doing this has already been written by a Nagios user. As of now, the event broker API is largely undocumented, but I hope to have the documentation completed before 2.0 goes stable. I plan to expand the API's functionality in 3.0 to allow modules to override monitoring and processing logic that is currently found in the daemon. That will be a big step in the evolution of Nagios. FOSDEM - Is there more work done on Nagios itself or in the plugins ? Ethan Galstad - I can't say whether there is more work done on the core program or the plugins, as they are two different animals. I imagine that plugin development will always continue at a fairly steady rate, as new plugins will need to be developed and existing ones updated as new hardware, services, and protocols are rolled out in production environments. Because it has been designed in an abstract manner, and is not tied to any particular set of protocols or services, the Nagios daemon will eventually mature to a point where development can proceed at a slower pace. FOSDEM - Are you satisfied by the infrastructure that will be put in place with v2.0? Is it a mature product in the sense that you wouldn't want to change anything fundamental? Ethan Galstad - I was satisfied with the first version of NetSaint six years ago, but I still managed to find new things to add as time went by. :-) Actually, I am really looking towards 3.0 for bringing some big ideas I have for the Nagios daemon to fruition. In my opinion, things like expansion of the event broker API and addition of custom object variables will vastly increase the flexibility and functionality currently found in Nagios. Fundamentally, I don't see things changing drastically in the Nagios daemon. The current CGIs will be replaced with a PHP or Perl interface (spun off as a seperate project), there will be some code cleanups that occur to increase efficiency, and new features (like the event broker API) will be added to enhance Nagios' abilities. However, when all is said and done, I imagine that Nagios will still function in much the same manner it does now. In fact, the present core functionality is not terribly different than what it was nearly six years ago. FOSDEM - What do you expect from your FOSDEM talk ? Ethan Galstad - First, let me say that I am extremely honored to be asked to participate in FOSDEM 2005. I would hope that, as a result of the presentation, more people will be aware of Nagios and its possible applications in their environments. I am also looking foward to the opportunity to meet a number of (hopefully happy) Nagios users in person. Europe seems to be a hotbed for Open Source right now, and it will be a wonderful opportunity to talk with some of the many people who are responsible for helping to make this happen. I look forward to seeing you all very soon!
|
|
|
|
 |
©
FOSDEM 2003-2005 - powered by Argon7 |