代码拉取完成，页面将自动刷新
简单 被动 心跳 服务
在项目中经常遇到需要上报数据的场景。出于安全原因，数据源一端只能将数据推到位于公网的互联网服务器上，而不能公开自己的端口。如此一来，也就无法通过主动监测来确认数据源一端的存活，而需要数据源一端定期发送心跳包来报告自己的状态。 出于集中管理的考虑，不同项目的心跳包其实可以由一个统一的心跳服务来接收和处理，诸如通知、统计等功能，也可以在一处完成。
此项目旨在建立一个具备基本的心跳包接收、判定、设备离线通知和统计功能的简单被动心跳服务
本项目由 node.js 开发，可以通过 npm 全局安装，通过 spbs 命令启动一个被动心跳服务
出于简单考虑，配置文件和心跳日志直接存放在用户目录下，不论在何处启动命令。
用来识别不同的心跳来源，并完成简单的验证
[
{
source: 'source1',
secret: 'secret1',
email: ['email1'], // 接收告警的邮箱，可填多个
threshold: 180, // 阈值，超过这个秒数未收到心跳认为客户端已离线
},
{
source: 'source1',
secret: 'secret1',
email: ['email1'],
threshold: 180,
},
]
每行一个应用名称加一个秘钥，客户端发送心跳包时，需要带有名称、时间戳和用秘钥参与获得的哈希值，名称用来识别是哪个应用发来的心跳，哈希值用来校验合法性
以具体应用名称为文件名的关于该应用的心跳记录
1598493392 1598493397
1598493402 1598493406
1598493446
时间戳记录，每行一对时间戳，第一个表示心跳开始，第二个表示心跳停止。服务器第一次接到心跳包时，新起一行，记录时间戳，中间心跳间隔小于阈值，不做记录，当连续无心跳超过阈值时，将上一次的时间戳作为心跳结束时间。此后再收到心跳时，开启一轮新的心跳记录。
设置服务的端口、通知离线的邮箱、心跳超时的阈值等
{
port: 7727,
smtp: {
host: 'smtp.example.com',
port: 587,
secure: false, // true for 465, false for other ports
auth: {
user: 'user@example.com',
pass: 'example password', // generated ethereal password
},
},
}
心跳服务自身也存在宕机的可能，甚至直接断电，没有预兆也没有机会进行任何退出前的操作，所以心跳服务宕机或异常退出时不会进行任何操作，并且下次启动时也不会对记录文件进行任何干预，也就是会出现下面这种情况
1598493392 1598493397
1598493402 1598493406
1598493446 # 此处出现了一次心跳服务的宕机
1598494055 1598494059
1598494065
统计时会忽略掉下一行的心跳开始时间，而认为这两行是连续的，如果你确定客户端在心跳服务宕机期间出现了宕机，可以手动将时间戳补到缺失的心跳停止位置。
默认情况下，心跳服务会比较客户端时间戳与本地时间戳之间的差异，对于超过阈值的情况进行丢弃，本次心跳无效，就和客户端没有发来这个心跳一样。但同时会返回时间戳之间的差值，客户端可以据此对后续心跳中的时间戳进行补偿，但在任何可能的情况下，建议同步服务器的时间。而只有在特殊的，不允许变动服务器时间设置的情况下，才考虑使用补偿机制。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。