Monitoring static page

[olivierboniteau]

Our IT service uses a monitoring system, which needs a static jsp page. A HTTP 200 is expected.

By default, this page is considered as standard internal Jira page. Is it possible to avoid this ?

Is it possible to exclude this page in all cases, even a reindexing operation or a XML import ?

[parthiban subramaniam · Accepted solution]

Why dont you use http://yourserver.com/jira/secure/errors.jsp this does not require any login or anything and returns a http 200 and even during reindex or jira locked it does that.

there is nothing in jira that prevents you from hitting that url directly

if this fails to return anything than a http 200 your jira instance is in trouble

this way you dont have to exclude or include anything and does what you want

or is there a gotcha i'm not stupidly aware of?

[olivierboniteau]

The monitoring page is supposed to be very light, and is periodically requested. The errors.jsp page is heavier, with a favicon and images.

[parthiban subramaniam]

All attributes are cacheable, and i'm pretty sure your monitoring application will be able to cope and adhere to the header attributes.

the ones we used to use just ignored them

if all else is too much you can copy and strip out errors.jsp and use it :)

[JamieA]

The monitoring app is not a browser... it's not going to request the images or the fav icon.

[Mark Symons]

Some monitors are very light on traffic as they only retrieve HTTP headers. Some retrieve page content and then parse that. eg, "if regex on content matches xxxx then I can infer that all is OK with back-end database".

In the past I have created conditional monitors that would perform a simple low-impact check and then branch and perform additional checks if the initial response was not as expected. The intention being to avoid false alarms.

Having said that, I am a bit of a traditionalist. I would much rather have a couple of Atlassian MIBs and monitor using SNMP rather than HTTP.

[JamieA]

The errors.jsp is the best option imho. If you don't use it, and the index is corrupted or locked say, this will be reported on the errors.jsp, but your monitoring app will report everything is fine.

If the instance is out because of indexing, then this should be recorded as scheduled downtime in your monitoring app, rather than everything is fine and dandy.

[Dieter]

It's not quite clear yet to me what you need to monitor. if it's just a periodic alive check of the Tomcat server process you could also add just another context to server.xml which serves a minimalistic jsp.

[olivierboniteau]

"The monitoring app is not a browser... it's not going to request the images or the fav icon."

Our network administrators reported that we shouldn't publish images.


" if it's just a periodic alive check of the Tomcat server "

It is ! But I'm not allowed to create another context.


The development department creates and manages applications, and pushes Tomcat Webapps with a deployment app, based on SVN tags. I cannot configure the production server myself. All parameters are standardized by enterprise rules, that why I try to configure the Jira webapp.
1 webapp = 1 context = 1 DNS name = 1 tomcat server

[parthiban subramaniam]

IMHO you are too worried about all the extra attribues, as Jamie says most of these monitoring apps such as nagios or siteminder are clever and are more then capable of handling these scenarios and work very similar to http://linux.about.com/library/cmd/blcmdl1_lwp-request.htm

an example of this would be

on JIRA context

lwp-request -s -d http://localhost:8080/jira
200 OK

On JIRA but to a page

lwp-request -s -d http://localhost:8080/jira/secure/errors.jsp
200 OK

try this for yourself and see

cheers

[JamieA]

Ah I see what you mean.

[olivierboniteau]

During reindex, any JSP request is redirected to errors.jsp. I want to exclude some pages.

If the monitoring JSP is not available, our monitoring system consider the Tomcat server unavailable, then shuts every HTTP request to 104 "Connection reset by peer".

Consequence : if a Jira administrator performs a reindex or a troubleshooting research, he will get a HTTP 104.

[JamieA]

What do you mean by redirect during reindex? The reindex has no knowledge of any JSP pages.

By default, this page is considered as standard internal Jira page. Is it possible to avoid this ?

Can you explain what you mean by this?

[olivierboniteau]

It is possible to exclude this page with the decorators, the JSP page will have the expected HTML content. There is still a redirect to "errors.jsp" during a reindex operation.

decorators.xml :
<decorator name="none">
<url-pattern>/monitoring.jsp</url-pattern>


monitoring.jsp :
<HEAD>
<meta name="decorator" content="none">