Hello,
I'm trying to monitor in some way the HTTP status code of my websites, following the path from the domain to the final webserver. This allows me to easily find where the issue resides in an event of failure and I'm sure that the websites on the failover server work as expected in the event of the failover. Normally an easy task, but unfortunately not in that constellation...
The setup I want to monitor has the following structure:
The loadbalancer switches to server 2, only if server 1 is not working and to server 3, only if server 1 and server 2 are not working. Nearly all of the domains have a HTTP 302 redirect on the root that redirects automatically to the users language (like https://domain.tld redirects to https://domain.tld/en-us/), which is causing me the problem. The redirect changes sometimes, when web agencies make changes to websites.
I have set up multiple web scenario with one step each:
domain.tld - HTTPS --> web scenario, step 1
URL: https://domain.tld
Follow redirects: ON
--> Works
domain.tld - HTTPS on loadbalancer 1 --> web scenario, step 1
URL: https://192.168.1.2
Header: domain.tld
Follow redirects: ON
--> The redirect of the domain redirects Zabbix from https://192.168.1.2 to https://domain.tld/en-us/, but I would need https://192.168.1.2/en-us/
domain.tld - HTTPS on server 1 --> web scenario, step 1
URL: https://192.168.1.11
Header: domain.tld
Follow redirects: ON
--> The redirect of the domain redirects Zabbix from https://192.168.1.11 to https://domain.tld/en-us/, but I would need https://192.168.1.11/en-us/
domain.tld - HTTPS on server 2 --> web scenario, step 1
URL: https://192.168.1.12
Header: domain.tld
Follow redirects: ON
--> The redirect of the domain redirects Zabbix from https://192.168.1.12 to https://domain.tld/en-us/, but I would need https://192.168.1.12/en-us/
domain.tld - HTTPS on server 3 --> web scenario, step 1
URL: https://192.168.1.13
Header: domain.tld
Follow redirects: ON
--> The redirect of the domain redirects Zabbix from https://192.168.1.13 to https://domain.tld/en-us/, but I would need https://192.168.1.13/en-us/
A solution could be to monitor directly https://192.168.1.2/en-us/ for example, so no redirect happen, but I would prefer to know that everything works, if a user enters only the domain name in the browser. This would allow me for example to see, if there is a redirect loop. I would also need to edit the website check, if a web agency changes something. With over 100 websites this can be a challenging task. Therefore I would keep this option as last possible solution.
My question is now, how would you solve this? Isn't there really any possibility how the FQDN should resolve for a specific web scenario or even step?
Before I used Nagios, and there it worked without problems with this command:
I'm trying to monitor in some way the HTTP status code of my websites, following the path from the domain to the final webserver. This allows me to easily find where the issue resides in an event of failure and I'm sure that the websites on the failover server work as expected in the event of the failover. Normally an easy task, but unfortunately not in that constellation...
The setup I want to monitor has the following structure:
Code:
domain.tld - HTTPS
|- loadbalancer 1 - 192.168.1.2 - HTTPS
|- server 1- 192.168.1.11. - HTTPS
|- server 2 (failover 1) - 192.168.1.12 - HTTPS
|- server 3 (failover 2) - 192.168.1.13 - HTTPS
zabbix-server - 192.168.1.200 (same subnet as the other servers)
I have set up multiple web scenario with one step each:
domain.tld - HTTPS --> web scenario, step 1
URL: https://domain.tld
Follow redirects: ON
--> Works
domain.tld - HTTPS on loadbalancer 1 --> web scenario, step 1
URL: https://192.168.1.2
Header: domain.tld
Follow redirects: ON
--> The redirect of the domain redirects Zabbix from https://192.168.1.2 to https://domain.tld/en-us/, but I would need https://192.168.1.2/en-us/
domain.tld - HTTPS on server 1 --> web scenario, step 1
URL: https://192.168.1.11
Header: domain.tld
Follow redirects: ON
--> The redirect of the domain redirects Zabbix from https://192.168.1.11 to https://domain.tld/en-us/, but I would need https://192.168.1.11/en-us/
domain.tld - HTTPS on server 2 --> web scenario, step 1
URL: https://192.168.1.12
Header: domain.tld
Follow redirects: ON
--> The redirect of the domain redirects Zabbix from https://192.168.1.12 to https://domain.tld/en-us/, but I would need https://192.168.1.12/en-us/
domain.tld - HTTPS on server 3 --> web scenario, step 1
URL: https://192.168.1.13
Header: domain.tld
Follow redirects: ON
--> The redirect of the domain redirects Zabbix from https://192.168.1.13 to https://domain.tld/en-us/, but I would need https://192.168.1.13/en-us/
A solution could be to monitor directly https://192.168.1.2/en-us/ for example, so no redirect happen, but I would prefer to know that everything works, if a user enters only the domain name in the browser. This would allow me for example to see, if there is a redirect loop. I would also need to edit the website check, if a web agency changes something. With over 100 websites this can be a challenging task. Therefore I would keep this option as last possible solution.
My question is now, how would you solve this? Isn't there really any possibility how the FQDN should resolve for a specific web scenario or even step?
Before I used Nagios, and there it worked without problems with this command:
Code:
check_http -H domain.tld -I 192.168.1.2 -f sticky -S --sni
Notes:
-H, --hostname=ADDRESS
Host name argument for servers using host headers (virtual host)
Append a port to include it in the header (eg: example.com:5000)
-I, --IP-address=ADDRESS
-f, --onredirect=<ok|warning|critical|follow|sticky|stickyport>
How to handle redirected pages. sticky is like follow but stick to the
specified IP address. stickyport also ensures port stays the same.
-S, --ssl=VERSION[+]
Connect via SSL. Port defaults to 443. VERSION is optional, and prevents
auto-negotiation (2 = SSLv2, 3 = SSLv3, 1 = TLSv1, 1.1 = TLSv1.1,
1.2 = TLSv1.2). With a '+' suffix, newer versions are also accepted.
--sni
Enable SSL/TLS hostname extension support (SNI)