Support #238
closed
The nagios check 'gcube search' goes often in critical state
Added by Andrea Dell'Amico almost 10 years ago.
Updated almost 10 years ago.
Category:
System Application
Infrastructure:
Production
Description
The "Gcube search" nagios check on portal.i-marine.d4science.org is often in critical state. The script source code is:
FILE_TMP=/tmp/xml-aquamaps
# wget http://$1/images/report/xml -O $FILE_TMP > /dev/null 2>&1 # service.d4science.org
"http://portal.i-marine.d4science.org/aslHttpInformationRetrieval/GenericSearch?responseType=xml&searchTerms="tuna"&allFields=false&count=1” -O $FILE_TMP > /dev/null 2>&1
nimages=`xmllint --xpath '//speciesCount/text()' $FILE_TMP`
rm $FILE_TMP
if [ "$nimages" -gt "0" ]
then
echo "Images cached : $nimages"
exit $STATE_OK
else
echo "0 Images cached!"
exit $STATE_CRITICAL
fi
There was a proposal to dismiss the discovery service, but it still active. If the service cannot be dismissed, a fix is needed.
Files
I think this check is messy, it seems mixing the check on the Images Servlet serving the iOS and Android app AppliFish (in the first part) and the gCube Search where you indicate the URL portal,i-marine....
I'll try to explain in the following:
hope this helps
- Assignee changed from Massimiliano Assante to Andrea Dell'Amico
If my Analysis is right you may need to correct the Nagios check
Sorry, I just noted that the formatting lost a part of the script. The line
wget http://$1/images/report/xml -O $FILE_TMP > /dev/null 2>&1
is only used on the check dedicated to service.d4science.org.
The i-marine check uses the second URL only.
I attach the two scripts to clarify.
It's working correctly since the start of the month, but it flipped a lot in May.
When if fails it's always because the request times out, and the actual timeout is 240 seconds.
then the ticket can be closed for me.
- Status changed from New to Rejected
Also available in: Atom
PDF