论产品的需求与实现系列之日志系统

         产品的需求与实现系列：

         论产品的需求与实现系列之日志系统

         论产品的需求与实现系列之监控系统

         论产品的需求与实现系列之数据平台

         论产品的需求与实现系列之ci持续集成

 

 

        刚开始的需求1: 能像tail -f 查看日志，不用单节点去查看。

           

          实施：先调研开源日志方案  

           

 

           尝试1: 用flume用采集，但采集到的日志文件不能按一定规则命名（虽是可以去改一小段的java实现），但都是文件存储方式。跟以前的相比只是不用跑去每个节点查看日志。

 

           尝试2:自我放弃了flume方案。换elk(当时的版本是1.7)。第一版的技术是elk+redis,原始的需求已经满足了，集中式，类似tail -f 方式。现在是集中式，web方式。

           

 

            需求2：要看聚合的数据，比如a一类集中显式

            解决需求2：采用 if [type]  == "a" {

 

            .....

            index => "a"

           }

           解决了

         

           需求3:数据量太大了，要过滤数据b

           解决需求3:

              filter {

                 grok {

                          add_tag => [ "valid" ]

                          match => [

                                     "message", "yzx"

                          ]

                  }

             }

       

           需求四：要归档重要的日志

           解决需求四：

 

            

 

          需求五：要自动查看ms级日志

          解决需求五：各种优化，前端，消息队列，存储，分片，索引，副本，加ngxspeed。改js 支持ms级别

-      

          总结：  从一个人最原始的需求，能集中式类似tail -f 查看日志，到了后期各种需求功能。如果从一开始提这样一个需求：

         1.集中式

         2.web

         3.过滤，聚合

         4.归档

         5.ms级实时日志

         6.从关键字查询

         会不会很吓人。

 

         产品的需求与技术实现，虽是开源的方案，但中间要学会懂得方案原理，语言。根据需求，快速实现。这是典型的互联网打法，从0到1,快速迭代实现。目前elk升级到2.x,尝试了引入kafka。

        之所以当成一个产品来说，是因为自已既是产品经理，又是技术经理角色，前期替用户假想功能需求有：用户行为分析，ip 展示图等。但用户只想看日志，don't make me think 程度，对产品功能减法，快速实现核心需求，其它只是锦上添花。