Hello everyone,
We thought we would update you on development progress and let you know what is in the development roadmap for 2019.
We have recently released Mutiny version 6.2 containing the latest agents, updates and back-end improvements. The update is available as usual on the Downloads page. You will need to have previously installed the final 6.1 release before installing 6.2.
If you are a few versions behind, don't worry as you can follow the upgrade path on this page; www.mutiny.com/mutiny-support/update/
Recently released.
ServiceNow connector.
With the ServiceNow connector, organizations can fully integrate their Mutiny monitoring capability into the Incident Management, Event Management and Configuration Management processes within their ServiceNow instance.
Installing the connector facilitates quicker and more effective troubleshooting by placing monitoring information at the finger tips of your ITSM resolver groups. Mutiny’s ServiceNow connector allows for quick inspection of node details and monitoring history directly from the ServiceNow incident (or other task) record.
The ServiceNow connector provides a fast and glitch free solution to integrate your Mutiny monitoring system to your ServiceNow platform utilizing best practice integration techniques and implementation standards.
Features
- Outbound connectivity from Mutiny to ServiceNow.
- No MID server or inbound firewall changes required.
- Convert Mutiny events and alerts into ServiceNow Events, Incidents or Notifications
- Synchronize Mutiny nodes to the ServiceNow CMDB
- Create actionable tasks from Events
- Provides Mutiny node information from within ServiceNow UI
Mutiny REST API
The Mutiny REST API represents the various elements that a Mutiny system uses contained in a URL. This allows HTTP verbs to be used to operate on them.
Data is returned as either a JSON document or as a location header that should be used to retrieve another document.
Any user of the main mutiny interface can access the API with the same set of permissions as normal.
Documentation for the API can be downloaded from the website Mutiny_REST_API_Documentation.pdf
Improved Event-Acknowledgment Methods
We will shortly be releasing a major change to the way that Event Acknowledgment works in Mutiny. Currently, when a node is at a Warning or Critical Status, you can place the entire node into Acknowledgement which will then supress any further Alerts that might be sent from the open Events on the node. This also gives you the option to show, or not show, these open Events on the Wallboard. This is fine if the node has only a single open Event, but what if (say) Memory Usage and Disk Usage both go into Warning or Critical at the same time? The new method will allow acknowledgment at the Event level so that each of the individual monitored properties can be separately acknowledged if required. For example, if on a node, disks “C:” and “D:” are both at Warning or Critical Status, then you could choose to acknowledge the Event from the D drive, but not from the C drive. When you acknowledge an Event, you will be able to choose the length of time for which you want the acknowledgment to stand, from a drop-down menu of time options. You will also be presented with a dialogue panel into which you can add a Comment, perhaps to record why the Event was acknowledged. This comment, along with the username that was used to log in and set the acknowledgement, will be displayed in a new “Acknowledgement History” table.
New SMS Gateways
After a long search we now have identified a SMS gateway that can be used to forward SMS Alerts from Mutiny without the need for a modem or analogue telephone line. The gateways are manufactured by MultiTech and are fitted with a Cat 5 Ethernet NIC, external power supply and a slot for a standard UK mobile SIM card.
Mutiny can supply these gateways as a complete packaged service at £500 per year (+VAT), including an unlimited* number of SMS messages (* subject to standard UK fair-usage rules).
Alternatively, you can purchase your own gateway from us, specially configured to work with Mutiny, at a one-off cost of £450 + VAT. You will then only need to provide your own SIM card, on a suitable package, from a UK mobile provider of your choice.
2019 Development Roadmap
The following developments have been approved for 2019, although the exact date that each feature becomes available is still fluid.
Improved “Northbound” Alerting
Alerts from a network-management system that are sent to another application of process (rather than directly to a person or persons) are termed as being “Northbound”. The most common type of application to receive these is a “Helpdesk” or “Ticketing System” and the most common type of Alerts are SNMNP traps or tightly-formatted emails. As reported above, Mutiny now has a connector for ServiceNow and in principle, this can be extended to cover other systems that can raise trouble ticket via an API. Although Mutiny has always had this capability (starting with Remedy in the very first release), it has always been a bit messy, slightly ah-hoc and inconsistent. There is also a desire to extend it to use the “Tracked-Views/Events” method of configuration which will be much more convenient to setup and maintain. The plan is therefore, to re-write the Contacts pages to allow additional methods of alerting to be added (or removed) from each Contact. These will be generated with internal templates making it much simpler to add new methods in the future, as they are required.
New SNMP-Trap Logger
We are designing a new module for processing and storing SNMP traps. This will make it easier to see the trap history for each node that is sending traps & informs to Mutiny. It will also make it simpler for us to provide custom decodes for cases when the MIB is insufficient or just plain wrong!
Improved SNMPv3 Support
We are planning to increase the level of SNMPv3 support to cover all our older Adapters as well as newer systems. Please note however, that SNMPv3 should only be used with extreme caution as although the protocol is inherently more secure than SNMPv2c/v1, the increased complexity could actually make its implementation less secure. Unless a Kerberos key server is employed, it has been found that people have a higher tendency to write the passwords down on paper. My advice would be to use SNMPv3 for device configuration and SNMPv2c for system polling. This will limit the prevalence of SNMP higher-level security settings on a “need to know” basis. Also, please note:
· SNMPv3 places a higher load on the end systems
· Polling with SNMPv3 is slower than SNMPv2c
· It is very, very hard to use SNMPv3 informs as the explicit “EngineID” must be pre-stored in the NMS and these are usually generate on the fly by the end systems (use Kerberos to fix this).
· Microsoft will not support SNMPv3, although third-party agents are available
Active-IPAM™ Version 2.0
An upgrade to the IPAM module is planned for later in the year. Please continue to send us your thoughts/comments/suggestions so that we can incorporate all the feedback into the next specification.
Front-End Enhancements
We are still working on the specification list for this project, but it will include:
· Customisable “Smart Views” and more system-defined ones also.
· A new icon set.
· Additional customisable glyphs for OS type, and Vendor/manufacturer.
· Redesigned pop-ups and “roll-over” dialogue boxes.
· Methods for auto-generating Dashboards from nodes and Views.
And finally...
As always, many thanks for your ongoing patronage and remember that we mainly develop features suggested by our users, so keep them coming.
If you like Mutiny, please tell others as we pay a "Bounty on the Mutiny" for referals.
Kind regards
The Mutiny Team
