基于FTP协议实现指定终端的日志自动上送方案

日志是应用程序的镜子，重要性不言而喻。日志是排查问题的一种有效的和快速的途径。

以往现场出了问题，都需要外办的到处跑，去采集设备日志，再提供给研发分析处理。

且采日志的过程是繁琐的，需要带电脑带工具以及一系列的繁琐操作，效率很低下，也很很辛苦。

终端抓包和抓取日志确实是个效率很低下的问题。浪费外办运维人员的时间和精力，也浪费开发人员的精力。

这中间会不少折腾，浪费的时间也是成本，出差的费用也是成本。

不能及时快速的发现问题解决问题，造成不好的客户体验和口碑也是问题。

针对这种情况其实有一种更好的思路去解决，来降低运维压力，提高解决问题的效率。

只要设备网络没问题，能让数据跑路就不能再让人跑路。本着这一思想，

以下为基于FTP协议实现终端日志自动上送的一种方案：

首先具备的基本条件：

有一公网的FTP服务器，作为日志文件接收的地方。（这个很容易做到，我申请了一个虚拟网络空间，提供的有免费空间。这个地方http://free.3v.do 可以申请。）

终端上有记录日志的模块，自动记录日志，形成文件存储到终端，这个也容易实现。

终端上有负责FTP上传和下载的模块，这个用go做的话很容易实现。

然后就是具体的实现方案：

在FTP空间的目录里放一个配置文件，内容如：终端号+日期

终端每次开机或定时去访问FTP空间里的配置文件，获取终端号和日期信息存储到本机。

终端判定FTP目录里的配置信息是否是自己的终端号，是的话则触发日志上送，上送配置里指定的日期的日志文件。

若让所有终端的日志都上送，是不大现实且无意义的。要的就是能指定某个终端，想调哪天日志就能调取。

再此基础上增加，应用异常或应用崩溃时，主动触发上送日志的机制，或者进一步主动推送给研发或运维。增加产品的竞争力与客户体验。让问题被客户发现之前，先由研发或运维人员提前截获，及时的响应解决问题，提高产品的口碑与竞争力和客户满意度。

再完善些，可以跟微信公众号打通，在微信公众号发送终端号+日期，自动获取该终端指定日期的日志。应用崩溃时，自动发送日志到公众号。

若进一步往下完善，甚至可以成为一独立的终端运维管理平台，只要设备网络是ok的，那么无论出厂升级，参数灌装，消息推送，终端监控，异常上报，日志收集，都不用人工去干预，解放运维的压力，提高效率。这有点儿类似于物联网平台但不同于物联网平台。

物联网“平台”不仅仅是软件架构。一个以平台为核心的物联网战略创造了一个生态环境，在这里也必须有软件来为这个生态中的玩家提供业务解决方案。平台不仅仅是把物联网设备和软件模块紧密结合在一起，还有一点是它增强了平台参与者之间的关联也加强了流程管理：业务流程编排、工作流协调、数据交换等等。能够帮助建立设备与云端之间的双向通信，同时支撑海量设备的数据收集、监控、故障预测等。支持设备端到云端、云端到设备端、设备端与云端异步请求、跨厂商设备互联等场景。

物联网把平台业务和终端接入管理分离，打通数据通道，云端和设备端通信等，有其存在的价值。搞物联网平台一定不是为了赶时髦，哗众取宠。而是能否解决某些方面的问题，或显著提高了生产力或创造一些价值。如果不能使你的生产力提高或提供一些价值，那用它的意义是什么呢。

一项技术能否被应用，并且在商业上获得成功，不仅取决于当下和近期可预见的需求，更取决于它能否符合用更少的能量传递、处理和存储更多信息这个商业发展的轴心趋势，如果符合，需求甚至会被创造出来。

可是我申请的免费空间不支持PHP，不能开发个类似网站后台的小功能，否则简单的异常报警和日志收集这部分是很容易实现的。

这种方案的好处是，平台和业务不受任何影响，也不涉及任何改动。也不需要定协议，定接口。

模块化，可复用性强。 

原来是想着让终端加上MQTT协议，支持后台向终端推送消息和控制命令，但是想想这种增加了复杂性且还是得有物联网协议代理服务才行，终端还得保持长连接。但这种通过FTP的方式就简单了，无需多余的配置。

缺点也是有的，FTP获取文件的效率不高，跟http比起来，协议握手的次数太多。且我申请的免费网络空间，服务不稳定。

若终端并发量大的情况下，是否能成功获取日志是个问题。这个可以用申请付费的空间提供更好的稳定的服务解决。

关于流量的耗费上，每次开机或定时获取一次，由于logcfg.txt中的信息量很少，耗不了太多流量。

日志上送上，由于把日志压缩打包后上送的，体积10M的日志压缩后可能就800多k,耗费也不大。

