This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.

You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Re-assign a managed transaction to a different playback location?

joedissmeyer over 9 years ago

Question,

Is there a way to simply re-assign or 'move' a managed transaction monitor from one playback location to another? I ask because I can see running into a situation where a player load starts to reach capacity and I'll need to move a transaction from one location to another to relieve the stress.

Take this situation for example:

I am currently monitoring a transaction against Google.com.
The player load is approaching 70% on the server where the Google.com transaction is running.
So I want to 'move' one transaction monitor to another location (in the case of the screenshot above, that would be QA #2) without losing the historical monitoring data.

So far what I've discovered is that I would need to assign the Google.com monitor to the QA2 location first (effectively 'duplicating' the monitor to another location) then delete the monitor from QA1 to free up resources.

The problem with doing this is that once you delete a monitor from SolarWinds all of it's historical data is deleted from the SQL database as well. So I don't want to delete the monitor because there may be very good polling data that we would need for reporting and historical reasons. Instead I would prefer to 'move' the monitor from one poller to another to relieve stress on the system. We can do this in SolarWinds NPM and SAM where you can change your polling engine. So I am hoping it is possible to do the same with this product.

So, is it possible to move transactions from one location to another without deleting them?

*** I am running WPM v2.2.

- Joe

Top Replies

0 ZZamazal over 9 years ago

Hi Joe,
Although I am no longer active user of this product, I would say following :
A transaction is always unique combination of a recording and a location. Transaction is tied to location and therefore it cannot be moved with all historical data. The difference between transaction and recording is that transaction is a recording assigned to a location.
Recording 1 + Location A = Transaction 1A
Recording 1 + Location B = Transaction 1B
I can only recommend assigning the recording to another location and unmanaging the first transaction, without deleting it.
Regards
-Zdenek
Cancel
Vote Up +2 Vote Down

Cancel
0 romeyde over 8 years ago in reply to ZZamazal

Hopefully this gets addressed in a release soon.   This is an issue we deal with frequently. I thought I remembered seeing it on the roadmap a long time ago.
Just this week I had to move 40 transactions off of one player onto another so the player could be upgraded.
This took me a couple of hours to accomplish and I of course loss all historical data.
Even better would be our request to have a 'pool' of players so we don't have to assign transactions to specific players at all and instead to the pool.
It's time to run transaction A, transaction A is assigned to pool A which consists of 5 players.   WPM simply runs transaction A on the least loaded player in pool A.
Currently, if a player goes down for any reason, we lose all monitoring that is assigned to that player.   This is a big deal. With a pool, we can lose a player and no monitoring is affected.
Cancel
Vote Up +3 Vote Down

Cancel
0 klinejw over 8 years ago in reply to romeyde

Agree...this should have been addressed by now. This along with some other bugs I have reported in the past are preventing this product from going to the next level.
Cancel
Vote Up +2 Vote Down

Cancel
0 bhilgenkamp_botw over 7 years ago in reply to romeyde

I really like the idea of a pool as it would allow some automatic failover in the event of a failure. Just this week I had a player randomly stop working and had to work with SolarWinds support to fix it (they were unable to determine the root cause and simply had me re-install the player). We lost all availability information for the applications being monitored from this server during the duration of the failure. A pool would have prevented this. At the very least though it would have been extremely useful to temporarily move those transactions to other players while the problem was corrected.
Cancel
Vote Up +1 Vote Down

Cancel