You can accomplish what you want without password logging. But it's also important to ask "why?" Why do these checks? What are you realistically going to do with this information? Can they be accomplished by passive means?
Check if it is just typo : if a user often failed login at first time with the same hashed password but later it logs in successfully, then it is possibly just a typo
Check if there is someone trying to guess password : Some common passwords, just like 123456 and birthday, which has fixed hash, if those attempts exists, the failed login may be done by password guessers.
Logging the account, timestamp, IP, and whether they succeeded is sufficient. You can deduce a lot from this information.
If you see a pattern of fail, fail, fail, pass in quick succession for the same account it was probably a typo. If you see a great many failures in a row and very quickly that's likely an attack on that account.
But a smart attacker will play the numbers game and distribute their attacks across multiple accounts. If the attacker has no information about your accounts, any given password guess is just as likely to work on any given account. If they have 100 passwords to try it doesn't matter if they try them all on 1 account or spread them across 100 accounts, the odds are the same.
Similarly they might use multiple IP addresses. If you see a group of nearly all failures from many accounts but a single IP that could be a distributed attack, or it could be a bunch of real users behind the same NAT or VPN. It's difficult to tell.
Realistically there's a much simpler way. These attacks are made more costly by rate limiting and soft lockouts. Guessing a password relies on being able to do a great many login attempts very quickly. Logins should already be rate limited by account, there's no reason a real user will attempt to login multiple times a second. Pick the highest rate limit you can that is still not noticeable by your users. This will foil rapid-fire automated login attempts. If there's persistent attempts anyway, automatically and exponentially increase the rate limit for that account (and possibly IP), reduce it once the alleged probes subside.
In addition, you can provide good feedback about password strength when users are creating their accounts to avoid easily guessed passwords.
In this way you can foil automated, rapid-fire probes while not annoying legitimate users who are just having a hard time typing today.
Check if a user have alternative account : some users may have alternative account but with different passwords, if a user usually failed to login with the same hash, and the hash is the same as another account but then login successfully, then it may be a user trying to login with an alternative account but forgot to switch password.
This seems more a business requirement than a security issue. You're essentially trying to detect the unique person behind an account, and that's quite difficult to get right: the internet very much does not want you to have that information. The cost to get it right is high, and as you get more and more users it's more and more likely to have a lot of false positives annoying your real users.
Unless that's your business, if you're a data mining company for example, consider why you have this requirement: what's its real effect on your system? What metrics do you have to back that up?
If you decide you really need to prevent alts, make use of various semi-unique real world IDs to add a cost to alt accounts and reduce their frequency. Email address is the most common. Making accounts cost money or requiring a credit card number is another. Even tax identification numbers if you're a big business site. It all depends on what you're doing.