Is it safe to use fast/small hash for key identity? I have to roll database access keys often, but it's important to know which key each system is using in order to avoid unavailability. I want the systems to report that without exposing the key itself, of course.

I'm using randomly-generated 512-bit keys, and from each key I'm planning to make a 32-bit hash. I only need to compare a handful of keys each time, so it's ok to have $1 - \frac{1}{2^{32}}$ of comparison confidence (which gives more than 99.99999%).

If the attacker sees the hash and knows the key size, he/she can filter out keys that produce a different hash. However, he/she will still have $2^{480}$ keys to brute-force access the database.

Does that make sense or is there a better solution? If this will work, which hash function should I use for the 32-bit hash? CRC/Checksum/something else?
In general, you never want to use CRC/weak checksum for any computations on secret material (like keys). CRC is a linear function and by showing CRC of a key, you reveal a lot of equations that hold among the key bits. This is equivalent to showing the same number of bits of the key as the length of the checksum.

The proper way of doing it has been suggested by @puzzlepalace: Take a cryptographic hash function (like SHA-2), compute the hash of the key and take only 32-bits of the digest.

Key fingerprint of 32-bits may be too small: if you have ~2^16 keys, you will get different keys that give the same fingerprint. You need to take this into account when designing your system.