Ubeity

Ubeity is a third-party (not endorsed or supported by the Blue N) monitoring (events and performance) utility for NetApp 7-mode filers.

The plan is to implement event monitoring and add on performance monitoring as well as provide a framework for addition plugins.

Eventually support for additional appliances/devices is planned (e.g. c-mode filers).

I would also love to tie in filerview (or System Manager) management into this program, but that may be biting off more than I can chew. It's certainly on my wish-list if I can get some help coding this.

Doesn't the Blue N already provide comprehensive, enterprise software for monitoring?

Yes. It's called DFM/Operations Manager/OnCommand Core/OnCommand Unified Manager or ONCUM. I'm quite familiar with it as my day job is supporting it. I have a number of gripes with it (not the least of which is its name) and have claimed I could do a better job. So ubeity is my attempt to put my code where my mouth is.

Improvements over DFM:

• Limited scope
  • Like many programs suffering from creature feep DFM has become a sprawling mess of half thought-out features. Being a unix-guy I very much support the idea for tools to do one thing and to do it well.
• No Java. No browsers.
  • DFM's core services are written in C for speed and efficiency, but the webui and the Management Console is written in Java. The main UI is a webapp. I am a fan of neither java and web-based UIs. Taking into consideration that NetApp does not recommend multiple instances of NMC running at the same time (as it puts a load on the DFM server) the client-server architecture does not make any sense. Many customers want to run the client on the same machine the server is running anyway (as it matches their workflow of logging into machines via rdp to do their administrative tasks).
• Not Supported by NetApp
  • This is more of a feature for myself.
• Low memory usage / small package size.
  • The DFM installer is several hundred megabytes. This is largely due to java and the need to include all supporting libraries
• DFM is slow.
  • DFM's slowness is partly due to the slowness of the machines its communicating with. Ubeity does its best to conceal filer lag from the user.
• Open source
  • DFM is proprietary and closed source.
  • DFM uses sybase. Ubeity uses sqlite.
• Ubeity only requires SSH.
  • DFM relies on many ports and protocols for all its features (snmp, ssh, rsh, http, https, NDMP). Granted, not all of these are required for monitoring.
• Ubeity only uses ssh keys.
  • Ubeity does not store passwords. Filers must be configured to use ssh keys.
• ZAPI is not used.
  • ZAPI is ontap's API and it is, IMHO, terrible. Command wrapped in XML sent over rpc/http. ZAPI does not tie into the same API that the commandline is tied into and there are inconsistencies between ZAPI, the ONTAP CLI, and SNMP. Confusion and ambiguity are reduced by using just the CLI (which should be the most accurate).

The back-end is a single Tcl process (that dispatches asynchronous Tcl procs for filer communication). The front end is integrated into the back end. The UI can be launched via a SIGUSR1.

Any processor or memory intensive operations are tucked in to a C-based tcl extension.

While I am a NetApp employee, no inside knowledge or code owned by NetApp was used in the creation of Ubeity. Ubeity is a personal pet project not supported by or endorsed by NetApp.

All opinions expressed on this page (and indeed this site) are that of Matthew Hiles and not NetApp.