With the decision to step away from the old check_http and moving to a/the new Check HTTP web service plugin i am a bit disappointed as to the (detail-) output generated.
Do not get me wrong, i do welcome the extra options provided in this check, but when using the options the details output is unfortunately not reflecting what options were checked.
Comparing to the ‘old’ check i was given exactly what i expected as detail.
With the new check, where i primarily focus on HTTPS Certificate validity, that detail is no longer shown.
The check works (well i have not yet had a certificate expire as of yet, but will assume so).
But i would have really appreciated to see a/the certificate expiry back in the details as before.
This may seem to others as a trivial change, but to me it enabled me to see at first glance (pro-active) if certificates would pop up as warning in a/the monitoring.
I will assume that for other options (have not played with other options) the details are also not completely implemented.
So it would be my wish to see the level of detail brought back in the new check.
Because its not the only thing i want to monitor.
my wording might have been wrong in this … but i find certificates myself the most important.
This does not mean it is the only thing i monitor.
Thanks for the explanation. This is just my personal opinion, based on the experiences I made with website monitoring: I find it most effective to use the check_httpv2 AND the new check certificate check. By doing this I benefit from the features and strenghts of both checks. Furthermore, one problem I had in the past with having http and certificate checking combined in one service was what happened when I acknowledged an alert. Lets say your certificate expires in 30 days which generates a warning. You acknowledge the service because you planned to renew it next week, but then something else happens (e.g. website response time is too high, which usually also generates a warning). Now you either dont get notified at all, because the service is already acknowledged OR the acknowledgement expires (if the service gets crit and the ack is not sticky) and you have to set it again. By splitting it up into two services I dont have this problem anymore.
Regarding your statement that the old check displayed the certificate expiry date in the service output: Sure, because in the rule configuration you had to select “Check SSL certificate age” which is now basically equivilant with the new check_certificate, where the output is almost the same.
You say that you’re not only interested in the certificate age, but the old check_http with the mentioned option did exactly that and nothing more. So if you wanted to monitor the website and the certificate before version 2.3 you had to create two rules. The improvement with 2.3 and the check_httpv2 now is that you can do this all in one rule, but why should the date be shown in the service output? The main purpose of the check is not certificate monitoring. By this logic, the result of every configuration option needed to be shown in the output.
Like I said, just my opinion, maybe someone else can help you better.
Thanks for your sharing your opinion, i really appreciate it you took the time to write this.
And yes, your view upon things does make me think if i went the right way.
i will be moving towards splitting the check(s) where i can.
But still there is one situation i still might need the check http webservice.
And that is a federated (web-)resource.
In essence what happens is you ‘hit’ the resource, it will redirect to my Identity Provider because it requires authentication/authorisation.
So i was afraid that if i were to use the check certificate(my assumption), i will be testing the IDP certificate, and not the actual resource one.
With the Check Certificate i do not see a possibility to actually authenticate thru the IDP and get the actual resource information.
With the Check http webservice i can authenticate (if i dont i’ll get a HTTP 403)
I had hoped this check also provided the same detail as the old method/check.
Thats a good point, didn’t think about this kind of scenario.
What you could do as workaround is to create a seperate view where you only show the HTTP Services and add the column “Services: Details”.
I might be missing something here, but: A TLS certificate is relevant upon connecting to an endpoint. Redirects and authentication happen after that initial low-level connect. Now I do not know for a fact, that the new certificate check does not follow redirects, but you should be able to easily test this.
the purpose of the service summary is to only show the most important information. It is context-sensitive and will adapt it’s content based on the check evaluation, e.g. if something is critical, then the content is shown in the service summary. To ensure that the tables don’t get convoluted, we enforce again a more focused approach (vs. some years before, where no one looked in to detail into that). The tables are general purpose - if you have specific needs, you can adapt them to your needs as e.g. Janncek commented.
The certificate expiry is only shown, if there is an action required from your side, e.g. you set thresholds and they are crossed.
If you want to always see the certificate expiry, then I also recommend the specific CERT service, which is an improved replacement vs. the implicit CERT service from the old HTTP check.
Thank you for going into such detail in your post, together with the other participants in this thread who contributed i can move forward (better said change my way of how i was handling a/the checks)
