|
|
Sponsored Content
Special Forums
UNIX and Linux Applications
Infrastructure Monitoring
Event processing & machine learning in monitoring system
Post 302857067 by zaxxon on Wednesday 25th of September 2013 11:26:42 AM
09-25-2013
I had bad experience with expensive tools in the past, where OS names were listed in the white papers and sales publications, even in the header of scripts, which simply did not work or were a pain to get to work.
Some monitoring solutions can't come out of the box as some demands for applications etc. is far too special so you often have a lot of coding or at least configuration works.
Some companies even charge insane prices for additional probes/modules/plugins/spys (whatever they call them), that are so badly programmed or simple, you could think they are making a bad joke.
I would always setup a detailed Prove of Concept, invite the company and have detailed things tested, before buying anything. The sales often promise a lot, while the techs take the pain or the hotline/support is pushed to the front to block off the customer more or less.
Nagios, as a free tool for example, offers a lot of plugins that cover most things, but the plugins you can get for free are from very good to flawed. Again, sometimes you have to write stuff on your own but can offer them for exchange, if allowed
my 2 cents
Some monitoring solutions can't come out of the box as some demands for applications etc. is far too special so you often have a lot of coding or at least configuration works.
Some companies even charge insane prices for additional probes/modules/plugins/spys (whatever they call them), that are so badly programmed or simple, you could think they are making a bad joke.
I would always setup a detailed Prove of Concept, invite the company and have detailed things tested, before buying anything. The sales often promise a lot, while the techs take the pain or the hotline/support is pushed to the front to block off the customer more or less.
Nagios, as a free tool for example, offers a lot of plugins that cover most things, but the plugins you can get for free are from very good to flawed. Again, sometimes you have to write stuff on your own but can offer them for exchange, if allowed
my 2 cents
|
|
We Also Found This Discussion For You
1. UNIX for Dummies Questions & Answers
What is the best way to learn UNIX, shell, and Perl on a Windows 2000 machine? My place of employment uses Solaris and Perl and I would like to learn some UNIX skills on my home PC.
I read about "dual boots", "Microsoft Windows Services for UNIX", and "cygwin". What other free options are... (9 Replies)
Discussion started by: wolfv
9 Replies
LEARN ABOUT DEBIAN
module::starter::plugin
Module::Starter::Plugin(3pm) User Contributed Perl Documentation Module::Starter::Plugin(3pm) NAME
Module::Starter::Plugin -- how Module::Starter plugins work DESCRIPTION
This document is a guide to writing plugins for Module::Starter. Currently, as is evident, it isn't very comprehensive. It should provide enough information for writing effective plugins, though. After all, Module::Starter's guts are nice and simple. "Module::Starter->import" Module::Starter provides an import method, the arguments to which are plugins, in the order in which they should be loaded. If no plugins are given, Module::Starter::Simple (and only Module::Starter::Simple) is loaded. By default, the given modules are required and arranged in an is-a chain. That is, Module::Starter subclasses the last plugin given, which subclasses the second-to-last, up to the first plugin given, which is the base class. If a plugin provides a "load_plugins" method, however, the remaining plugins to be loaded are passed to that method, which is responsible for loading the rest of the plugins. This architecture suggests two kinds of plugins: engine plugins An engine is a plugin that stands alone, implementing the public "create_distro" method and all the functionality required to carry out that implementation. The only engine included with Module::Starter is Module::Starter::Simple, and I'm not sure any more will be seen in the wild any time soon. plain old plugins Other plugins are designed to subclass an engine and alter its behavior, just as a normal subclass alters its parent class's. These plugins may add features to Module::Starter engines, or may just provide general APIs for other plugins to exploit (like Module::Starter::Plugin::Template.) The template plugin is a simple example of a plugin that alters an engine to accept further plugins. Other plugins like template will probably be written in the near future, and plugins that exploit the API provided by Module::Starter::Plugin::Template will be available on the CPAN. AUTHOR
Ricardo SIGNES "<rjbs at cpan.org>" COPYRIGHT
Copyright 2005, Ricardo SIGNES. All Rights Reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. perl v5.12.4 2010-05-28 Module::Starter::Plugin(3pm)