零开发之日志管理平台ELK

【前言】


一、常用服务器模型

1. 多进程的并发服务器
a、每个连接fork一个进程：主进程accpet连接，有新连接到来时fork一个进程，然后继续accept，等待新的连接。数据传输由子进程处理，处理完后子进程exit。每个子进程只处理一个连接。
b、 Prefork进程：主进程预先fork一些进程，各个子进程竞争accept，然后处理数据传输。一个子进程可以处理一个连接，也可以同时处理多个连接（通过select等）。
c、 Prefork进程：由父进程accept请求，通过流管道转发fd到子进程，子进程收到fd后，处理数据传输，处理结束后通知父进程。父进程处理的事情比较简单，容易监控子进程。

2. 多线程的并发服务器
a、每个连接一个线程
b、Prethread多个线程，各个线程互斥accept
c、Prethread多个线程，主线程accept并分发连接给子线程

一般是父进程或主线程为生产者角色，子进程或子线程为消费者角色。而这些服务器模型都有个共同点，就是网络功能和业务逻辑都绑定在一个程序里。
原文出处：http://blog.csdn.net/proad/article/details/2296925


二、不重复造轮子

1、有断点的 7*24 服务
当重启时，server是暂时不能够提供服务的，至少不能accept新的连接。
也许，当时那个程序员的运气不好，服务停了便起不来，这可就太悲剧了。
所以，重启是个大问题，当然你可以在框架上做优化，不过想必要消耗不少脑力和体力。
平滑重启是个好办法：生产者不退出，消费者停止“进食”，“肚子里面的食物”消化完了便离场，换下一批进场。关键在于生产和消费的平衡。
ps：开源的服务框架（如grpc、thrift等rpc服务），需要自己实现平滑重启的功能。

2、丢失的数据
a、有状态的服务
像agent这类的异步缓冲服务，一般都需要一个或多个数据队列以及若干个worker(线程或进程)。
当它重启的时候，要保证原先内存中的数据能够恢复。
b、批量网络读写
跨地区的网络请求通常会比较耗时，为了提高性能，一般都会采用批量的访问方式。
当缓存到一定数量的数据后就触发批量读写。数据在这之前是有可能会丢失的。

为了避免数据的丢失，通常的做法是把数据写进共享内存或者消息队列里面。
倘若你的团队有这样的通用组件，那么事情便很好解决；否则，就得花时间自己动脑动手了。

3、巧用MQ(message queue)
那么，把请求直接写进MQ，再由后端程序异步处理，也许是个不错的选择。
根据业务处理的协议的不同，MQ的组成有：
a、字符串（string line、json）协议，可直接读写redis；
b、protobuf、thrift 等 rpc 协议，搭一个 rpc 服务，由它来读写redis；
c、自定义协议，搭一个能够解析自定义协议的服务，由它来读写redis；
ps：redis不是唯一的选择。你完全可以自己实现一个高可用可扩展的队列服务。


三、使用文件通信的优势（logstash）

1、耦合度低：系统间的通信，一个顺序写，一个顺序读，其余各不相干；
2、代码简单：较之socket通信，不用处理连接失败、中断等网络问题；
3、可追踪：待同步的数据就在文件上，不用再去记操作日志；
4、不容易丢失：数据已落地，除非磁盘坏了。


四、数据量大了mysql怎么办?

我的数据收集服务在接入所有的APP前，尝试接入其中的几个APP，每天新增几百万条记录，3天內毫无疑问的超过了1千万，sql语句随便加上where ***，查询都好慢。
于是不得不先分表，一天一张，由程序自动创建。暂时查询快了，但是后面的统计工作就不太好开展，况且还有很多APP未介入，总不能每小时一张表吧...
有什么海量的存储来解决这锥心的痛么？答案是：elasticsearch。
因为需要写得快，查得快，便于数据统计和挖掘，最重要的是程序员不用关心水平扩展的问题。
所以，数据量大了，mysql就得换！换！换！


五、孤陋寡闻
我用了两个月的时间，自己实现一个服务调用日志平台，存储和分析公司所有server的运行数据，如：接口的调用次数和耗时、server心跳、机器的部署，core、异常告警等。
分别用grpc编写后端数据存储 central server，用websocketpp编写local agent和数据收集lib库 info collector，修改thrift代码生成器，用python编写数据统计脚本。

螃蟹算是吃腻了：
1、grpc，刚出来不久，文档几乎没有；
2、websocketpp，基本没什么人用，本身没有实现断线重连的功能，非常耗cpu且并发量少；
3、修改thrift源码，编译调试特花时间。

经过一段时间的调试，总算是稳定下来了，后面准备把存储切换到elastic上，于是在网上找了很多资料，无意中得到了惊喜：ELK
E（Elasticsearch）L（Logstash）K（Kibana），三个开源软件皆来自：https://www.elastic.co/downloads
利用ELK，可以实现我的 central server 和 local agent 的功能，统计报表的功能也不用做了，一切只需配置即可。

唉，若是早日发现，何必今日苦逼？



【ELK】

部署很简单，报表的配置也有教程：
部署文章：http://nkcoder.github.io/blog/20141031/elkr-log-platform-deploy/
制作报表：http://blog.webkid.io/visualize-datasets-with-elk/

elastic官方手册：https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
其他中文手册：http://learnes.net/index.html
http://es.xiaoleilu.com/index.html

logstash官方手册：https://www.elastic.co/guide/en/logstash/current/index.html


我的选择：
1、用 elasticsearch 替换 mysql；
2、使用 central logstash （看上面的部署文章） 替换 我的 central server；
3、使用 shipper logstash （看上面的部署文章） 替换 我的 local agent;
4、修改 info collector，把原先通过websocket发送给 local agent 的数据以kv的形式写到指定的文件里，由logstash自动同步进elasticsearch；
5、redis 和 central logstash 都集群部署。