Hi Larry and others,
Troubleshooting without the WUT in a Server Group environment is one of the use-cases the MonitorRemedy product is designed for. Managing load balanced server group environments can be a complicated and a time consuming process Typically, Remedy specialists have to trawl around multiple Mid-Tier and AR Servers in order to ascertain which server or servers are the problematic ones. Diagnosing issues involves logging in to each server and looking at resource usage and multiple logs files. A unique user search feature of MonitorRemedy allows you to identify which users are connected to which Mid-tier and AR Servers – allowing specialists to quickly home in on problematic Mid-tier or AR Servers. The MonitorRemedy product also provides a specialist graphical view of your application's health focused on your BMC Remedy AR System and Application installations. A graphical warning system lets you quickly identify which Application function, AR System, Mid-tier or Load Balancer components of your application are either down or trending towards a potential issue. Drill down features for example allow you to see: · If key application components are working (e.g. approvals, email) · Trends on resource usage , standard query and submit times. · Log files of all your servers · Real time ARSystem and Application licence usage. Setup time for monitoring tools can be time consuming. MonitorRemedy is a dynamic web application easily deployed to an Apache Tomcat server. The configuration interface allows you to define the additional applications to be monitored in minutes, allowing rapid product deployment. BMC Engage 2014 pricing applies until 17th November 2014 and is £5k GBP per environment monitored. You can learn more online at http://www.pws-europe.com/products/MonitorRemedy Thanks, Deepak Thohan cid:image001.gif@01C7FECB.9C4B3860 deepak.tho...@pws-europe.com _____ Telephone: +44 1784 497 047 | Mobile: +44 7875 009519 Fax: +44 1784 497 048 | Skype: deepak.thohan <http://www.pws-europe.com/products/MonitorRemedy> <http://www.pws-europe.com/products/ShareRemedy> <http://www.pws-europe.com/products/Workflow%20Studio> ShareRemedy | Leverage your investment in Remedy and SharePoint AnalyseRemedy | The unique Migration, Analysis and Maintenance Tool <http://www.pws-europe.com/products/MobileRemedy> MonitorRemedy | BMC Remedy Environment Monitoring Solution MobileRemedy | BMC Remedy On Your Mobile On Wed, Oct 22, 2014 at 5:17 PM, Larry Robinson <n...@ncsu.edu> wrote: ** Hi Folks, John Baker was kind enough to let me know that the script I posted had some potential security vulnerabilities. He provided the following alternative: <%@ page import="java.net.*" %> <html><head></head><body><p> <% String myhostname= null; try { myhostname= InetAddress.getLocalHost().getHostName(); } catch (UnknownHostException e) { } if (myhostname!=null) { %> This application server is running on hostname <%= myhostname %>. <% } %> </p></body></html> Works great. Thanks John! Larry On Thu, Oct 16, 2014 at 11:44 PM, Larry Robinson <n...@ncsu.edu> wrote: Hi William, I too receive problem reports from our Mid-tier users and struggled to determine which server they were connected to. I asked one of my JSP experts to write us a program that could run from the browser that would emit the name and IP of the Tomcat server that was serving the users session. We use LVS as our load balancer, which is IP based so once you are locked onto a server, you stay there. I put this JSP program in the Tomcat webapps/ROOT directory and ask the user to invoke it as: https://myservicename/server_id.jsp and have them tell me which server they are locked onto. Here is the code: server_id.jsp: <%@ page import="java.util.*,java.io.*" %> <% String cmd = "hostname"; String outstr = ""; try { Runtime rt = Runtime.getRuntime(); Process p = rt.exec(cmd); try { InputStreamReader ise = new InputStreamReader(p.getErrorStream()); BufferedReader bre = new BufferedReader(ise); InputStreamReader iso = new InputStreamReader(p.getInputStream()); BufferedReader bro = new BufferedReader(iso); String line=null; while ( (line = bre.readLine()) != null ) { outstr += line; } while ( (line = bro.readLine()) != null ) { outstr += line; } } catch (IOException ioe) { ioe.printStackTrace(); } int exitVal = p.waitFor(); } catch (Throwable t) { t.printStackTrace(); } %> <br> Hostname: <strong><%=outstr%></strong><br> Your IP: <strong><%=request.getRemoteAddr()%></strong><br> Service IP: <strong><%=request.getLocalAddr()%></strong><br> Hope this is helpful. Larry On Thu, Oct 16, 2014 at 1:02 PM, William Rentfrow <wrentf...@stratacominc.com> wrote: ** I sent this to our premiere support person and manager, but I'd be interested to see what others have to say about this too. Original message below: Hi – This came up on our call and I wanted to write it out. BMC has stated that the Windows User Tool (WUT) is going to be discontinued (in fact, it already was in 7.6x). What I need to know is what is BMC’s recommendation for diagnosing problems with the AR Servers in a server group? Currently our users will report an issue like this: “Remedy is slow/locked up/whatever”. Routinely we get no more information than this. Right now our troubleshooting is to first diagnose which server(s) is having problems. The fast way to do this is to login to every server with the user tool. We usually know within a few seconds if one of the AR servers is locked up, because we will not be able to log in to it. Then we can bounce it and get service restored. If they are responsive we then move on the Mid-tier servers, etc. With a large load-balanced environment there is no way to QUICKLY do this without the WUT. I could login with Developer Studio, but that doesn’t use the same threads on the server as the WUT does. We have seen instances where users are locked up and admins can log in with Dev studio (and vice versa). Same goes for migrator and the import tool. Support suggesting checking the AR Error log, but there are two problems with that – first, many lock-up scenarios do not results in errors in the arerror.log file. There are numerous other logs to check on every server as well (CMDB, Email, AIE, etc). Checking every log file on every server is time consuming and not 100% guaranteed to show us which server is locked up. The second problem with support’s suggestion is the sheer time it would take to login to each server. We are on Linux, so we need to connect via SSH using putty. We do that by first connecting to a gateway server. Then we ssh to the actual AR server (direct access is not allowed). Finally, we sudo to the user Remedy is running as. That means each time we connect it’s 3X we login. If we multiply that by the 10 servers in our server group it would take at least an hour just to triage the problem. I can do the same thing with the WUT in seconds. So here is the question: What is the proper way to QUICKLY triage which server is having problems without using the WUT or Dev Studio/Migrator/Import? William Rentfrow _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
