使用elasticsearch与kibana来分析nginx日志小结

         最近由于项目中有很多业务功能需要借助搜索引擎才能实现（比如有业务是按照User_ID分表，但是又需要在部分地方采用entity_id的维度查询，为了避免同一业务数据需要存储两份导致一序列的问题，这样的问题就用搜索引擎来实现），甚至也想把所有涉及到DB使用like的操作用elasticsearch来实现，借此彻底避免人为或者恶意SQL注入风险的存在，刚好团队中有兄弟熟悉elasticsearch，就这么用起来了，也没有去做什么比较啊，选型啊之类，反正gitbub之类都用elasticsearch来搜索代码了，那我们这个业务实现起来应该也没有什么太大问题。我们的搜索原来是直接用Lucene裸奔的方式来实现的，双机部署，各自独立进行数据索引，以Hessian方式对内部其它应用提供搜索服务，elasticsearch就要用起来了，而我对ES却还是所知甚少，这才有了我去实践ES的苦难历程了。

        呵呵，讲了半天的前凑曲，下面ES那些事情就要粉墨登场了。 要折腾ES首要的问题就是要有实际的场景，于我就选择了用elasticsearch + kibana来处理nginx的访问日志这么个命题了。nginx的访问日志采用flume-ng来收集到Kafka，再起一个应用接收kafka的日志来建立索引，索引有了就用kibana来进行各种统计图表来展示结果，这个方案有很多想象力，可以做得事情很多。

        为了对ES有个初步掌握，我先在一台2Core CPU、6G RAM、500G STAT盘的win7系统上获得初步体验。

        场景1： elasticsearch 一个节点，单线程，单条的数据来建立索引