nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

ipMonitor v8.5 vs v9.0?

hemlock

Currently have 4 installations of ipMonitor v8.5 with 5000 license each. Using a 500 monitor license, we are testing v9.0 to ensure that it is compatible with a few SOAP applications we have developed.

To detail a couple of manual steps we do today for v8.5. We have individual "Application" groups and HTTPS/HTTP monitors are created by hand and added to the appropriate group. Dependencies are setup as needed. Also, each "Application" group is assigned to a corresponding alert to send emails/text to the correct group/s.

In testing with v9.0, we are trying to create these HTTPS/HTTP monitors individually but it appears that it can only be created when a "Device" is in place? I've ran through the Admin Guide and it describes the use of the Device wizard. We do not want to create a "Device" just so we can add an HTTPS/HTTP monitor. As well, when creating a new monitor through the SOAP interface, it is successful but is then considered "orphaned".

Based on the new version, what is the thinking of using devices as opposed to just simple group structures? Is something being missed or undocumented? Or are we now limited to only adding monitors to devices?

Find more posts tagged with

Accepted answers

All comments

Peter.Cooper

Hello hemlock.

Based on the new version, what is the thinking of using devices as opposed to just simple group structures? Is something being missed or undocumented? Or are we now limited to only adding monitors to devices?

There is a singular rule with regard to adding new Monitors: Monitors must be owned by one of the following: a device or "Orphaned Objects". Once it's added, you can then add it to any "regular Group" you want. (Technically, it should belong to a device not orphaned objects. This may not fit your application view though.)

