分享美团日志收集系统的架构设计和实战经验

美团日志收集系统负责收集美团的所有业务日志，并为Hadoop平台和Storm平台提供离线数据和实时数据流。基于Flume设计和构建的美团日志收集系统。基于Flume的美团日志收集系统将向读者展示美团日志收集系统的架构设计和实践经验。架构和设计的第一部分主要集中在日志收集系统的整体架构设计上，以及为什么要做这样的设计。第二部分的改进和优化将主要集中在实际部署和使用过程中遇到的问题上，以及Flume的功能修改和优化。日志收集是大数据的基石。许多公司的业务平台每天都会产生大量的日志数据。日志收集系统需要收集业务日志数据，供离线和在线分析系统使用。日志收集系统的基本特征是高可用性、高可靠性和可扩展性。Flume、Scribe等是目前常用的开源日志收集系统。Flume是Cloudera提供的一个高度可用、高度可靠、分布式的海量日志采集、聚合和传输系统，目前是Apache的子项目。Scribe是Facebook开源的日志收集系统，为日志的分布式收集和统一处理提供了可扩展、高容错的简单解决方案。对比下面常用的开源日志收集系统，将对比常用的开源日志收集系统Flume和Scribe的各个方面。Flume主要以Apache下的Flume-NG为参考对象。与此同时，美团将常用的日志收集系统分为三层(Agent层、Colector层和Store层)进行比较。美团日志收集系统负责收集美团的所有业务日志，并为Hadoop平台提供离线数据和Storm平台提供实时数据流。基于Flume设计和构建的美团日志收集系统。每天收集和处理约T级别的日志数据。下图是美团日志收集系统的整体框架图。a.整个系统分为三层：Agent层、Collector层和Store层。其中，Agent层的每台机器部署一个过程，负责收集单台机器的日志；Collector层部署在中央服务器上，负责接收Agent层发送的日志，并根据路由规则在相应的store层中编写日志；Store层负责提供永久或临时的日志存储服务，或将日志流引导到其他服务器。b.Agent到Collector使用LoadBalance策略，平衡地将所有日志发送到所有Colector上，以实现负载平衡的目标，并处理单个Collector故障的问题。c.Collector层主要有三个目标：SinkHdfs,Sinkkafka和SinkBypass。将离线数据分别提供到HDFs，并将实时日志提供到Kafka和Bypass。SinkHdfs根据日志量的大小分为SinkHdfs_b，SinkHdfs_m和SinkHdfs_s三Sink，以提高写入HDFS的性能，详见后面介绍。d.对于Store，Hdfs负责永久存储所有日志；Kafka存储最新的7天日志，并为Storm系统提供实时日志流；Bypass负责为其他服务器和应用程序提供实时日志流。下图是美团日志收集系统的模块分解图，详细说明Agent、Colector和Bypass中的Source、Chanel和Sink之间的关系。a.模块命名规则：所有Source从src开始，所有Chanel从ch开始，所有Sink从sink开始；b.Chanel统一使用美团开发的DualChanel，具体原因后面详细说明；NulChanel用于过滤掉的日志，后面详细说明具体原因；c.Avro接口统一用于模块之间的内部通信；4架构设计将从可用性、可靠性、可扩展性和兼容性等方面对上述架构进行详细分析。4.1可用性(availablity)对于日志收集系统，可用性(availablity)指系统在固定周期内无故障运行的总时间。4.1可用性(availablity)对于日志收集系统，可用性(availablity)指系统在固定周期内无故障运行的总时间。为了提高系统的可用性，需要消除系统的单点，提高系统的冗余度。让我们来看看美团日志收集系统的可用性。4.1.Agent*Agent*分为两种情况：机器*或Agent过程*。对于机器死机的情况，由于产生日志的过程也会*，因此不会产生新的日志，也不会提供服务。对于Agent过程的*，确实会降低系统的可用性。在这方面，美团有三种方法可以提高系统的可用性。首先，所有的Agent都是以supervise的方式启动的。如果过程*，系统将立即重启以提供服务。其次，对所有Agent进行生存监控，发现Agent*后立即报警。最后，对于非常重要的日志，建议应用程序直接将日志写成磁盘，Agent通过spoldir获得最新的日志。4.1.由于中央服务器提供平等、无差异的服务，Agent访问Collector制定了LoadBalance和重试机制，因此Collector*。因此，当Collector无法提供服务时，Agent的重试策略会将数据发送到其他可用的Collector上。因此，整个服务不受影响。4.1.美团在Colector的Hdfsink中提供了开关选项，可以控制Collector停止写Hdfs，并将所有events缓存到Filechanel。4.1.如果Hdfs异常停机或不可访问，Collector此时无法写Hdfs，则4hdfs异常停机或不可访问。由于美团使用dualchanel，collector可以将收到的events缓存到filechanel，并保存在磁盘上，并继续提供服务。Hdfs恢复服务后，将FileChanel中缓存的events发送到Hdfs。这种机制类似于Scribe，可以提供更好的容错性。4.1.5Collector或Agent/Collector网络变慢，如果Collector处理速度变慢(例如机器load过高)或Agent/Collector之间的网络变慢，则Agent发送到Collector的速度可能会变慢。同样，在这种情况下，美团在Agent端使用DualChanel，Agent可以将收到的events缓存到FileChanel，保存在磁盘上，并继续提供服务。Collector恢复服务后，将Filechanel中缓存的events发送给Colector。4.1.当Hdfs在Hadoop上有更多的任务和大量的读写操作时，Hdfs的读写数据往往会变慢。这种情况很常见，因为每天每周都有高峰使用期。美团还使用DualChanel来解决HDFs变慢的问题。Hdfs快速写入时，所有events只通过Memchanel传输数据，减少磁盘IO，获得更高的性能。当Hdfs写入较慢时，所有events只通过fileChanel传输数据，数据缓存空间较大。4.2可靠性(reliability)对于日志收集系统，可靠性(reliability)在数据流传输过程中，Flume保证了events的可靠传输。对于Flume来说，所有的events都保存在Agent的Chanel中，然后发送到数据流中的下一个Agent或最终存储服务。那么AgentChanel中的events何时被删除呢？当它们被保存到下一个Agent的Chanel或最终的存储服务中时。这是Flume提供数据流中点到点可靠性保证的最基本的单跳信息传递语义。那Flume是如何实现上述最基本的信息传递语义的呢？首先，Agent之间的事务交换。Flume使用事务的方法来确保event的可靠传输。Source和Sink分别包装在保存event或Channel的事务中。这就保证了event在数据流的点对点传输中是可靠的。在多级数据流中，如下图所示，上级Sink和下级Source都包含在事务中，以确保数据可靠地从一个Channel转移到另一个Chanel。第二，Channel在数据流中的持久性。在Flume中，MemoryChanel可能会丢失数据(Agent*时)，而FileChanel是持久的，提供类似mysql的日志机制，以确保数据不丢失。4.3可扩展性(scalability)对于日志收集系统，可扩展性(scalability)是指系统能够线性扩展。当日志量增加时，系统可以简单地增加机器，以实现线性扩容。对于基于Flume的日志收集系统，在设计的每一层都需要线性扩展服务。下面将对每层的可扩展性进行相应的说明。4.3.Agent层对于Agent层，每台机器部署一个Agent，可以在不受限制的情况下水平扩展。一方面，Agent收集日志的能力受机器性能的限制，Agent通常可以为单机提供足够的服务。另一方面，如果机器较多，可能会受到后端Colector提供的服务的限制，但Agent到Collector有LoadBalance机制，使Collector能够线性扩展和提高其能力。4.3.对于Collector层，Agent到Collector有LoadBalance机制，Collector提供无差异的服务，因此可以线性扩展。其性能主要局限于Store层提供的能力。4.3.对于Store层来说，Hdfs和Kafka都是分布式系统，可以实现线性扩展。Bypass属于临时应用，只对应某一类日志，性能不是瓶颈。Flume1.4.4.4channel选择.在0中，它的官方提供常用的MemoryChannel和FileChannel供您选择。其优缺点如下：MemoryChannel:所有events都保存在内存中。优点是吞吐量高。缺点是容量有限，Agent*时内存中的数据会丢失。FileChannel:所有events都保存在文件中。优点是容量大，*时数据可以恢复。缺点是速度慢。上述两种Channel，优缺点相反，分别有自己合适的场景。然而，对于大多数应用程序来说，美团希望Channel能够提供高吞吐量和大缓存。基于此，美团开发了DualChanel。DualChannel：基于MemoryChanel和FileChanel的开发。当堆积在chanel中的events数小于阈值时，所有events都保存在memorychanel中，sink从memorychanel中读取数据；当堆积在chanel中的events数大于阈值时，所有events都自动存储在filechanel中，Sink从FileChanel中读取数据。这样，当系统正常运行时，美团可以使用MemoryChanel的高吞吐特性；当系统异常时，美团可以使用FileChanel的大缓存特性。4.5与scribe兼容。在设计之初，美团要求每种日志都有一个对应的category，flumeagent提供两种服务:avrosource和scribesource。4.5与scribe兼容。在设计之初，美团要求每种日志都有一个对应的category，flume的agent提供两种服务:avrosource和scribesource。这将与之前的scribe相对应，降低业务变更成本。在目前的日志收集系统中，美团只使用最简单的权限控制。只有设置的category才能进入存储系统。所以目前的权限控制是category过滤。如果将权限控制放在Agent端，其优点是可以更好地控制系统中垃圾数据的流通。但缺点是配置修改麻烦，每增加一个日志就需要重启或重载Agent配置。若将权限控制放在Collector端，则优点是便于配置的修改和加载。缺点是Agent/Collector之间可能会传输一些未注册的数据。考虑到Agent/colector之间的日志传输不是系统瓶颈，目前的日志收集属于内部系统，安全问题是次要问题，因此选择使用colector端控制。4.7提供实时流美团的一些业务，如实时推荐、反爬虫服务等，需要处理实时数据流。因此，美团希望Flume能够导出一个实时流给Kafka/Storm系统。一个非常重要的要求是，实时数据流不应受到其他Sink速度的影响，以确保实时数据流的速度。在这一点上，美团通过Co

以上就是关于分享美团日志收集系统的架构设计和实战经验的相关介绍，更多分享美团日志收集系统的架构设计和实战经验相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对分享美团日志收集系统的架构设计和实战经验有更深的了解和认识。