[ale] Todays trends

Thu Oct 10 10:44:23 EDT 2013

Zabbix has better history functions, too.

Wolf Halton

--
This Apt Has Super Cow Powers - http://sourcefreedom.com
Security in the Cloud - http://AtlantaCloudTech.com<http://atlantaCloudTech.com>
Apache Developer wolfhalton at apache.org

On Thu, Oct 10, 2013 at 10:35 AM, Beddingfield, Allen <allen at ua.edu> wrote:

> I think the pretty web front end is what I like about Zabbix.  You don't
> have to be a Linux geek to administer it.  I can give one of our Windows
> admins rights to it, and a person who can't figure out how to exit out of
> vi can do everything they need to do from the gui.  Sure, you can extend it
> with some custom scripts you call, etc...  but you can get most of your
> monitoring configured without ever touching the commandline.
> Allen B.
>
> --
> Allen Beddingfield
> Systems Engineer
> The University of Alabama
> ________________________________
> From: ale-bounces at ale.org [ale-bounces at ale.org] on behalf of Wolf Halton [
> wolf.halton at gmail.com]
> Sent: Thursday, October 10, 2013 9:30 AM
> To: Atlanta Linux Enthusiasts
> Subject: Re: [ale] Todays trends
>
> I always liked administering nagios.  It was sometimes hard to understand
> since so many tutorials were only concerned with setting up sensors on the
> nagios server.  ssh to localhost?  What?  Once I had it sorted out, it was
> satisfactory.  I could turn off alert emails from knotheaded processes
> while I sorted them out.  It was an extra step to turn off alerts from
> machines that were getting offline maintenance.  I think you are right that
> some people who are charged with administrating Nagios, just want to look
> at the pretty web front end.  That is like you saying you administer the
> Gmail servers because you have a mail account.  lol
>
> Wolf Halton
>
> --
> This Apt Has Super Cow Powers - http://sourcefreedom.com
> Security in the Cloud - http://AtlantaCloudTech.com<
> http://atlantaCloudTech.com>
> Apache Developer wolfhalton at apache.org<mailto:wolfhalton at apache.org>
>
>
> On Wed, Oct 9, 2013 at 7:45 AM, Lightner, Jeff <JLightner at water.com
> <mailto:JLightner at water.com>> wrote:
> So the issue wasn't Nagios - it was the folks managing it.
>
> Nagios is a great tool and we use it in Production.   As you sort of
> allude to it is configurable so you don't have to use defaults.  Not only
> that it allows you to create your own monitors easily.   We've created some
> very esoteric monitors for various purposes such as snmp checks for air
> handlers,  web checks for a variety of different scenarios (they're not all
> as simple as seeing if the web page is responding) and determining which
> node of a cluster has the actual service running at this moment.   You can
> use snmp checks or you can do full scripting on your various servers by
> adding nrpe (UNIX/Linux) or NSClient++ (Windows).
>
> The benefit to using a monitoring system is you set it not for your
> "properly" configured but rather for what occurs when it quits behaving
> "properly".    It is much the same as performance tuning.  You set up
> things the way you expect them to work then adjust for the reality of what
> you're actually observing.
>
> The problem you describe happens with any monitoring system in which
> people managing the tool don't actually manage it.   At a Fortune 500
> company I used to work at we had a rather pricey monitoring system in place
> and it was somewhat annoying because all it really did was page me
> endlessly in the middle of working on a problem.   Nagios at least allows
> end users to acknowledge problems once they occur which:
> a) Lets others who see the alert see also that it has been acknowledged.
> b) Stops sending out needless emails and pages until the issue clears.
>
> It is amusing to me that we have a group here that complains they don't
> want our Nagios alerts because they say they do their own monitoring but I
> often have to let them know when something is down because I see it in
> Nagios and they don't have a clue it is an issue until I tell them.
>
>
>
>
>
> -----Original Message-----
> From: ale-bounces at ale.org<mailto:ale-bounces at ale.org> [mailto:
> ale-bounces at ale.org<mailto:ale-bounces at ale.org>] On Behalf Of Jeff Hubbs
> Sent: Tuesday, October 08, 2013 5:33 PM
> To: Atlanta Linux Enthusiasts
> Subject: Re: [ale] Todays trends
>
> My experience with Nagios in production was a bad one but only because the
> people who were doing it paid no attention to the nominal operating
> behavior of the servers being monitored and relied on dead-stupid
> broad-brush configurations that alarmed all the time uselessly.  And they
> wouldn't revisit their configurations in any sort of reasonable way
> because, well, that was *work*; you had to *think*!  The moral is that in
> typical (by which I mean over-servered in the extreme) environments, in
> order to use Nagios effectively you wind up having to put in the kind of
> thought and effort that would have best been put into setting up reliable
> systems in the first place.  It's a bit like a racing team putting half
> their effort into the efficiency of their tow trucks. :)
>
> A Puppet set up I encountered as my IT career was ending had a similar
> problem, but it tended to hold everything back; whenever you wanted to
> advance anything - change to a new version of a Linux distribution (if
> you're stuck in that kind of goat-rope) or introduce a new distribution
> - you had to drag the Puppet implementation along collaterally and it
> seemed as though people would rather run ancient versions of stuff and
> suffer those consequences than do the dragging.  If anything, it seemed to
> me that Puppet and the like get used to facilitate practices that shouldn't
> be occurring in the first place:  server overprofileration.
>
> On 10/8/13 4:11 PM, JD wrote:
> > On 10/08/2013 01:46 PM, Boris Borisov wrote:
> >> Back in mid 2000's when I was working actively on Linux servers my
> >> major tasks were related to settings firewalls, LAMP servers,
> >> networking, ISP user traffic management (today maybe irrelevant since
> >> users have unlimited traffic), Qmail servers etc. Every install had
> >> own hardware except VHOST sites and mail servers.
> >>
> >> I want to get myself up to date so please just number few of the new
> >> hot technologies used by Linux administrators.
> >>
> >> I assume these two are "hot": Virtual servers and cloud computing.
> > DevOps, CM-tools, monitoring, alarming, alerting Nagios, Splunk,
> > Cacti, OpenNMS, Puppet, Chef, CFengine, Ansible are a few of the
> > tools, but there are many others.
> >
> > When deploying servers to a public or private cloud, can you scale
> > from 5 to 500 servers easily with your deployment tools AND not be
> > tied to a single cloud provider?  Are the deployment tools
> > another-mouth-to-feed or do they really make things easier,
> reproducible, more secure, more flexible, idiot-proof?
> >
> > OpenStack seems to be gaining traction in the Fortune 50 world too.
> > They aren't throwing VMware out completely, but they are looking to
> minimize that technology.
> >
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org<mailto:Ale at ale.org>
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> >
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org<mailto:Ale at ale.org>
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
>
>
> Athena(r), Created for the Cause(tm)
> Making a Difference in the Fight Against Breast Cancer
>
> ---------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
> information and is for the sole use of the intended recipient(s). If you
> are not the intended recipient, any disclosure, copying, distribution, or
> use of the contents of this information is prohibited and may be unlawful.
> If you have received this electronic transmission in error, please reply
> immediately to the sender that you have received the message in error, and
> delete it. Thank you.
> ----------------------------------
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org<mailto:Ale at ale.org>
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20131010/18d1ea64/attachment-0001.html>