首先解释一下云端判定心跳超时逻辑：
每个连接都维持着一个最近活跃时间，任何mqtt上行报文都会刷新这个最近活跃时间。云端如果检测到一个连接的最近活跃时间与当前时间的差值，大于1.5倍的心跳时间，就会判定这个连接心跳超时，从而将这个设备踢下线。
举个例子，设备端连接时设置的心跳时间是60秒，那么设备端应用如果60秒被没有发业务报文，设备端sdk就应该自动发送一个ping报文。而对于云端来说，如果90秒内没有收到设备端的任何报文，就会将设备踢下线。
备注：目前云端的实际实现逻辑，是每隔30秒去检查下当前机器上的所有连接，所以实际的时间还会加上0~30秒。对于上面的例子，目前实际会经过90~120秒后将设备踢下线。
1.首先找到IoT控制台日志服务，业务类型里面筛选出【设备行为】
2.然后找到具体的offline日志，内容里面找到offline reason
3.常见的offline reason排查：
1.TCP长连接断开，解决：检查设备端网络，本身设备端做好重连机制：MqttConnectOptionsc.setAutomaticReconnect(true)
2.Keepalive timeout after 100sec，心跳超时，解决：MQTT连接心跳时间为30秒至1,200秒。心跳时间不在此区间内，服务器将会拒绝连接。建议取值300秒以上。如果设备端网络较差，值相对可以设置的大一些。【这里设置心跳时间的参数具体要看使用的什么sdk，比如c sdk，在 IOT_MQTT_Construct 的入参中可以设置 keepalive_interval_ms 的值, C-SDK用这个值作为心跳间隔时间，keepalive_interval_ms 的取值范围是 60000 - 300000, 即最短心跳间隔为1分钟, 最长心跳间隔为5分钟】
java sdk见附件截图
3.Kicked by the same device，设备互踢，两种情况
①.设备和物联网平台的连接是基于mqtt协议的，假设设置的心跳时间是300s，那么只有超过心跳时间后，平台还没有收到设备端发送的心跳包，才认为设备离线。
如果在300s内，网络恢复，您的设备重新上线（也就是说设备本来离线，平台这边还是认为在线的，因为没有到300s），那平台就认为被同一台设备挤下线了，所以显示kicked by the same device
②.同一组三元组信息两个或以上设备同一时间连接，这个连接被踢掉了。
4.Connection reset by peer，这个是TCP连接被对端重置，您那边是设备端有持续重复连接的情况或者因为设备端网络不稳定导致的重连。
5.device disconnect这个一般是云端收到设备端disconnect报文的同时，设备端主动断开了tcp连接，并发导致的。
