Re: [CentOS] Nagios, getting started
On 06/22/2015 01:04 PM, Rob Kampen wrote: Hi List, I have noted a number of times, various comments on this list about Nagios, hence my questions. just been employed by an ISP and they want to upgrade their fairly extensive nagios monitoring. Just for information, Nagios has been forked by some, for several reasons. https://www.icinga.org/ http://shinken-monitoring.org/ I recommend you check the history in order to have the background. They are mostly an ubuntu lts shop, so 1st question What advantages does the RH/CentOS world have (if any?) over the ubuntu LTS world? There is a famous quote: If ain't broke, dont fix it https://en.wiktionary.org/wiki/if_it_ain't_broke,_don't_fix_it If you have documentation, plugins, configuration all working with some flavor of a distribution, ease your work. They are talking about running the server on a vm, as I have no experience with this tool, is that appropriate? or does it really need some hardware resources to function properly? If a vm is okay, what kind of RAM does it need? We run our monitoring tools (Nagios, Collectd, Munin,...) all on VMs. It is ideologically OK to run this kind of service on a VM. About ressources, VM are extensible: begin with small ressources, extend when needed. I see epel has nagios 3.5.1 with a date of 2013 for CentOS7 along with plugins, is this the version folk use? - as the latest from nagios is 4.0.8 I am under orders to use packages and not compile, a viewpoint I endorse. Are there other repos folk use? Packaging has advantages and drawbacks. On the other hand, packages are built from compiling sources. Some repos can be trusted for their packages quality, but some others might be personnal repos that might work only for the packager use case. Some repos are listed on the CentOS website: http://wiki.centos.org/AdditionalResources/Repositories Using a 3rd party repo requires some investigation. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Nagios, getting started
Hi List, I have noted a number of times, various comments on this list about Nagios, hence my questions. just been employed by an ISP and they want to upgrade their fairly extensive nagios monitoring. They are mostly an ubuntu lts shop, so 1st question What advantages does the RH/CentOS world have (if any?) over the ubuntu LTS world? They are talking about running the server on a vm, as I have no experience with this tool, is that appropriate? or does it really need some hardware resources to function properly? If a vm is okay, what kind of RAM does it need? I see epel has nagios 3.5.1 with a date of 2013 for CentOS7 along with plugins, is this the version folk use? - as the latest from nagios is 4.0.8 I am under orders to use packages and not compile, a viewpoint I endorse. Are there other repos folk use? What about front ends, visualization etc.? I've been asked to look at nagvis - no apparent epel package and nagiosql which appears to have halted development and supports only 3.x are there better tools? Any comments about FAN? looks a bit like what zimbra does for emails FAN does for nagios, or am I missing something? TIA Rob ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nagios, getting started
On 6/22/2015 6:04 AM, Rob Kampen wrote: What advantages does the RH/CentOS world have (if any?) over the ubuntu LTS world? I can't think of any compelling reason to run Nagios on RHEL/CentOS if the rest of your shop is Ubuntu. If everyone there is familiar with Ubuntu, it'll be easier for them to troubleshoot a problem if they don't have to learn a new package manager at the same time. If a vm is okay, what kind of RAM does it need? A VM is fine. I have Nagios monitoring 1,800 hosts and 17,000 services on a VM with 3 CPUs, 4GB of memory, and 20GB of storage. Whatever you do, set up MRTG graphing so you know how well Nagios is performing (http://nagios.sourceforge.net/docs/3_0/mrtggraphs.html) on your monitoring host. If you have many hosts and services to monitor, look in to the large installation tweaks and other advice in the tuning guide (http://nagios.sourceforge.net/docs/3_0/tuning.html). Also, Nagios causes constant disk activity temporarily storing and processing check results, so you can use a RAM disk to speed that up. I see epel has nagios 3.5.1 with a date of 2013 for CentOS7 along with plugins, is this the version folk use? - as the latest from nagios is 4.0.8 I still use 3.5.1. There was a compatibility break in 4.0 with Check_MK, an addition that's too valuable to lose. It's since been resolved, I think, but I haven't gotten around to upgrading yet. I will probably put it all together on a new CentOS 7 VM for maximum fun. I am under orders to use packages and not compile, a viewpoint I endorse. Are there other repos folk use? I use the distro package manager to manage Nagios' dependencies, but I compile Nagios myself for maximum control. It's really not that hard. What I would like to do next is get the best of both worlds and learn how to make my own Nagios RPM. What about front ends, visualization etc.? I use Check_MK. It can replace Nagios' own configuration files, but I only use that part for several Linux hosts. However, the LiveStatus pages is a Swiss Army knife compared to the stock Nagios pages (which are still available). And it's FAST. I don't use any Nagios-specific add-ons for Nagios' config files. However, since they are still just text files, I use a programmer's text editor (SciTE), version control (git), and rsync to move config files from the dev Nagios host to the production Nagios host to the DR Nagios host. Both Check_MK's LiveStatus pages and SciTE understand regex searches. Unfortunately, they use different syntaxes, but once you get the hang of them they're invaluable. Any comments about FAN? I don't know anything about FAN or any other Nagios configuration tools, but the moment you have to do something creative with your monitoring system will probably be the same moment you figure out it's not something automatic tools were programmed to cope with. Might as well get comfy with the config files from the start. -- -Chris ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
