背景：对方公司数据在海外，我司数据接收服务在国内，由于某些网络原因，最后打算租一台ec2，作为数据中转服务：
服务分为两个部分，一个是receive，作为接收对方，将数据写到ec2的硬盘上；另一个是transfer负责将数据从国外EC2硬盘上保存的数据，传输到国内。
目前为止，receive与transfer都提供了简单的监控，并且为ec2也提供了相应的监控，主要是网络流量的输入输出。 但从服务开始之后，出现了一些问题：
- receive从头到尾没有出现相关问题，只是负责将接收到的数据写到硬盘上；
- transfer经常挂，具体特征：
uploading... total: 10496 success: 2304 timeout: 0 retries: 4 duration: in 2 hoursess
uploading... total: 10496 success: 2304 timeout: 0 retries: 4 duration: in 2 hours
uploading... total: 10496 success: 2304 timeout: 0 retries: 4 duration: in 2 hours
如上，transfer提供以上几个指标，total指的是接收到的数据，success指代成功传输的数据，retries指的是重试的数据条数，duration指的是运行了多长时间
发生问题时，total继续接受数据，不断增大，但success不再变化，经过一段时间后，total与success都不在发生变化，网络输出流量也少得可怜。可以知道receive目前依然在正常的运行，但transfer已经卡死，重启transfer之后中转服务可以恢复，但从发现transfer卡死到重启之间，会存在大量日志通过receive保存到了硬盘但没有进行transfer传输到公司后台。
- transfer的改进，最开始的transfer直接使用
tail -n 0 -f filename.log > node .....
这种方案使用了大概几天出现问题，觉得可能是linux提供的pipe buffer的问题，因此修改代码，使用了tail，之后发现了一问题，一下子大批量导入的话，tail并不能良好分割消息，可能造成消息体混乱，相关issuetail.on(‘line’, function(data)) may get messy data，最后换成了always-tail，这个测试可以解决上面tail暴露的那个问题，然而然而，该来的还是要来的，在最近10天中，最长的坚持了3天，最短20分钟，特别是网络不好的时候，今天早上6点起来重启了下，当时的丢包率大概是58%，不排除是网络问题。 为什么发帖，因为真的找不到其他好的思路了，目前想法主要集中于两点，一个是代码问题，transfer没法提供，但是它底层调用的代码可以到这里查看lambdacloud-uploader.js，还有一个便是网络问题，网络的话确实不太好解决。 各位给点思路啊！ :black_hands:
@sunyonggang 哈哈是啊我也觉得有点怪。之前我做了一个应用，也是涉及这种美国主机往七牛 push 数据的，经常因为网络问题出错。 而且不知道我的这个看法是否正确：当数据要从国外传回国内的时候，【从国外主动传】与【从国内出去拉】的网络情况是不同的。
@alsotang 好想法，假如从国内拉的状况不一样的话，可以试一下。我怀疑是晚上的时候网络状况变坏了，后来尽管网络恢复了，但数据服务已经出问题了，不再进行数据传输。