且抓日志是针对解决问题的场合，没事儿谁去抓日志啊。所以流量耗费这块儿倒不是问题。

但还有个问题，后台FTP服务器会允许多个设备用一个账号登录？因此使用ftp方式每次开机或定时获取后台的配置文件的方式是不合适的。应该改用http的get方式去获取。但目前我的免费网络空间不支持。

最后说下，该方案已实现。用在了某地方，试试效果。

目前也就我一个人在用，我为此提了个金苹果创新奖但没选上。倒不是说去争什么荣誉，这是次要的。只要自己的事情做好，其他的都无所谓。只是从侧面反映大家对此都不重视，可能觉得这可有可无，用处不大。但我觉得有用，所以我做了，至少能提高点儿效率。因为我遇到过之前某地方公交出差，竟为了现场某种老卡不能刷，需要抓包的问题。为了抓个包，就需要出趟差？为了测个卡,就需要卡得寄过来？这成本可真高，因此才做了远程读写卡工具解决。

而这个呢，我陪现场人员跟我车，蹲过点，抓过包，跑过不少现场。有时候晚上十一二点还在公交场站分析解决问题。了解感受过他们的情况，深有体会。有时很感恩我们的客户的理解，包容和大度，晚上十一二点一个公交的管车辆的部长也陪同我们一块儿跑。是我们自己没做好，为此感到惭愧。

研发人员应多的跑跑一线，而不是闭门造车。你做的功能是达到了，但真正是客户想要的？喜欢的？好用的？

去听听客户的吐槽和批评，听听客户的声音，感受下外办运维人员的工作。再在做开发任务时，感受是不一样的，不是功能完成就完事了，这还远远不够，而是要精益求精，注重细节，争取做的更好。站在客户使用者的角度想问题，站在运维的角度想问题。你的一个小的细节的改进，可能能让外办人员少跑几天的路。你的一个小细节的改进，可能能给客户带来惊喜和称赞，而不是吐槽。就如同一块儿玉，如果其他地方都好就一个地方有瑕疵，那它就不是一块儿好玉，就不会被喜欢和珍惜。产品一定要打磨，精益求精，让客户喜欢，让客户好用，才能获得好的口碑和影响力，才能在激烈的市场竞争中处于不败之地。

这个权当我业余时间做的一个小工具，用于个人解决某个地方的问题。若是真正用起来，一是要重视，二是要推广，三是要标准化，四是要有后台服务器空间资源。

如果有个云空间。可以进一步优化，做一个简单的管理平台供各个地方用，每个地方都分一个账号登录。

可查看终端是否在线，灵活调取各个终端的日志包括参数信息。终端监控，终端升级，参数下发，日志获取都能做得到。这一功能标准化，独立于终端上的应用，做为终端机器上的一种出厂服务程序与后台交互。只要这终端网络是ok的，只需要装卡开机即可，其他的都不需要人来干，包括出厂灌装。

从表面上看，觉得这样实现起来不简单吧，还得做平台，投入太大。其实新的方案出来可以先不要贪全，考虑的那么的面面俱到。得给其更新迭代的机会，由小做大，由简单到复杂。先紧着核心功能，一步步的来，最后会发现万丈高楼平地起，只要大方向有了，一步步的朝目标前进，做事也没那么难。

我觉得未来终端运维一定是朝着这种方向走的。即便不是我来推动，也会有其他人来推动做这件事情。因为随着5G和智能物联网时代的到来，终端也日益强大和智能化，网络更不是问题。传统的低效率的运维工作，是该通过信息化来革命了。这也算不上是多么新的革新，像那些智能手机固件的升级不早都是这么做的。他们面向的是海量用户，若用人来维护几乎不可能。

用雷布斯雷军的话说，5G+AIoT将推动下一代超级互联网的发展，它将会是一场涉及平台、算力、网络的全面革命。这场AIoT全面革命才刚刚开始，格局未定、玩家众多，在这片新兴的蓝海市场中，还将上演无数场精彩的战役。

那么面对5G+AIoT,我们的终端设备是否已做好准备，迎接这新一轮战役的到来？通过运维的自动化和故障的提前诊断报警等等一系列的改变来带来更好的用户体验和满意度，朝着智能化的方向迈进。

我相信未来的硬件产品一定不是单纯的硬件+软件的简单组合，而是更加的网络化（物联网）智能化。是一套完整的解决方案和服务体系。比如海康威视的安防摄像头设备很火，但是假如它只是机械的很高清，硬件参数很亮眼，那没什么用。随着竞争的加剧，它未必占优势。但是它基于硬件设备提供的人脸追踪，声音识别，云监控等等一系列的服务是一套完整的智能化的解决方案，这个才是它的核心竞争力，无可替代。