You ask, we listen. Many of the top features being worked on in SAM are generated through your feedback, your participation in our user sessions and your votes in our feature requests forum. API Poller Management - Key CRUD functionality enabled across one or more API pollers. Advanced API Poller - monitor strings, and chain requests together for more advanced use cases. Allow any response field to be monitored in the API poller More flexible REST monitor REST based monitor - string checking Scale improvements for monitoring Active Directory - Increase the number of domain controllers that can be mo nitored. Latest Release The latest release of Server & Application Monitor (SAM) is available on solarwinds.com and in your customer portal . See the release notes for a comprehensive look at the features contained within. >> SAM 20 20 . 2 Release Notes Give Us Feedback We actively refine the product roadmap to solve your problems. Participate in user sessions for THWACK points and personalized input into the future of SAM.

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.

What We're Working On For Server & Application Monitor (Updated August 3, 2020)

solarwinds_worldwide_llc over 8 years ago

You ask, we listen. Many of the top features being worked on in SAM are generated through your feedback, your participation in our user sessions and your votes in our feature requests forum.

API Poller Management - Key CRUD functionality enabled across one or more API pollers.

Advanced API Poller - monitor strings, and chain requests together for more advanced use cases.

Scale improvements for monitoring Active Directory - Increase the number of domain controllers that can be monitored.

Latest Release

The latest release of Server & Application Monitor (SAM) is available on solarwinds.com and in your customer portal. See the release notes for a comprehensive look at the features contained within. >> SAM 2020.2 Release Notes

Give Us Feedback

We actively refine the product roadmap to solve your problems. Participate in user sessions for THWACK points and personalized input into the future of SAM.

Top Replies

Parents

0 nick0909 over 4 years ago

Some things off the top of my head I know we have needed for API monitoring (REST or whatever):
Save the results of an error. Right now the HTTP check can kind of do the check, but the error comes back in the result, we can search for it (contains the string "ERROR") using that HTTP check, but all we get is a "DOWN" notice. If the error clears we never know what that return was. If that return could be included in the error somehow that would be a lot of help.
The ability to parse the return. It might be JSON or XML, at least regex, let me slice and dice it to get the information out of it that I need. Extending on the above request, if there is a <STATUS>Everything is broken because of Bill</Status> line, let me pull that out and make it part of the alert.
And continuing to extend from above, let one part of a return be used in the next step of a check. I might have to request what queues exist, and then want to check the error value on all those queue names that came from the first step. So 1 initial request might create a dynamic request for another 100 items. Right now this is basically impossible. Zabbix does this somewhat with its discovery tasks.
Edit - one more thought, authentication for the endpoint. Some of our APIs require it depending on what they provide.
Cancel
Vote Up +1 Vote Down

Cancel

Reply

0 nick0909 over 4 years ago

Some things off the top of my head I know we have needed for API monitoring (REST or whatever):
Save the results of an error. Right now the HTTP check can kind of do the check, but the error comes back in the result, we can search for it (contains the string "ERROR") using that HTTP check, but all we get is a "DOWN" notice. If the error clears we never know what that return was. If that return could be included in the error somehow that would be a lot of help.
The ability to parse the return. It might be JSON or XML, at least regex, let me slice and dice it to get the information out of it that I need. Extending on the above request, if there is a <STATUS>Everything is broken because of Bill</Status> line, let me pull that out and make it part of the alert.
And continuing to extend from above, let one part of a return be used in the next step of a check. I might have to request what queues exist, and then want to check the error value on all those queue names that came from the first step. So 1 initial request might create a dynamic request for another 100 items. Right now this is basically impossible. Zabbix does this somewhat with its discovery tasks.
Edit - one more thought, authentication for the endpoint. Some of our APIs require it depending on what they provide.
Cancel
Vote Up +1 Vote Down

Cancel

Children

No Data