u014659211的专栏

目录写在最前：为什么做日志收集系统❓一、多种日志收集工具比较1、背景介绍2、Facebook 的 Scribe3、Apache 的 Chukwa4、LinkedIn 的 Kafka5、Cloudera 的 Flume OG6、“星星”小结7、众星捧月之 Apache 的 Flume NGFlume NG 架构：Flume NG 特性：Flume NG 节点组成图：Flume NG 常用组件删减节点角色，脱离 zookeeper用户配置变化之安装

1.hadoop有master与slave，Storm与之对应的节点是什么？2.Storm控制节点上面运行一个后台程序被称之为什么？3.Supervisor的作用是什么？4.Topology与Worker之间的关系是什么？5.Nimbus和Supervisor之间的所有协调工作有master来完成，还是Zookeeper集群完成？6.storm稳定的原因是什么？7.如何运行Topology？strom jar all-your-code.jar backtype.storm.MyTopolog

在云原生时代和容器化浪潮中，容器的日志采集是一个看起来不起眼却又无法忽视的重要议题。对于容器日志采集我们常用的工具有filebeat和fluentd，两者对比各有优劣，相比基于ruby的fluentd，考虑到可定制性，我们一般默认选择golang技术栈的filbeat作为主力的日志采集agent。相比较传统的日志采集方式，容器化下单节点会运行更多的服务，负载也会有更短的生命周期，而这些更容易对日志采集agent造成压力，虽然filebeat足够轻量级和高性能，但如果不了解filebeat的机制，不合理的配

为什么用到ELK：一般我们需要进行日志分析场景：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。一般大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套

作者：欧阳辰 链接：https://zhuanlan.zhihu.com/p/22165241 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。今天介绍一个来自俄罗斯的凶猛彪悍的分析数据库：ClickHouse，它是今年6月开源，俄语社区为主，好酒不怕巷子深。本文内容较长，分为三个部分：走马观花，死而后生，遥指杏花村；第一章，走马观花，初步了解一下基本特性；第二章，死而后生，介绍ClickHouse的技术架构演化的今生...

引言ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进大规模使用：今日头条内部用ClickHouse来做用户行为分析，内部一共几千个ClickHouse节点，单集群最大1200节点，总数据量几十PB，日增原始数据300TB左右。 腾讯内部用ClickHouse做游戏数据分析，并且为之建立了一整套监控运维体系。 携程内部从18年7月份开始接入试用，目前80%的业务都跑在ClickHouse上。每天数据增量十多亿，近百万次查询.

1. 背景介绍许多公司的平台每天会产生大量的日志（一般为流式数据，如，搜索引擎的pv，查询等），处理这些日志需要特定的日志系统，一般而言，这些系统需要具有以下特征：（1） 构建应用系统和分析系统的桥梁，并将它们之间的关联解耦；（2） 支持近实时的在线分析系统和类似于Hadoop之类的离线分析系统；（3） 具有高可扩展性。即：当数据量增加时，可以通过增加节点进行水平扩展。本文从设计架构，负载均衡，可扩展性和容错性等方面对比了当今开源的日志系统，包括facebook的scribe，apach