Hi Bastian
To your points:
-Yes, we are SaaS only. This does mean that an outage of our service can mean monitoring is out. Obviously we try to prevent this. :-) It is in fact a very rare occurrence for our service to be down, in a way that impacts monitoring and alerting. We did actually have a 12 minute such outage this year, caused by an error in a script that updates DNS records. This affected about 10% of our customers, for about 10 minutes. Prior to that, I dont believe there had been such an outage for over a year.
- the more common outage we post is about our external web site checking (where we test the reachability/performance of websites from various places). As we have test nodes spread around the internet, the test nodes are more subject to various internet issues.
- our main service is less subject to internet issues, for a few reasons: it has multiple top level ISPs; it is designed to route around BGP failures. (Data being reported back from customer sites will try to use regular BGP transit paths, but if they fail, it can reroute via other application forwarding nodes we run around the internet - so if a direct path from the customer to their main site is not working, it may route via Singapore, or the north west USA.)
- plus, of course, we have a 24 x 7 NOC staff on call, focussed on nothing but the performance and availability of our applications. Something that can not usually be said of premise based systems.
Custom monitors are certainly possible. Data can be collected using a variety of collection protocols (SNMP, WMI, JMX, http content interpreted by JSON/XML/Regular expression, various APIs (NetApp, Vmware, etc), and so on.) While LogicMonitor does have datasources for virtually all hardware and software found in a datacenter, it is fairly easy to write a datasource to collect whatever you want, provided it is exposed. So we have customers pulling data out of databases via SQL queries to plot the $/minute flowing through ad networks, for example. You can collect custom JMX mbeans; perfmon counters, or whatever you wish. This data can then be graphed, alerted onm escalated, and aggregated, like any other data we collector.
You can certainly collect data via XML. Our web page collector system has built in XML interpretation. If you find there is custom collection that is too complex to be done in our standard collectors (say, for example, you wish to collect data from three different we pages, and create a compound metric that is derived from content on all three), you can also easily extend collection using embedded groovy scripts, that can call whatever groovy libraries you wish (although again, we expose a lot of groovy methods from our collector, to make this easier.)
Powershell is also possible. Any scripting language supported by the collector platform (which can be linux or windows) is possible. We generally recommend groovy, as its supported on both platforms, and has some other advantages, but some of our own windows specific datasources use powershell.
Feature requests are brought to us in several ways: support requests; posts in the forum; or direct customer discussions. Sometimes its a clearly good idea, and we implement as soon as possible. Sometimes we solve the problem in a different way. Sometimes we get a request that is only appreciated by a single customer, which will not be acted on - but oftentimes we'll acquire further customers with the same needs, and do so. The metrics we look at depend on whether we are adding functionality, or easing workflows. Requests that add functionality generally require higher standards, as we do not want too complex a product.
There are a variety of differentiators. Whether it is worth it depends on your situation. We tend to cover a lot wider range of devices (network, servers, storage, power, virtualization) and software. We automate a lot more of the device management: if you add a device, say Citrix Netscaler, we will discover not just all the VIPs and content switching VIPs, and set up monitoring appropriately - we will also keep the monitoring up to date. So if you later add more VIPs, or enable compression, or global server load balancing - the monitoring will notice, and start monitoring those new features. Our view is monitoring is too complex to be not automated. You need a very good engineer to determine what to monitor, and to maintain the monitoring, for each specific class of device. And those engineers will be better deployed adding more strategic value to your company. We are SaaS based, which certainly tends to work better for companies with many datacenters or sites (avoiding VPNs, etc), but also ensures that you are not subject to the "I didn't know my datacenter was down because that was the one with my monitoring in it" issue. We dont limit on interfaces or anything else. And our support is both very good (being staffed with people with operational experience, in US and England) and very accessible (with embedded real time chat in the application). Our company culture is that we are here to help our customers deliver excellent service to their customers (those who use the IT infrastructure.)
In summary, what most of our customers have found is we give better monitoring with much less staff resources required, as compared to their prior monitoring.
Let me know if you have any more questions.
Best Regards
