MQ Admin at a financial services firm with 501-1,000 employees
Vendor
Jun 25, 2014
We have been using IR360 for about 2 years now. We have very diverse hardware z/OS, AIX, Linux, Windows. Our middleware infrastructure consists of clustered, multi instance message brokers, multi instance qmgrs, Active-Active, Active-passive HACMP. The product works well with all the platforms and handles the HACMP configurations with no problems. It is very simple to deploy. I was very impressed with the product and the support is first rate. I know that it must be very competitively priced otherwise we would not have purchased it. We did a POC with it before purchasing it so we had a very high confidence level and it did what the vendor claimed it could do!
Search for a product comparison in Application Performance Monitoring (APM) and Observability
Price was certainly a HUGE consideration for us, but who cares what it costs if it doesn't work. For us, the solution is simple to implement, it's intuitive, it works and while we bought it for MQ we are beginning to use it for http services, and evaluating it for EMS as well as other service stacks. We are a 2 man MQ shop with well over 100 qmgrs to manage and monitor and IR360 helps us keep cost and man hours down. I've been working with MQ since 1997 and was an engineer for the QPasa product for about 5 years so I've evaluated LOTS of solutions. Infrared360 is an excellent balance of cost, usability, reliability, scalability and it's just easy to implement and use.
While I do not have the product, I would lead you to ask some more questions. Does it help you know where the messages are going to and thus discover the whole path of the message request / reply?
In a thought to be simple MQ / Broker system we were surprised to discover the number of interactions taking place with our WebSphere Apps using MQ to request data. We were using request/reply queues for real time requests / response and thus our online response time was impacted by the number of message and number of hops that a message was taking before a full response would be sent. We discovered that many MQ messages were creating a flood of MQ requests to other services one layer deep. This was discovered once we had use Network Traces and exploding the MQ header information to discover where the MQ Broker messages were going. This led to major changes in the backend systems to retire technical debt. We finally got to the rewrite of those older MQ bandaid systems because of insight gained.
Look for a tool that gives you the whole picture. We had to write our own tool, but surely they exist by now. That was 3 years ago and the concept was shared with a number of vendors asking for their help for development.
This tools monitors a major item, queue depth and this gives a good clue to a problem. You need to start somewhere.
The full information is carried in the network packet and in the MQ header. These values allow you to stitch the messages back together to understand the full flow of request/reply.
Application Developer Manager at a tech company with 10,001+ employees
Real User
Top 20
Jun 19, 2014
I would suggest checking out also Stackify, We are using it for DB and servers monitoring as well as overal app performance & error and logs management. You may want to talk to them as I think they are coming with some new relevant features
Avada Software specializes in Enterprise Middleware solutions. Founded by some pioneers in SOA, MQ and J2EE technology, Avada’s Flagship product, Infrared360, is a holistic & innovative private cloud enabled portal providing self-service administration, monitoring, load testing, auditing & statistical reporting for Enterprise Middleware including IBM’s middleware stack of MQ, IIB (message broker), WAS, and Datapower, as well as other applications servers such as JBoss, TC...
We have been using IR360 for about 2 years now. We have very diverse hardware z/OS, AIX, Linux, Windows. Our middleware infrastructure consists of clustered, multi instance message brokers, multi instance qmgrs, Active-Active, Active-passive HACMP. The product works well with all the platforms and handles the HACMP configurations with no problems. It is very simple to deploy. I was very impressed with the product and the support is first rate. I know that it must be very competitively priced otherwise we would not have purchased it. We did a POC with it before purchasing it so we had a very high confidence level and it did what the vendor claimed it could do!
Price was certainly a HUGE consideration for us, but who cares what it costs if it doesn't work. For us, the solution is simple to implement, it's intuitive, it works and while we bought it for MQ we are beginning to use it for http services, and evaluating it for EMS as well as other service stacks. We are a 2 man MQ shop with well over 100 qmgrs to manage and monitor and IR360 helps us keep cost and man hours down. I've been working with MQ since 1997 and was an engineer for the QPasa product for about 5 years so I've evaluated LOTS of solutions. Infrared360 is an excellent balance of cost, usability, reliability, scalability and it's just easy to implement and use.
While I do not have the product, I would lead you to ask some more questions. Does it help you know where the messages are going to and thus discover the whole path of the message request / reply?
In a thought to be simple MQ / Broker system we were surprised to discover the number of interactions taking place with our WebSphere Apps using MQ to request data. We were using request/reply queues for real time requests / response and thus our online response time was impacted by the number of message and number of hops that a message was taking before a full response would be sent. We discovered that many MQ messages were creating a flood of MQ requests to other services one layer deep. This was discovered once we had use Network Traces and exploding the MQ header information to discover where the MQ Broker messages were going. This led to major changes in the backend systems to retire technical debt. We finally got to the rewrite of those older MQ bandaid systems because of insight gained.
Look for a tool that gives you the whole picture. We had to write our own tool, but surely they exist by now. That was 3 years ago and the concept was shared with a number of vendors asking for their help for development.
This tools monitors a major item, queue depth and this gives a good clue to a problem. You need to start somewhere.
The full information is carried in the network packet and in the MQ header. These values allow you to stitch the messages back together to understand the full flow of request/reply.
I would suggest checking out also Stackify, We are using it for DB and servers monitoring as well as overal app performance & error and logs management. You may want to talk to them as I think they are coming with some new relevant features
Price, simplicity, agentless, browser based, delegation of roles, support for SDLC, flexible, able to integrate with ServiceNow and HP OV