Discussion Feed

The database monitoring agent would provide much more granular details not only about server hardware usage but about that usage specific to individual databases, procedures, queries, and granular comparison data.   Server Visbility would not provide that without adding several Performance Counters and even then you would never truly know what queries were causing you the most resource usage pain without a lot of time comparing with your database analysis toolset.   Edit:  This is also something to consider from the standpoint of target audience.  If you have a group that is monitoring overall server health they may not care about the specific metrics by query.  In the event that you wanted to monitor overall server health the Server Visibility agent is better suited to present OS-critical metrics to evaluate health by.  In the event you are concerned with Root Cause regarding the execution and operation of SQL, then database monitoring is more aptly suited to your needs.   It is my opinion however, that there are specific needs for each agent so I would advise if the budget and hardware allows for you to implement both where you are able. ... View more

Sundar,   You can log into the administrator console and provide yourself a daily audit report, which you can define to include changes like these or at least in part to a somewhhat accountable degree.   To accomplish this, you can go to your controller's url and change the "/#/" in the routing to "/admin.jsp/" for example if oyur controller is at "https://123.456.789.1:8090/controller/#/etcetcetc"  you will replace the hashtag with "admin.jsp" as "https://123.456.789.1:8090/controller/admin.jsp" and that will take you to the root admin login.  You will be able to tell you're in the correct place because only the password will be requested at the login form, you are bound to "root" as user at this address.  Once logged in you will see all your controller configurations, at this point change "/admin.jsp/" to "main.jsp" and you will view your controller's AppD interface UI.   Go to "Dashboards and Reports" and you can configure a basic "controller audit" where "application changes" can be monitored as a standard event type.   This may not be EXACT, but it will let you know who logged in and made application changes and when.  If, in your event you're finding people are sabotaging your work, committing changes without accountability, or just making uninformed changes they will be logged "to some degree" by user and time frame at very least.   I have attached 2 images, one to show the url for admin.jsp as it is with ours and a second to show the criteria you would want to assign to your ROOT loign which will tell you when overall application configuratiosn have changed, when a bad config has been launched, or when someone is in general making unapproved changes.  This may not be EXACTLY what you want to a high level of detail, but it should take you 90% of the way and give you good grounds to create a formal structure of accountability when your "sub-admins" make unapproved changes you are then held responsible for. ... View more

Do you already have a Server Visibility agent or other agent running on this machine?  I found that with the server visibility agent running prior to the .NET agent I had to entirely disable the Machine Agent Service before attempting to connect to our controller in the .NET setup.  However, my error message appeared to be stating that there was a conflict in the "monitoring services" and to verify if there was a previously installed service for monitoring.     If that is not the problem, attempt to telnet using the following to verify you're allowed the network to network connectivity. (In CMD line on Windows) type "telnet CONTROLLERip CONTROLLERport" and if you cannot connect, you're dealing with a network issue.  The only reason I think perhaps this is a network issue or conflicting agents is that the config for 1 agent should work fine for the next if your network settings are identical.   Please also review what version the agent you've copied the configuration from is on.  If the agent that you are deploying is not on the same version you could be attempting to start your agent without hte necessary conifugrations and flags available and configured. ... View more