论产品的需求与实现系列之日志系统
产品的需求与实现系列:
论产品的需求与实现系列之监控系统
论产品的需求与实现系列之数据平台
刚开始的需求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 程度,对产品功能减法,快速实现核心需求,其它只是锦上添花。