I'm new to SolarWinds and trying to find my way around, trying to figure our whether SAM or some other SolarWinds tools can cover my needs of monitoring and administration. I have a Java app running with different settings on several linux machines.
1) monitoring availability of machines and apps
that's an easy one ... yes
2) starting/stopping the apps from the SAM interface
I've seen it's possible to run linux scripts remotely through ssh. Can this be done manually without a schedule?
3) present and control internal application data
As it's a Java app I first looked at Jmx and MBeans. Created some beans to encapsulate internal data ( number of clients, messages/client, etc... ) I want to monitor and control and was able to set/get it with jconsole.
Then realized SAM only supports monitoring of numeric types.
Is there an alternative solution to monitor Strings?
Is there an alternative solution to be able to set numeric/string data in a Java app, to dynamically configure the application through SAM?
In SAM is it easy or at all possible to present application data like : number of active clients, a list(variable length) of names/number of messages of active clients
4) my app is also generating log files,fast growing at times. Is it possible to stream these logs to SAM and present it to the user?
5) deploying the application and patches
SolarWinds Patch Manager only supports windows right? Is there an alternative for linux or any plans to support linux in the near future?
Possibly some of the requirements are out of the scope of SAM. In that case are the other SolarWinds tools to help cover them?
Technically, you can probably do much of what you want with SAM on Linux using scripts. Some of it could get pretty involved though and I really don't think its what SAM was designed to do. I'll let others/staffers comment on the ability for other SW products to meet some of your needs and focus strictly on using SAM itself.
1) Seems you've already answered that question for yourself.
2) You can either have what I refer to as a "Test Only" component which is a Custom Script component that is not actively monitored, but you can use the Edit Application screen to run the script --or-- you could use the alert trigger/reset actions to run a script. The first option is a bit of a hackish workaround that we engineered to reduce the need to lookup the passwords from servers every time our triage team needs to login to a server to run something like 'top'.
3) Any data that you are able to pull using perl or bash can be retrieved. You would likely want a custom script that uses the "Message:" field to return the string values and the "Statistic:" field could either always return a specific number or you could use the script to programatically return a statistical value based on the string data. I don't have much experience with JMX myself, but I believe there are some JMX templates floating around that could point you in the right direction.
4) I'm not sure if you could get a real-time stream in place; however, I do see a few possibilities. Both would involve sending the log file information to the SW Server and using a custom HTML resource to display the last x lines of the log file. This would require some HTML coding to pull the data.
4a) Setup a script on the linux server to send the script to the SW Server. Obviously you'd want to have the file go into the IIS folders somewhere (I'm no web programmer, so you're on your own for figuring out where ).
4b) Have a script monitor that triggers the log transfer. I'd personally prefer this method. You could tie this in to a regex that searches for keywords that indicate a problem.
5) Technically, you could probably do this. As long as you have the install process automated you should be able to use one of the previously mentioned "test only" monitors to deploy the software. I've considered doing stuff like this myself, but mostly just as a fun exercise. I'm sure there are better solution available for automating an installation.
You can do a whole lot of stuff with custom scripts in SAM. The primary things to remember are the returns that you use. Exit(0) will show the component as up, Exit(1) will show the component as down. Statistic field is always required, but you can force it to always return the same value and use the Message field combined with Exit codes to monitor things that don't lend themselves to numeric values.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.