You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2014/11/07 23:04:05 UTC
mod_jk monitoring
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
I've been playing around with mod_jk's status screens a lot lately. I
also recently upgraded from Apache httpd 2.2 to Apache httpd 2.4 and
the hostname shown at the top of the page changed from the "real"
hostname to the masquerading hostname (more on that in a second) and I
was wondering what else was going on.
First off, I have a load-balancer with 3 web servers behind it. Each
individual web server has its own distinct hostname (the "real"
hostname) like foo.example.com, bar.example.com, etc. plus, when you
contact it through the load-balancer, it thinks it's "www.example.com"
of course.
Everything seems to work fine.
These days, the jk-status page always says "JK Status Manager for
www.example.com:443" when I visit the page, no matter which back-end
server I get by entering https://foo.example.com/jk-status. When I
connect to an individual server, I use HTTPS of course, so I get the
"_default_:443" virtual host which makes sense.
My conf/hostname.conf has "ServerName www.example.com" and no server
aliases, and my conf.d/ssl.conf has no ServerName and no ServerAlias.
(This is on Amazon Linux, which is essentially CentOS, and I'm using
package-managed versions of httpd so this is the layout they have).
I'm assuming that, since I have no ServerAlias for my :443
VirtualHost, that's where the name at the top of the page comes from.
Can anyone confirm that? It would be nice if the page advertised my
"real" hostname instead of the generic one. That is, I'd like to see
"JK Status Manager for foo.example.com:443" instead of
"www.example.com:443". Would adding a ServerAlias in either
hostname.conf (which I believe is loaded at the top-level
configuration) or in ssl.conf inside the VirtualHost achieve that?
Next, I have a question about the workers. I believe - but I'm not
sure - that each worker is unique to the server as a whole, and not to
just a single VirtualHost, right? That is, my jk_workers.properties
file contains a series of worker definitions and I can use them in any
VirtualHost I like. If I reference the same worker from two different
VirtualHosts, I just get two references to the same worker, right?
The reason I ask is that I don't have the jk-status page available for
users coming from the load-balancer. I want to make sure that when I
disable a worker when looking at the :443 jk-status page that I'm
disabling it across all VirtualHosts in the server.
(The load-balancer uses a different VirtualHost, and it's tough to
convince the load-balancer to pick a specific back-end server to
direct my commands to, so... it's kind of important that the above be
true.)
Can anyone confirm that the workers are shared? I think it would be
very difficult to administer if the workers were not shared, but I
wanted to be absolutely sure.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUXUHUAAoJEBzwKT+lPKRYC/oQAJ1XBBuGKbdqTbSPIt99/ZIa
vmj8m16TGQACuSeAcprBUXATJJ0yjgPpuE99gn8uTnwIs9D7nGIifWtCV2JC5x6Q
TZWFjqEHZpftoPuycvHg42DpnTEG53Pjxs3bdms+OLADOSZTFu3fKsbIuVwaraL8
/IHfBhanP/mgNXz5si/hVwDOb8zVcWCj2vGe/xIgQNJ6A7DFSU+MVMXxBFGmvdBh
qvoMsm8pBlZ9VDsHLwgRikoP0pyTfdXAR9EzEwS9pDaBn+CiffPC3vXY2unBxCj6
Nm5xoA5VPihJGbTw2VVpHSz9GOjq7rFdwqQEWCl1t2TbxfiyV5+Y0FUDHWGMwlhb
FUjdFw7zgr4xTSLdbrQTVsOUhsimgbqvycTQC3qOKL+Gd4HW0onct1a0qGfJfIKG
IW2KreY7ft6/RTM6AGahRUUPB/c45W3L04T4BY/FIIJA0rcmvq7ihli0ngCGinQM
/KoTRGOYj3geYWdwfpdZAOcCIIWyoo+qtUg1dNUN7nrfRMvINj51ETmvRYyLOamP
o1d5FcGpfP6rTU2llZOZ9qzgZgOj9ym7B1H+U6XUZfsL4rxwBFPL+s7nMUIex+vb
cU0dhs/3qmQrQ0ky6LdbdZcClGwwBlLIShGw4mWjw++GSG8ZSlueszUKKmbVTt7T
lRPeO88GuN11oJMmut7Y
=sRUk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk monitoring
Posted by Rainer Jung <ra...@kippdata.de>.
Am 07.11.2014 um 23:58 schrieb Christopher Schultz:
> Great. We've been having some problems draining Tomcat nodes, and I
> was concerned that maybe I had overlooked this one possibility. Our
> next release will include a version of the recently-discussed
> load-balancer draining filter/valve so we'll see how that does.
There are some tricks also in mod_jk to improve draining:
- people using an old session id without an existing session, e.g.
having a JSESSIONID cookie or who bookmarked a jsessionid-encoded URL,
will hinder draining. Typically clearing the cookie during logout
doesn't happen. So what you can do is twi things:
- you can use mod_headers to force cookie clearing on a logout URI by
setting the Set-Cookie header to an empty JSESSIONID cookie if the URI
matches your logout URI
- you can use mod_setenvif or mod_rewrite to set the Apache environment
variable JK_STICKY_IGNORE to "1" for requests that might have a session
id but can actually be handled non-sticky. E.g. a request for a login
form from a user that might use an old cookie. If mod_jk sees
JK_STICKY_IGNORE it will not handle the request sticky, so if you
already disabled some worker, the request will not be send there, even
if the cookie points to that worker.
Finally you can use the Tomcat Manager webapp "Expire Sessions" feature.
If you click it, it will not really expire sessions (actually only those
that the automatic expiration would expire during the next run), but it
will show a histogram of session idleness. Depending on the data you
might be able to decide, when enough draining happened, e.g. the
remaining sessions all or nearly all have a long idleness time (but of
course shorter than the session timeout).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk monitoring
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rainer,
On 11/7/14 5:44 PM, Rainer Jung wrote:
> Hi Chris,
>
> Am 07.11.2014 um 23:04 schrieb Christopher Schultz:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> All,
>>
>> I've been playing around with mod_jk's status screens a lot
>> lately. I also recently upgraded from Apache httpd 2.2 to Apache
>> httpd 2.4 and the hostname shown at the top of the page changed
>> from the "real" hostname to the masquerading hostname (more on
>> that in a second) and I was wondering what else was going on.
>>
>> First off, I have a load-balancer with 3 web servers behind it.
>> Each individual web server has its own distinct hostname (the
>> "real" hostname) like foo.example.com, bar.example.com, etc.
>> plus, when you contact it through the load-balancer, it thinks
>> it's "www.example.com" of course.
>>
>> Everything seems to work fine.
>>
>> These days, the jk-status page always says "JK Status Manager
>> for www.example.com:443" when I visit the page, no matter which
>> back-end server I get by entering
>> https://foo.example.com/jk-status. When I connect to an
>> individual server, I use HTTPS of course, so I get the
>> "_default_:443" virtual host which makes sense.
>>
>> My conf/hostname.conf has "ServerName www.example.com" and no
>> server aliases, and my conf.d/ssl.conf has no ServerName and no
>> ServerAlias. (This is on Amazon Linux, which is essentially
>> CentOS, and I'm using package-managed versions of httpd so this
>> is the layout they have).
>>
>> I'm assuming that, since I have no ServerAlias for my :443
>> VirtualHost, that's where the name at the top of the page comes
>> from. Can anyone confirm that? It would be nice if the page
>> advertised my "real" hostname instead of the generic one. That
>> is, I'd like to see "JK Status Manager for foo.example.com:443"
>> instead of "www.example.com:443". Would adding a ServerAlias in
>> either hostname.conf (which I believe is loaded at the top-level
>> configuration) or in ssl.conf inside the VirtualHost achieve
>> that?
>
> The name that is shown is the server name for the request being
> handled. This name is influenced by
>
> - the host header send by the client - the ServerName configured in
> the VirtualHost or global server actually serving the jk-status
> request - the UseCanonicalName setting
Ah, I had forgotten about UseCanonicalName. It is set to "On" so
everything is being set to www.example.com.
> For details see:
>
> http://httpd.apache.org/docs/2.4/en/mod/core.html#usecanonicalname
>
> A ServerAlias does not directly change that name. But if setting a
> ServerAlias in a VirtualHost that does not handle jk-status
> currently results in that VirtualHost handling your jk-status afer
> setting the Alias, it can also change the name shown in the page.
>
> First check what your UseCanonicalName setting is. If it is off,
> then mod_jk will simply show what is in the host header of your
> request - as long as your LB forwards the host header correctly.
> That would typically the best situation. Everything else quickly
> gets messy.
Agreed. I may disable UseCanonicalName for the direct-to-web-server
VirtualHost. Or, perhaps I'll do:
ServerName foo.example.com
ServerAlias www.example.com
UseCanonicalName Off
>> Next, I have a question about the workers. I believe - but I'm
>> not sure - that each worker is unique to the server as a whole,
>> and not to just a single VirtualHost, right? That is, my
>> jk_workers.properties file contains a series of worker
>> definitions and I can use them in any VirtualHost I like. If I
>> reference the same worker from two different VirtualHosts, I just
>> get two references to the same worker, right?
>>
>> The reason I ask is that I don't have the jk-status page
>> available for users coming from the load-balancer. I want to make
>> sure that when I disable a worker when looking at the :443
>> jk-status page that I'm disabling it across all VirtualHosts in
>> the server.
>>
>> (The load-balancer uses a different VirtualHost, and it's tough
>> to convince the load-balancer to pick a specific back-end server
>> to direct my commands to, so... it's kind of important that the
>> above be true.)
>>
>> Can anyone confirm that the workers are shared? I think it would
>> be very difficult to administer if the workers were not shared,
>> but I wanted to be absolutely sure.
>
> Yes, workers and their status are global (shared). Only Mounts are
> not.
Great. We've been having some problems draining Tomcat nodes, and I
was concerned that maybe I had overlooked this one possibility. Our
next release will include a version of the recently-discussed
load-balancer draining filter/valve so we'll see how that does.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUXU6oAAoJEBzwKT+lPKRYyFYQALYipZysSxOlYHrx0UYRFneW
r/169hi1JZ87ZF56LADktME82kJLQZJ1kpk0217YEBVg+8gNgCVHWiA5Xd2jGPnB
jOY+YBmytly4wzLB3zeiNW+dXoy2Nzb3br1ctnWcHPSOqaoWkwMTqcwPp1IPfPAY
XtFLPt7tWTJKRnEGyWaC0MWmVpNF51xDudtSENsetJAMLdyCSe/SXOksdD2/ERIh
0+sGI3vjubUKO/JkMQr93+q5e0ZhAPQu5sopoq6vfoMyghCA/16RQOwQBHNYFCAN
O77Tysk7HwsifIXckj9QFQukGV5kP+rVKU3m31Vw75b3fX7XyK2Gv5HW3uLLSYV8
iq5e0Fpf4ZmDgEZG+oRRkeEoC2MgdsGbGYy5ljW0bWZ2GyAV+9OzehZywwEyXITM
mOr4kn6qe7hko2NF4R1zA3TBdhhMxocI7mHGK/4e3z5Y03XU2uKYZkkNWbof5Vpi
CFH42YPPxkExsBuhTizAx4omh6rFYs5W1lcdyFzM9bfJ0mTE/i9IBOiZ0wTJjyp0
04F/CJFy9vgsNhu8RFD+CfgH2kpsCvlmLSNfiqRw4U/1nSpxfLIG95J06yJVPm0a
pGdaAjcV6AH1jCGFrABNH8ANg/4GODCyJNfHf43wlgcJmwyuyngdCOzcprxKFHCf
g4utrDTCOZHlI3qaBnBM
=5Ys2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk monitoring
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Chris,
Am 07.11.2014 um 23:04 schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> All,
>
> I've been playing around with mod_jk's status screens a lot lately. I
> also recently upgraded from Apache httpd 2.2 to Apache httpd 2.4 and
> the hostname shown at the top of the page changed from the "real"
> hostname to the masquerading hostname (more on that in a second) and I
> was wondering what else was going on.
>
> First off, I have a load-balancer with 3 web servers behind it. Each
> individual web server has its own distinct hostname (the "real"
> hostname) like foo.example.com, bar.example.com, etc. plus, when you
> contact it through the load-balancer, it thinks it's "www.example.com"
> of course.
>
> Everything seems to work fine.
>
> These days, the jk-status page always says "JK Status Manager for
> www.example.com:443" when I visit the page, no matter which back-end
> server I get by entering https://foo.example.com/jk-status. When I
> connect to an individual server, I use HTTPS of course, so I get the
> "_default_:443" virtual host which makes sense.
>
> My conf/hostname.conf has "ServerName www.example.com" and no server
> aliases, and my conf.d/ssl.conf has no ServerName and no ServerAlias.
> (This is on Amazon Linux, which is essentially CentOS, and I'm using
> package-managed versions of httpd so this is the layout they have).
>
> I'm assuming that, since I have no ServerAlias for my :443
> VirtualHost, that's where the name at the top of the page comes from.
> Can anyone confirm that? It would be nice if the page advertised my
> "real" hostname instead of the generic one. That is, I'd like to see
> "JK Status Manager for foo.example.com:443" instead of
> "www.example.com:443". Would adding a ServerAlias in either
> hostname.conf (which I believe is loaded at the top-level
> configuration) or in ssl.conf inside the VirtualHost achieve that?
The name that is shown is the server name for the request being handled.
This name is influenced by
- the host header send by the client
- the ServerName configured in the VirtualHost or global server actually
serving the jk-status request
- the UseCanonicalName setting
For details see:
http://httpd.apache.org/docs/2.4/en/mod/core.html#usecanonicalname
A ServerAlias does not directly change that name. But if setting a
ServerAlias in a VirtualHost that does not handle jk-status currently
results in that VirtualHost handling your jk-status afer setting the
Alias, it can also change the name shown in the page.
First check what your UseCanonicalName setting is. If it is off, then
mod_jk will simply show what is in the host header of your request - as
long as your LB forwards the host header correctly. That would typically
the best situation. Everything else quickly gets messy.
> Next, I have a question about the workers. I believe - but I'm not
> sure - that each worker is unique to the server as a whole, and not to
> just a single VirtualHost, right? That is, my jk_workers.properties
> file contains a series of worker definitions and I can use them in any
> VirtualHost I like. If I reference the same worker from two different
> VirtualHosts, I just get two references to the same worker, right?
>
> The reason I ask is that I don't have the jk-status page available for
> users coming from the load-balancer. I want to make sure that when I
> disable a worker when looking at the :443 jk-status page that I'm
> disabling it across all VirtualHosts in the server.
>
> (The load-balancer uses a different VirtualHost, and it's tough to
> convince the load-balancer to pick a specific back-end server to
> direct my commands to, so... it's kind of important that the above be
> true.)
>
> Can anyone confirm that the workers are shared? I think it would be
> very difficult to administer if the workers were not shared, but I
> wanted to be absolutely sure.
Yes, workers and their status are global (shared). Only Mounts are not.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org