日志数据处理
这么多的日志，运维要通过各种手段完成日志的收集、过滤分析、可视化展示，那么如何实现这些功能呢？
方法很多，例如ELK集成套件（Elasticsearch , Logstash, Kibana）就可以轻松实现日志数据的实时收集、分析传输以及图形化展示。
那么要如何使用ELK呢，根据日志量的不同，对应的ELK架构也不尽相同，看下面几个常见架构：
ELK架构1
此架构主要是将Logstash部署在各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。
Elasticsearch再将数据以分片的形式压缩存储，并提供多种API供用户查询、操作。用户可以通过Kibana Web直观的对日志进行查询，并根据需求生成数据报表。
此架构的优点是搭建简单，易于上手。缺点是Logstash消耗系统资源比较大，运行时占用CPU和内存资源较高。
另外，由于没有消息队列缓存，可能存在数据丢失的风险。此架构建议供初学者或数据量小的环境使用。
ELK架构2
由此衍生出来了第二种架构：
此架构主要特点是引入了消息队列机制，位于各个节点上的Logstash Agent（一级Logstash，主要用来传输数据）先将数据传递给消息队列（常见的有Kafka、Redis等）。
接着，Logstash server（二级Logstash，主要用来拉取消息队列数据，过滤并分析数据）将格式化的数据传递给Elasticsearch进行存储。
最后，由Kibana将日志和数据呈现给用户。由于引入了Kafka（或者Redis）缓存机制，即使远端Logstash server因故障停止运行，数据也不会丢失，因为数据已经被存储下来了。
这种架构适合于较大集群、数据量一般的应用环境，但由于二级Logstash要分析处理大量数据，同时Elasticsearch也要存储和索引大量数据，因此它们的负荷会比较重，解决的方法是将它们配置为集群模式，以分担负载。
此架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题，在海量数据应用场景下，可能会出现性能瓶颈。
ELK架构3
最后，还有第三种架构：
这个架构是在上面第二个架构基础上改进而来的，主要是将前端收集数据的Logstash Agent换成了filebeat，消息队列使用了kafka集群，然后将Logstash和Elasticsearch都通过集群模式进行构建。
此架构适合大型集群、海量数据的业务场景，它通过将前端Logstash Agent替换成filebeat，有效降低了收集日志对业务系统资源的消耗。
同时，消息队列使用kafka集群架构，有效保障了收集数据的安全性和稳定性，而后端Logstash和Elasticsearch均采用集群模式搭建，从整体上提高了ELK系统的高效性、扩展性和吞吐量。
用大数据思维做运维监控
大数据分析最早就来源于运维人的日志分析，到逐渐发展对各种业务的分析，人们发现这些数据蕴涵着非常大的价值。
那么如何用大数据思维做运维呢，大数据架构上的一个思维就是：提供一个平台让运维方便解决这些问题， 而不是，让大数据平台去解决出现的问题。
基本的一个大数据运维架构是这样的：
对于运维的监控，利用大数据思维，需要分三步走：
获取需要的数据过滤出异常数据并设置告警阀值通过第三方监控平台进行告警
所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是定义分析日志的的逻辑。
340
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
