Configure logging and debugging
This topic has not yet been written. The content below is from the topic description.
There are three main log files you will interact with when debugging any issues that arise. These files are as follow: 1. Apache Access Log – this log shows all requests coming in to the web server. This is naturally the first log to look at. Here you will verify that the request is actually coming into the web server. This file is typically located at /logs/access.log but each Virtual Host can create its own access log. Because of that, it is best to get the location from the configuration of the domain you are debugging. Illustration 28: Sample Apache access log 2. Apache Error Log – this log shows all errors that the web server is encountering. Errors typically are for artifacts (images, stylesheets, html pages) that could not be found. You will see other errors in here though if the web server is running low on resources which could be a sign of long-running threads or requests. Finally, you will also see more verbose debugging information here; for example information around ajp connections. This file is typically located at /logs/error.log but each Virtual Host can create its own access log. Because of that, it is best to get the location from the configuration of the domain you are debugging. Illustration 29: Sample Apache error log file 3. Mod_jk / mod_cluster / mod_proxy.log – This log file will show all of the requests and responses over the connectors to JBoss including keepalive information or cluster information in the case of mod_cluster. Look in this log to verify that requests are being sent to JBoss appropriately as well as to troubleshoot the expected translation and response from JBoss. This file is typically located at /logs/mod_connector.log but each Virtual Host can create its own access log. Because of that, it is best to get the location from the configuration of the domain you are debugging. Inside the httpd.config file, you can set the logging level of Apache using the LogLevel directive. The examples above are with LogLevel set to Debug to show more verbose samples. Illustration 30: LogLevel definition inside httpd.conf The format of your log files is configurable. For the sake of this whitepaper, we will stick with the default logging configuration, but more information can be found here - http://httpd.apache.org/docs/current/logs.html Finally, be sure to rotate your log files. As log file growth is directly dependent upon LogLevel as well as site requests, be sure to tune your scenario accordingly. In general, you always want to avoid log files getting to large. Most organizations are fine with a nightly log rotation and that is what the below example will cover (just note that your needs may vary). The easiest way to set up nightly log rotation is to use the rotatelogs script that comes with Apache (located at EWS_HOME/sbin/rotatelogs. To rotate our access log after 24 hours, we would add the following line: CustomLog "|sbin/rotatelogs /var/local/httpd/logs/access.log 86400" common There are a few items above that are of interest. Lets look at them individually CustomLog - We are using the CustomLog directive to set up a custom logging structure. At the end of this line, we can see the ‘common’ parameter. This is telling CustomLog to use the common logging format and apply that to our CustomLog. |(Pipe Character) - We start off the CustomLog by entering the pipe character. This tells apache to use piped logging. This way Apache does not keep a filehandle lock on the log file. If we didn’t use piped logging, we could still rotate the files, but we would need to stop apache to release the lock before we could rotate. sbin/rotatelogs - This is the relative path to the rotatelogs executable /var/local/httpd/logs/access.log - This is the path to the log file we want to rotate. Note that for each log you want to rotate, you will want to add a CustomLog. 86400- This is the number of seconds, offset from webserver start, when the log should be rotated. This could also be defined in filesize, i.e. 5M to rotate after 5Mb of logging. common - Finally, we define that this log should use the common definition for log message formats. Again, the above information shows the best approach for setting up log rotation. In the example above, we are rotating the access log file every 24 hours. 4.7 Connecting to JBoss There are three main ways to connecting Apache HTTPD to JBoss EAP. 1) Using mod_proxy – mod_proxy acts like just that – a proxy to your application server. With mod_proxy, you simply tell apache that for certain request patterns, the request will be responded to by the application server. mod_proxy can act as a regular forward proxy or as a reverse proxy. Mod_proxy is simple to configure, supports SSL, but lacks a considerable amount of control that you will get with mod_jk and mod_cluster around how you will forward requests as well as information around application server availability. 2) Using mod_jk – mod_jk is the jakarta connector from Apache. Development on it has slowed down recently. Mod_jk is nicer than mod_proxy as it allows a tighter integration with the application server as well as a small communication channel (leveraging AJP) and more fine-grained control of how requests are forwarded (i.e. mod_proxy forwards based on URLs, so typically a whole directory would be proxied. With mod_jk, you could say for a given directory with a given extension type, forward those requests. This works well with virtual includes). However, mod_jk does require a slightly more involved configuration and does not support an encrypted communication channel between web server and application server. 3) Using mod_cluster – mod_cluster is the next generation connector from JBoss. Like the others, it serves to be the bridge between web server and application server. Like mod_proxy, it can work with an encrypted channel and has a simple configuration. Like mod_jk, mod_cluster also allows fine-grained control of requests and configuration parameters. Unlike mod_jk and mod_proxy, mod_cluster allows an application server to grow / shrink dynamically without needs for reconfiguration. Additionally, mod_cluster leverages a second communication channel which allows it to have more robust load balancing options as well as being more than just application server aware – it is also application aware meaning that it can detect scenarios where an application server is up but an application is not available and thereby not route traffic to it. Now that we have provided a background on the 3 ways to connect Apache HTTPD to JBoss EAP, we will go through an exercise configuring these connectors. In each example, we will do the following: 1) Send requests to websiteDomain/theboss to the admin-console of a cluster of JBoss EAP instances 2) We will configure these to communicate using AJP – a performant, binary format used for communication between a web server and an application server 3) We will configure it such that the second instance will get 3 times the traffic as the first 4) Finally, we will configure our connector to use sticky session. This way once a user has established session on one application server instance, they will continue to go to that one as opposed to being load balanced between the two. This is ideal for a situation such as this where we are logging into an administration console. Setting up mod_proxy All of the changes in this example will be made to the httpd.conf file located at EWS_HOME/conf. mod_proxy is dependent upon the following modules, so be sure to have them loaded: mod_proxy mod_proxy_balancer mod_proxy_ajp / http / ftp (depending on your connecting protocol) Because we only want this forwarding applied to one domain, we will put these directives inside the VirtualHost definition. If we wanted the proxy applied globally, these directives can stand alone in the configuration file. ... ##Identify the proxy ##Setup the members for this proxy. 2 members, using ajp protocol (could also ##use http. ‘loadfactor’ tells the balancer that the second instance should get ##3 times the load of the first. ##Use ProxySet to establish sticky session ##ProxyPass defines the URL pattern to match to the balancer BalancerMember ajp://127.0.0.1:8009 loadfactor=1 BalancerMember ajp://127.0.0.1:8109 loadfactor=3 ProxySet stickysession=JSESSIONID ProxyPass / balancer://jbossCluster ProxyPassReverse / balancer://jbossCluster ... Here is what we see in a browser (note running over port 80) Illustration 31: Accessing JBoss through HTTPD front-end proxy, note the browser is accessing site over port 80 We could continue using the application as normal, all over port 80. If you want to see the AJP communication, set your LogLevel to Debug and view the error log file: Illustration 32: Log files for information showing AJP connectivity