企业日志的几种情况：
A. 服务器监控日志
B. 内部应用程序日志
C. 网站用户点击行为日志
在这，我们和大家仅仅是交流下不同模式下的架构设计和使用场景而已。很多的内容我也并未深入研究下去，过程中如有不妥之处，请大家及时指正。
服务器监控日志对企业来讲是非常重要的一个部分。这部分数据包含服务器的性能监控，也包含应用程序站点的日志监控。企业上了一定规模以后，是迫切需要解决当前服务器的运行状态、应用程序运行状态。如果在外部市场投放了广告，带来巨大流量后，可视化实时监控web应用程序运行状态是很关键的。
服务器监控通常会用到Cacti，zabbix，ganglia，Splunk等工具。其中Splunk是一个顶级日志分析软件，它不仅可以用多种方式来添加日志，生产图形化报表，最厉害的是它的搜索功能 - 被称为“Google for IT”。Splunk是商业版。
Cacti，zabbix大部分是用来做服务器CPU、磁盘、网络等情况进行监控。
日志信息分析工具中推荐使用Logstash+ Elasticsearch+ Kibana这三个组合进行监控。
logstash agent 监控日志——》redis(队列) ——》logstashindex——》全文搜索服务ElasticSearch.前端通过Kibana 来结合 自定义搜索进行页面展示.
在安装这些的时候要准备好Ruby，JDK等环境。
安装过程中一定要考虑Logstash+ Elasticsearch+ Kibana这三个版本的兼容性，切莫追求最新最高大上的版本。
官网：
https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html
logstash支持的inputs、codecs、filters和outputs的参数配置:
https://www.elastic.co/guide/en/logstash/current/index.html
如果大家有兴趣，推荐中文学习资料：
http://udn.yyuap.com/doc/logstash-best-practice-cn/get_start/introduction.html
内部应用程序日志
应用程序内部产生的日志，码农专用。
应用程序的日志是在研发体系中一个非常重要的环节。一个产品上线后出现问题，例如需要排查程序过程中拼接产生的SQL，记录查询接口的请求参数和输出参数等，随着应用程序的访问量上升，存储量增大，存储的内容也非常复杂。团队在处理这类问题时，如果都是采用cat、tail、sed、awk、perl以及grep来处理，则非常耗时。
在这种情况下，我们非常需要一种既能灵活查询，又支持海量存储的程序日志架构。考虑到程序日志的特殊性，我们建议使用mongodb来负责程序日志的存储问题。Mongodb的好处不用多说。
网站用户点击行为日志
用户和互联网公司之间主要有两个方面的接触：
1. 消费数据。这部分需要实时响应，用户提交一个表单，通过应用程序存放到关系型数据库(Oracle、Mysql、sqlserver)。
2. 点击数据。用户在网站、App上的所有操作，例如页面访问量、用户行为、搜索情况。这些数据是准实时性的消息流。公司可以根据这类消息做个性化推荐，运营监控，营销等一系列的应用。
第一点的数据及其重要，是创营收的程序，这是大部分码农必须要保障的根本性任务，要做好关系型数据库的维护工作，能抗每秒**订单的指标就行了。它和本次要讲的日志有什么关系等下再说。
点击数据是企业做精细化过程中非常重要的一个宝库。它能做如下事情：
1. 分析流量的ROI，指导流量投放。
前端的点击做好渠道跟踪体系，根据用户的访问流量来统计付费渠道、免费渠道的效果。指导网站该在哪些渠道上做改进。每个互联网公司几乎都有竞价、应用市场等各个渠道的流量来源，而实时监控并统计效果，则能让流量投放更加有的放矢，把钱都花在刀刃上。
2. 建立浏览跟踪体系，优化产品页面设计
Web程序中首页、列表页、产品详情页、预订页都是可看做一个一个独立的产品。为每个类型的页面打上标记，并在用户浏览的时候记录下来。这样就可以根据用户的是否成单、停留时长、跳出率等指标来评定哪些页面是需要改进，并且也可以给出参考的数据指标。例如A页面需要改进，提升转化率到30%；B页面需要改进，提升支付率到60%。
3. 统计分析页面质量，分析漏斗转化率
根据流量漏斗，我们可以知晓页面的质量。运营此页面的人员可以跟进，迭代优化。
4. 优化用户访问路径
有了用户点击数据，我们就可以进行web路径分析，找出用户从首页到产品的最短路径。
5. 专题活动分析
专题活动页面的上线，一定要做好用户点击数据的收集工作。这些数据决定了你的专题活动的好坏。例如有些专题是专门上线拉流量的，那通过用户点击数据可知道是否达到了此目标；有些专题上线是为了促进转化，那用户点击专题后都做了什么，有没有成单，这些数据便可以考核这个专题的好坏。
6. 营销推送效果分析
短信、app推送等都是激活老会员，增加会员忠诚度的一种营销手段。如果每天发送几万或几十上百万的短信，就要根据用户点击短信中的url来分析效果。这些url中可根据url参数、点击时所在地、浏览时长、页面点击等数据来分析短信的效果。
App推送也是一样的效果。在app推送上一般都是h5页面，那就要考虑多少用户打开，能不能获取设备ID,用户在h5页面的点击行为，及后续的浏览行为。
7. 丰富会员浏览等偏好数据
用户在网站或app上的所有点击都透露了一些信息。
例如在哪个地方访问，如果这个地方出现次数最多，那是不是就可判断为用户常用地。
用户经常逛哪些产品，哪些资源，在点评信息的停留时间，浏览的深度等等这些数据。
当然用户经常不登录，但是如果在pc上有登录了，那就要想办法把历史数据和当前会员匹配上。
App更好做，绑定设备和会员的关系就好。
8. 监控转化率数据，指导运营
转化率等数据是运营的一些核心指标，用户点击行为数据是完全可以支持的。
9. 浏览的推荐行为，丰富用户接触点
当搜索无结果、当用户下完单了等场景中，我们是一定要根据用户访问的数据来为用户推荐一些结果。
网站页面本身就是一个广告位，要尽可能为用户呈现一些感兴趣的产品，增加产品的曝光度，也丰富了用户的接触点。
10. 数据分析和预测
每次的用户点击行为数据，都是可以积累下来作为数据分析和预测的依据之一。例如在当前的流量情况，预测下月的流量。考虑季节和节假日因素的话，还可以预测下一年的流量，为投放做好依据。
也可以根据现有某个产品的转化率进行分析，找出几个可能提升的点，配合业务部门一起提升。
技术架构
用户点击行为数据一般都是巨大的，场景方面有离线和准实时。
在这些情况下，各个企业一般都要贴合实际来出发。例如每天流量如果只有几万UV，那就没必要上大数据来处理；反之，流量增长到几百万UV以后，用关系型数据库来处理也不合适。
每天流量如果只有几万UV的情况下：
Web程序：用户在浏览和点击时，触发js或app sdk事件，负责将数据以json等方式提交到接口程序。
接口程序：负责解析接收到的数据，并存储到数据库。在这个地方，最好考虑下做个负载均衡。
关系型数据库：数据库方面做个读写分离。相关的监控措施配套齐全即可。
后台统计：负责统计呈现用户行为数据
如果流量提升了，并需要准实时：
我们会用到Flume，kafka，storm等，这些都是分布式的。
前端的Tengine主要是输出接口程序收到的json数据到文本中。
Flume：推荐使用Flume-NG.
Kafka:在分布式集群方面要考虑一个topic多个partition的配置，还需要考虑zookeeper集群。
Storm：如果条件允许，就升级集群配置的内存。
用户行为数据共有几个类别：
a) 需要实时查询。这些可存储到索引集群中，例如elasticSearch，solrcould等。方便业务通过字符串等快速检索数据
b) 需要准实时。这些数据主要是用来计算用户的下一次访问、感兴趣的产品。可以用spark执行计算，并将结果输出到hbase。利用hbase集群来承担对外的应用查询
c) 一般应用数据。这些主要是离线的统计分析。可以使用关系型数据库来存储，让用户能看到隔天的数据效果。
从以上内容可以看出，kafka集群是非常重要的一个环节。如果我们想做到数据驱动产品，那么用户点击就数据，这些数据通过中央存储队列kafka，被不同的应用程序消费，并计算反馈最优结果。这也是我一直期望去做的“实时消息驱动”，驱动的背后可以是营销，大盘监控，运营监控，也可以是推荐。
