Idea Details

Provide TrapExploder tool with Spectrum

Last activity 05-04-2017 04:10 AM
Frank Tonjes's profile image
05-24-2016 07:44 AM

Hi All,


It is a great trap manipulation tool and see a lot of value packaged with Spectrum allowing us to use it to compliment TrapDirector. We have seen in some cases that you can improve performance by forwarding traps directly to landscapes for known devices, and then just let TrapDirector deal with traps it doesn't have model info for.


Since eHealth will is no longer a strategic platform it might be good to move some of the utilities to other tools. Perhaps even make this available to UIM/CAPM although I see Spectrum as the more obvious choice! (Maybe I'm being biased! )






05-04-2017 04:10 AM

Yes agreed. And I would say we should also clarify "are we allowed to deploy TrapExploder everywhere a Spectrum is installed without any licensing issue ?".

05-04-2017 04:06 AM

Now that we announced officially that eHealth will be soon EOL, Trapexploder inside Spectrum should be a must

09-12-2016 08:26 AM

That's a good idea for saving yourself some administrative overhead.

09-02-2016 03:15 PM

I agree, the most comprehensive infrastructure management is when you use as much as possible (while making sure it's useful and not duplicating other methods). Traps are the most reactive and 'cost-effective' (ie sending 1 trap takes less bandwidth and is more reactive than trying to poll each oid of a device every 5 mins).


I am also fully for using the REST API. It's something I have always believed that CA were not advertising it enough!

09-01-2016 11:23 AM

Scott, I am 10000% in agreement with you.  However, I constantly loose that argument.  We get the argument all the time that if the device detects a problem, it needs to send it (aka trap).  So we need to live with both and be able to intelligently handle both.

In our environment we have over 160,000 devices sending traps to our Spectrum environment.  Asking those device owners to understand a matrix of trap destinations and then scream at us when we change it due to adding new SpectroSERVERs and moving models, was a massive frustrating coordination effort.  About 5 years ago we went the route where we have a pair of load balancers that are the trap destination for all 160,000 devices.  The load balancers redirect the traps to the appropriate SpectroSERVER.  This is handled through load balancer configs that are updated every 30 minutes.  Those configs are built by a script that uses the Spectrum REST interface to dump the inventory, parse it out and build the load balancer configs.

As a plug for the REST interface, we tried to do this before the Spectrum REST interface with CLI.  It would take us hours to dump the inventory.  With the REST interface we can dump the entire device list that spans all 59 landscapes in about 5 minutes.

We tried trapExploder, but it couldn't keep up with our volume of traps.  The load balancers handle it without even blinking.  The one downside is that it doesn't handle Notifications.  Since the final destination is not the original destination, the feedback on the Notification fails.  So we just have the v2 Notification configurations set to trap only, don't listen for a reply.

08-31-2016 04:33 AM

I'm surprised by your comment, because indeed, we tested in very very large environment (more than 10,000 devices) and for several years, and we never noticed any trap lost. I'll try to run tests again when I'll have spare time!

08-24-2016 09:57 AM

I agree with Christophe "TrapExploder is a must have in large Spectrum environments!", but have you ever measured the input and the output of traps using Trap Exploder (TE)? Try it! You just configure two targets (Trap Exploder primary and backup) in all your devices. Feeding 1,000 traps into TE should result 2,000 traps output. You will see, that this is not the case in really large environments,. i.e. you will loose traps on the way through TE. So we used the TrapRouter in this large customer environment as an alternative with no loss of traps.

08-22-2016 04:09 PM

It's a good idea from the perspective of managing via traps.  The strength of Spectrum, though, is in its inference handling - polling devices judiciously, which largely dispenses with the need for cumbersome rule configurations and vastly cuts down on both processing and network traffic.  You could get fifty traps all resulting from the same network event, versus a few gets.

05-28-2016 06:10 AM

Yes, i second this too!

05-27-2016 05:19 AM

Yes, I fully support this too!

Consider an MSP, using Spectrum to manage their 100+ (some small) tenant customers, networks, who all have overlapping IP address domains.  Having a Spectroserver per customer or even a Secure Domain Connector would've been prohibitively expensive in on-going maintenance even if not licencing. So Trapexploder formed  a crucial part of the solution for this MSP to translate the embedded Agent address in trap headers. CA 'stabilised' trapx on April 17th, 2014. I knew of at least one 3rd party alternative that is more flexible to configure than trapx.


Moreover, given that CA Product Management are considering a drive to ensure  the needs of multi-tenancy are properly met - this would be the major ingredient in my opinion.

05-26-2016 02:20 AM

Yes, TrapExploder is a must have in large Spectrum environments! Please, add it into the Spectrum distribution!

05-26-2016 02:00 AM

Agree. We have Trap exploder running on Spectroservers which sends only the required traps to our landscapes and thus optimizing the performance.