Forum Discussion
NimbostratusLTM Health monitors logs
Hello, can someone please explain me logs of failed LTM monitors on pool members ? Trying to figure out why the monitor failed for a certain pool member and this is what I see in logs
/Common/TDF-WEB-12:443 monitor status down. [ /Common/my_domain.com: down; last error: /Common/https_my_domain.com: Response Code: 200 (OK) @2019/08/06 01:02:57. ] [ was up for 2hrs:51mins:25sec ]
root@(TDF-F5-01)(cfg-sync In Sync)(Active)(/Common)(tmos)# show ltm monitor https https_my.domain.com
-----------------------------------------------
LTM::Monitor /Common/https_my.domain.com
-----------------------------------------------
Destination: 10.112.11.200:443
State time: up for 0hr:37mins:30sec
| Last error: Response Code: 200 (OK) @2019.08.06 01:20:09
Destination: 10.112.11.210:443
State time: up for 0hr:37mins:40sec
| Last error: Response Code: 200 (OK) @2019.08.06 01:19:59
And here is configuration of the health monitor:
ltm monitor https https_my.domain.com {
adaptive disabled
cipherlist DEFAULT
compatibility enabled
defaults-from https
destination *:*
interval 5
ip-dscp 0
recv "^HTTP.1.1\s(200|301|302)"
recv-disable none
send "GET / HTTP/1.1\r\nHost:my.domain.com \r\n\r\n"
ssl-profile /Common/serverssl
time-until-up 0
timeout 31
}
So 200 OK response code should be okay based on the monitor and is what I get when everything is okay. This happens very intermittently, and based on the logs I am not really able to tell what is wrong. Anyone have any tips why the logs shows what I see ?
Thanks
Can you use curl to check?
curl -v https://my.domain.com -X HEADI think, you should use this receive string.
HTTP/1.1\s(200|301|302)
xMadiHello
Isn't the dot suppose to represent "anything" ? Or why do you suggest to use "/"
Anyway, this is the curl return.
[root@TDF-F5-01:Active:In Sync] config # curl -v -k -H "Host:my.domain.com" https://10.112.11.210 -X HEAD
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
* Rebuilt URL to: https://10.112.11.210/
* Trying 10.112.11.210...
* Connected to 10.112.11.210 (10.112.11.210) port 443 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
* subject: OU=Domain Control Validated; CN=*.my.domain.com
* start date: Dec 1 03:13:00 2017 GMT
* expire date: Dec 1 03:13:00 2020 GMT
* issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
* SSL certificate verify ok.
> HEAD / HTTP/1.1
> Host:my.domain.com
> User-Agent: curl/7.47.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 06 Aug 2019 09:13:22 GMT
< Server: Apache
< X-Powered-By: PHP/5.6.40
< X-Trace: 2B13BF2E0DFB6C447D0D6ED4EB2C221169A173BED6826D2E26839F88D301
< Set-Cookie: d6992861f82e516ee763eb7c634a4ee3=m2vofhgariqjv27am48rt2kmu2; path=/; HttpOnly
< Expires: Mon, 1 Jan 2001 00:00:00 GMT
< Last-Modified: Tue, 06 Aug 2019 09:13:22 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Vary: Accept-Encoding
< Connection: close
< Content-Type: text/html; charset=utf-8
<
* TLSv1.2 (IN), TLS alert, Client hello (1):
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
MaryVIs http the only monitor you have for those pool members?
If so can you also configure an ICMP monitor and see whether when this is happening icmp also fails?
If icmp fails at the same time you are probably looking from some connectivity issue. Check MAC/ARP tables, interface flaps and so on.
If only the HTTP monitor fails then your best shot is to capture traffic on the LTM while the problem is ongoing and see what the response from the server is.
PSritaCAltostratus
Hello
Were you able to resolve this? I am seeing a similar issue for one of our applications.
Thanks!
