My MV Bot for Slack is progressing nicely. This allows MV VARs and sysadmins to proactively monitor and get notifications of local and remote server events. It notifies a Slack channel with events, and any authorized person can get the data from any device or browser.
If you’re not familiar with Slack or how it might apply to MV,
see a blog written by Kevin Powick (since this writing, Kevin shutdown his blog).
The idea here is to help Value-Add Resellers provide more pro-active value-add services, by knowing about problems perhaps before they become critical. This can be offered by VARs to their clients, beyond standard DBMS and application maintenance. And I’ll also offer to monitor systems for end-users or VARs.
I started writing a notification system like this many years ago. With the initial version I needed to create my own network/server environment to support it, and that got to be a hassle for this application. Now with Slack being so popular it’s easy to base an offering on that platform – and then expand from there as required.
Welcome to … mvManager ?
mvHuh? The working name for this now is mvManager. Unless someone else has already used this name I might go for that. I’m getting a little tired of NebulaX names, and a little tired of mvNames too. But I’m not that particular about names in our industry. The original product was called NuRSE: The NebUla Remote Support Environment. The docs had a Nurse icon, and a medical metaphor for technical support people healing sick systems. Sure it was kinda cutesie, but it’s nice to have a little fun with a product. This is all still in the air.
So what does mvManager tell us?
Example events right now include a D3 boot up or shutdown, backup start/end, frame usage, and when BASIC errors or specific system events occur. Do note, demos of this are available for this right now, though it is not yet being offered for sale.
Enhancements over the next few days will include notifications when backups are Not done, when D3 is Not up, spooler issues, license consumption, and threshold changes in disk, CPU, memory. Application KPIs can be monitored with custom code via a pluggable design. Depending on how far I get with this, v2 will support other MV platforms and other DBMS and OS-level metrics. Notifications will also be optionally sent by email and SMS. At some point I’ll check for things like pending license expiration, or even notifications when a new DBMS release is available for a system using the service.
One of the cool things about this is that it’s completely modular. So I’ll provide a number of modules which sites can enable or disable as they please. If you don’t care about frame usage, disable the module that checks it. Or if you only want that check performed once per day it’s already easy to tune that frequency. As new ideas come in I just need to create new modules and plug them in. And sites and vendors will be able to plugin their own components as well – it’s just BASIC code, and that can interface with other code at OS/network level if you wish.
Since all of this data is being gathered over time, metrics will be available for charting. So you’ll be able to see frame usage change over time and estimate the need for a restore or more disk. You’ll also be able to compare data across systems, to get an average backup time for all clients, average up-time, or to identify sites that have an unusually long backup time or month-end close time. You’ll also be able to spot the sites who don’t get backups regularly.
From the “Wouldn’t it be really cool if it went the other way” Department…
I already have partial support for server actions initiated from Slack. So you’ll get a notice that BASIC errors are occurring, but if you want to get a full report from a client system you’ll just need to enter a command into Slack like “/admin serverID list-runtime-errors”. Depending on some details (like how big the report is) you’ll get the report on your current device. Or you’ll get a link when the report is ready so that you can just click and view it in a browser. Taking this a step further, when a VAR has application updates they’ll be able to get notifications to their clients through this medium and perhaps even do some of the updates. What’s important here is that it’ll be easier for service providers to spot and remedy issues across their client base. And with the ability to use this from any OS, PC, tablet, phone, or browser, there’s no such thing anymore as being out of touch.
As to pricing and other production-time details, I don’t have a clue. Info about that will be provided when the time comes. A VAR might want to offer this as a for-fee value-add service. But they might want to offer it for free too. Knowing about problems in advance can save a lot of time=money. Just think about how much it costs to solve unexpected problems. It’s often far beyond what we earn in reseller commissions. So offering this for free might be a self-defensive investment in preventing losses. I might even offer this to end-users so that I can monitor their systems, and just advise VARs by email when something important happens. So end-users get the benefits without their VAR needing to do anything. We’ll see…
If you’re an end-user getting support from another company, what info would you want your VAR to get when some issue occurs? Out of balance month-end? Program failure? Unusual login activity? Hits on your website? Unusually long reporting time? Unusually low order counts? Server patch notifications? Talk to your support provider and then let’s all talk together. Are you an end-user who gets support directly from your DBMS provider? That’s fine – I’ll be happy to work with all partners.
For now, more ideas for things to monitor are welcome. What events would You want to know about with your system or for your clients?