I have never heard of the heartbeat until the heartbleed bug. I wonder what is the difference between this and a ping, and if there are other signals to manage the connection (also, which are not data packages).
Strictly speaking, ping refers to using an ICMP ECHO request to see if the destination computer is reachable. It tests the network, but not whether the target computer is able to usefully respond to any other particular service request (I've seen computers which were ping-able but which were functionally down; the OS kernel — which is what responds to pings — was up, but all user processes were dead).
However, the term has been extended to cover any sort of client-initiated check of whether the other end is up, often done inside the protocol of interest so that you can find out whether the target machine is able to do useful work.
With heartbeats, I've typically thought of them as being where the service regularly pushes the notification to somewhere else (as opposed to being prompted by a client). The idea is that the heartbeat monitor detects if it hasn't had a heartbeat signal for a while and applies “emergency CPR” (i.e., restarts the service) if that happens. It's similar to a watchdog timer in hardware.
I view a ping and a heartbeat as being complementary: one is for the client to learn whether the service is up, and the other is for the service provider to learn whether the service is up. (The provider could use a ping, and probably does via their Nagios setup, but a heartbeat monitors something slightly different — internal timers, in particular — and is pretty cheap to implement so there's no reason not to use one.)
Ironically, the Heartbleed bug was in what I'd consider to be a ping-ing mechanism. But it's called that because it's based on a (mis-)implementation of the SSL Heartbeat Extension. Terminology's all too often just there to be abused…