'tmsh config sys load' causes monitors (healthchecks) to fail

To clarify, you were running http monitors without a send string? It sounds like you should be running the TCP 3WHS monitor instead, which does not have a default send string.

It may be worth opening a case to see if the http send strings being reset if blank is expected behaviour or a bug.

Additionally, it is usually not recommended to directly edit the bigip.conf.

Opened a support case. Additionally, not recommended and not allowed are two different things but I get what you are saying.

Another good practice to get into the habit of is verifying your configuration before running a load, if you do indeed need to edit the bigip.conf manually.

tmsh load sys config verify
( if good, then, )
tmsh load sys config

This should help prevent a misconfiguration from disabling a box, and give you more of a chance to correct it.

Thank you for the best practice information but that's not what the question was about. While it may not be recommended to directly edit the bigip.conf file, there is no other way in 11.4 to change the name of an object (pool, virtual server, etc). This was the reason we modified the file, based on the advice of F5.

Also, the verify command was run beforehand and it did not catch this use-case. We've brought this to F5's attention and it has been confirmed that this is a bug. When you delete the send string in an HTTP check the F5 config does not have an entry that simply says "", it just removes the line entirely. That's how the default "GET /" check gets loads on a tmsh load, as the F5 assumes that the check uses the send string of the parent profile (HTTP in this case) if none is specified.

Should we be using the HTTP check without a send string? Definitely not, it was done because the generic send string does not send HTTP version headers and that caused an issue with our Tomcat and Nodejs servers. We've since found a correct send string but the old ones had not been changed. However, at the end of the day F5 config allowed us to not specify a send string and it shouldn't have overwritten our empty string with the default on a tmsh load. We appreciate the best practice advice however the question was "Why would loading the config modify all of these health checks?" and it's a bit frustrating when we mostly just get best practice tips.

Not directly answering your question, I would like to provide some information instead. The default send-string uses the HTTP v0.9 syntax and that's why there is no version information specified.

I can imagine the situation in which a system uses the default value when no customisation is specified.

And an HTTP monitor without a send string is something new and interesting to me, for I had thought I could not rely on something like this myself.

Thanks for sharing the info that this has been confirmed as a bug and I sympathise with your unexpected plight, which I would never wish myself into.

My understanding is also that a system will use default values when no customization is specified. However, the documentation specifies that the parent monitor is only used to configure the initial values for the monitor.