Monitoring and reporting for Veeam Backup & Replication, VMware vSphere and Microsoft Hyper-V in a single System Center Operations Manager Console
Post Reply
mmcclung
Lurker
Posts: 1
Liked: never
Joined: Mar 04, 2009 2:04 pm
Full Name: Michael McClung

Post upgrade issues

Post by mmcclung »

I’ve installed the latest version 4.0.2 on two of our servers and followed the installation guide instructions. I noticed that a lot of the ESX servers show as Not Monitored and are greyed out and the OpsMgr Health service keeps stopping on the two servers where NWorks is installed on. I believe that's why the ESX servers showed up as grey in the OpsMgr console.

For instance some ESX servers show memory and CPU as Not Monitored but Network, Disk Storage etc. have a status.

Also I'd like to know the difference between Veeam Monitoring vs NWorks?

Thanks,

Mike
Gostev
Chief Product Officer
Posts: 31533
Liked: 6703 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Post upgrade issues

Post by Gostev »

Mike, I can answer your last question.

Biggest difference: Veeam Monitor is a standalone application, while nworks is a plug-in into your existing enterprise monitoring framework.

Functionality and feature wise, Veeam Monitor is shifted towards lower-level VMware Administrator responsible for monitoring and maintaining group of ESX servers. Veeam Monitor has pretty unique functionality to ease the actual low-level ESX performance troubleshooting: event correllation, guest process drill-down etc. It also has flexible built-in reporting to notify administrator about the issue before it starts affecting the users. Good reporting and trend analysis to watch your group of servers and be aware on upcoming bottlenecks.

Now, nworks solution is shifted towards providing insight on all VMware infrastructure to the enteprise monitoring team instead (the only way to provide this is to plug into the existing monitoring framework). So now enterprise monitoring team can get notified and see the problem no matter what server in what location is affected, see what applications are affected (new in 4.0), refer to the built-in knowledge base to better understand what is happening with ESX or specific VM, and dispatch the corresponding ESX administrator with recommendations on how to resolve the issue.

So both solutions complement each other very well.

Hope this helps!
Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests