Apr 12, 2012 12:32 PM
Small Consulting Opportunity
-
Like (0)
Hi All,
We are looking for some help with a Zenoss installation. Below is a summary of what we have setup, where we are seeing, and in which areas we think we could use some help. Also some questions for those people who might be interested and able to help us.
We installed Zenoss ourselves, following the general documentation, made it work, have been happy with what it does for us. We have about 75 devices that we are monitoring. These are mostly linux blade servers and Cisco routers/switches. There are a few windows servers that we have added more recently, need to really understand their monitoring better. Zenoss runs on it's own server, we also run RANCID on this server for doing config backups of the cisco devices, but generally it is on its own server. The server is a 4 core, 4GB RAM, 10K speed disks. Feels like more than enough for Zenoss (perhaps?). We are running Zenoss on RHEL5.5. Most of the devices we monitor are local. We have a very small set of remote devices that we monitor over a VPN.
We've been using this setup for some time, and occasionally we get alarms that processes on servers have failed, or servers are down. From looking at things what we can tell these are false alarms. This isn't ideal, and is something we'd like to fix. We don't really know our way around optimizing Zenoss. We do often see zenmodeler take 100% of one CPU core. Apparently this isn't multi-threaded or we're just not setup ideally? This hasn't reached a pain point yet, but certainly we're at the point where I'd like to make things better.
We would want someone to look through the config and make improvements. The areas would be: 1. fix what we haven't configured, or haven't configured properly with the installation / general overall setup. 2. Look at how we monitor blades / servers / processes and suggest improvements. Generally we're using ping, SNMP, and process monitoring. Perhaps in some places this is overkill. 3. Establish templates for new devices / clean up existing devices of each "kind". 4. bring us up to date as we haven't upgraded Zenoss in longer than I can remember. This feels not critical for me, but perhaps there are large performance improvements to be had.
I have the impression that someone with a good working knowledge of Zenoss could likely find a handful of massively flawed things we are doing in a very short time and provide a huge benefit for the time spent. This is mostly item #1 above.
Hi Jim,
I have a few clients for whom I have done something similar to what you are asking.
You have probably found my CV around, but if not, go here -
http://www.skills-1st.co.uk/ . I have been around the systems
management part of the industry for over 20 years, many of them around
IBM and the last 5 years or so, I have focused much more on open source
solutions, especially Zenoss.
I do a mixture of teaching and consultancy and have developed a couple
of Zenoss workshops that have run several times, both in classroom
environments and using remote-teach technologies. If you found me here on
the Zenoss forum then you probably know that I have been contributing
responses, documents and ZenPacks over several years.
I have a number of clients for whom I have done similar Zenoss work to
what you propose. These days, I actually have more remote clients that I
have never met face-to-face, than those that I actually visit! We find
that a combination of Skype and remote access to a client's Zenoss
system, works well. For access, we have a fixed external IP address; so
some folk simply open ports 8080 and ssh for our source address to their
zenoss server. We have also used nx, VNC, Citrix and various VPN
technologies.
Typically an engagement starts with a healthcheck to understand your
environment and provides written recommendations. Typically this is 2
days - depends on the size of the environment and how many issues there
are with it. Simple issues I will generally fix in the 2 days.
Once we agree what needs changing, we can work in 3 ways:
1) I fix it
2) You fix it
3) We fix it - generally I've used VNC as a screen-sharing technology
though I have also used join.me
Depends entirely on you. My feeling is that folk ought to insist on
skills transfer whenever they use a consultant, but often workloads
don't permit. Looks like you are US East Coast so the time difference
shouldn't be a big issue.
Some folk then setup an ad hoc support contract - typically between 1
and 5 days - to fix problems as they arise. We cannot offer a formal
9-to-5 support contract as I have other clients and commitments but,
other than planned holidays, I am generally contactable
one-way-or-another, most days and will respond to issues as quickly as
possible. For such contracts, I generally provide a weekly timesheet
for work done so we all know where we stand. Billing is monthly or at
the end of a contract, payable 28 days after invoice date. Rates for
remote work are £800 (GB pounds) / day.; "days" are typically made up of
hours spread over a much longer period. We will only bill for work
actually done; if you setup a 5-day contract and you feel we have
finished in 3 days, you get billed for 3 days.
With regard to your points 1-4, I think the 2-day healthcheck will
probably tackle points 1-3. Updating Zenoss depends rather on where you
are starting from and where you want to get to? Also, the number of
ZenPacks installed can have a big bearing on this. If you are at a
Zenoss 2.x then it is probably worth upgrading to 3.1 or 3.2.1 - depends
very much on exactly what ZenPacks you have installed. If you are at
3.1, I personally would stay there. 3.2 wasn't good and although 3.2.1
fixed many issues, it broke some more ZenPacks. 4 is currently in alpha
but I wouldn't be anticipating putting that anywhere near production
this side of summer.
Does that help?
Please feel free to discuss further.
Kind regards,
Jane
Follow Us On Twitter »
|
Latest from the Zenoss Blog » | Community | Products | Services Resources | Customers Partners | About Us | ||
Copyright © 2005-2011 Zenoss, Inc.
|
||||||||