Kerberos authentication not working after IIS/SharePoint rebuild.

The static SPN pattern just short circuits the regular reverse DNS lookup process. SharePoint (and IIS) control individual websites with application pools. These are thread and resource management entities, but they also control the identity under which a given service functions. Out of the box and IIS service will run as ApplicationPoolIdentity, which is a service owned by the local machine, therefore the SPN for that service would naturally be http/[local server machine name]. That's why it makes sense to do the reverse DNS lookup with APM. Assuming this is how the server's are configured, the returned PTR record will be the server's machine name, which would be the same as the SPN. But there are definitely times when you don't want to do it this way. Most SharePoint articles recommend creating a separate AD account and making that the owner of the frontend services. So you create that account and then you create an arbitrary servicePrincipalName attribute for that account. And then you can assign that same account as the owner of SharePoint on all of the servers, and you have an entire farm under a single SPN. That's specifically why you'd use the SPN Pattern option in the APM Kerberos SSO profile - to indicate that arbitrary SPN that will be used by all of the servers. What I'm guessing has happened is that you rebuilt the SharePoint servers but did not assign a separate AD account to own the frontend services. The fact that it works without the SPN Pattern now implies that the SPNs are all now machine-based and unique per server.

As for logging, that's a good question. You get the "S4U ===> OK!" message in the APM log because APM was still able to get a ticket for that old SPN. And since APM sent a ticket and SharePoint rejected it, the fault lies almost entirely in the SharePoint config. Had you captured the Kerberos traffic between APM and the KDC with WireShark, you would have seen the requested (incorrect) SPN in APM's request.