SOAP applications tuned to v8 will leave the Monitors in Orphaned Objects. My suggestion is to create a singular device with a known ID, and add new monitors there (assuming you're not going to manufacture devices). Once that's done, the Monitor will no longer be hanging out in that orphaned group. IF you can't modify the source of the application, you can just create a device and move the orphans in manually from time to time.

jonchill

Peter

If I was to create a device say a server and unticked everything because all I want to do is monitor a telnet session does that mean I'm using 2 monitor licenses or does the device in itself not use a monitor license?

Is it possible to create a device and move an imported montior onto that device so it makes everything consistant?

Thanks

Jon

hemlock

Peter,

Thanks for the reply. I can understand the use of Devices in v9.0 since most environments do monitoring against individual "devices". Our dilemma is that when we upgrade from v8.5 to v9.0, we will have close to 10,000 monitors in two separate installs as orphaned monitors. I would assume the group structures, dependencies and assigned alerts would still be in tack, but if we were to begin adding new monitors, the process would then need to change and all exisiting/upgraded monitors would require addition to a device.

Is there a particular reason to force monitors in v9.0 to be associated with a device? Our particular environment does not adhere to a per device monitor strategy. Any one of our monitors against an application URL could and would easily be placed against a separate "device" with a simple DNS change. I can see how adding a single device and placing EVERYTHING under that would work, but why the sudden change? I would rather see everything live under the Orphaned group but manual entry doesn't even allow that. At least have the ability to add an orphaned object and then assign to a device when needed.

Thanks again.

Peter.Cooper

Hello Jon,

If you have a device monitoring just one thing, that's just one license. Devices won't take up a Monitor license.

To answer your second question: You got it. Add an empty device and you can move Monitors from Orphaned Objects into there.

hemlock

Peter,

In an attempt to test out new setups, we try to add a new device but receive the message that it is not valid because of spaces in the IP address, Netbios name or domain name. This I can understand but then you are allowed to go into that Device and easily modify the name and add in spaces.

Two questions in regards to this. If we are allowed to modify the name without some type of validation, would it be an option to allow the name to originally be added with spaces, etc? Also, it appears that the SOAP interface hasn't change since v8.5. Do you know if additional methods will be added to support the addition/modification/deletion of devices?

Thanks.

Peter.Cooper

Hello hemlock,

I would assume the group structures, dependencies and assigned alerts would still be in tack, but if we were to begin adding new monitors, the process would then need to change and all exisiting/upgraded monitors would require addition to a device.

You're correct. Your alerting and suppression settings are intact from v8.

Is there a particular reason to force monitors in v9.0 to be associated with a device?

Yes. We went through a very sizable effort to help new and existing more easily associate the things they monitor to a physical entity. There's lots of management (manual and automated) value to knowing that there's a relationship between monitors "running" on the same device. i.e.: At a glance you can tell if anything else on the physical device is malfunctioning. You can more easily set dependencies on all the monitors running on the device (like a managed switch).

Having devices and the forced association (even if you don't need it) will help to unlock new functionality we couldn't do otherwise. It was also a requirement to managing arbitrary logical grouping. Without having a hard and fast rule about what "owns" what, we found that nested groups would be unpleasant to manage over time.

Not leveraging devices means you'll have a different experience of version 9 than we intended. A hybrid between v8 and v9 that might feel a bit off. I don't really recommend it, but by the sounds of it, you right a organized and tight ship. My suggestion is to run a separate ?eval? v9 instance for a couple weeks, and experience the difference just so you know you're running optimally for your installations.

Note: If you're intent on wanting to run everything in the Orphaned Objects Group, do a (important!) monitor-only xml export . Next, use regular expressions to find and replace the parentid to "0" then re-import and then restart ipMonitor. i.e.: regex: "[<]parentid[>]-?[0-9]+[<]/parentid[>]" with: "<parentid>0</parentid>".

Peter.Cooper

In an attempt to test out new setups, we try to add a new device but receive the message that it is not valid because of spaces in the IP address, Netbios name or domain name. This I can understand but then you are allowed to go into that Device and easily modify the name and add in spaces.

Overzealous validation strikes again. I've noted your remarks for a future work item. As to the implementation on how it'll be done, I don't know quite yet, but all of your remarks will be right there for the reading.

Also, it appears that the SOAP interface hasn't change since v8.5. Do you know if additional methods will be added to support the addition/modification/deletion of devices?

Beyond making sure that ipMonitor v9 concepts are upheld via the existing SOAP interface, there haven't been any adjustments. You can currently manipulate devices (add,edit,delete) as you would a Group. The distinguishing characteristic for a device is the "typeid" value (which you'll see with an XML popup).

hemlock

Peter,

It does appear that the GroupListDesc() method returns Groups and Devices, with there Type and TypeDesc being different of course. With this understanding and a few changes on our end, I think our setup will benefit from this. We have a pretty complex web application that allows multiple groups to create HTTP/HTTPS monitors for individual URL's and they are assigned to he appropriate group. The same is performed for new systems that come online, scanned for standard, CPU, Network, Memory, Ping, and any services that match a provided list.

ipMonitor has always been a top notch application. After getting accustomed to the new features and ways of functioning, I think this will be a great release.

Thanks again.

unixbeard

Yes. We went through a very sizable effort to help new and existing more easily associate the things they monitor to a physical entity. There's lots of management (manual and automated) value to knowing that there's a relationship between monitors "running" on the same device.

Agree with you in general, and once I'd finally got my head around how the dependencies actually fitted together it has certainly made our v8.5 installation a lot tidier.

However, you say that not using devices is not recommended, but in that case what is the recommended way of dealing with monitors which are designed to monitor non-physical entities? For example, while the majority of our monitors do reference individual servers or other equipment, we have two other groups of monitors which confirm that services across our platform are working correctly. One group does a series of DNS QA checks on some of our key DNS records to confirm that they return the expected result. Which of our nameservers returns the result isn't important, that the result is correct is. The second group confirms that e-mails are passed correctly through our mail platform. We have individual monitors to check the different mail servers themselves, but these monitors check that the complete route can be completed, eg from the sender, through the various screening servers, and on to a final server for collection. So the monitor doesn't really "belong" to any one device, or for that matter any one location either.

So I just wonder the best way to set these monitors up when we upgrade to keep them working, without causing any issues by not using the new methodology.