项目背景
每个系统都有日志, 当系统出现问题时, 需要通过日志解决问题
当系统机器比较少时, 登陆到服务器上查看即可满足
当系统机器规模巨大, 登陆到机器上查看几乎不现实
当然即使是机器规模不大, 一个系统通常也会涉及到多种语言的开发, 拿我们公司来说, 底层是通过 c++ 开发的, 而也业务应用层是通过 Python 开发的, 并且即使是 C++ 也分了很多级别应用, python 这边同样也是有多个应用, 那么问题来了, 每次系统出问题了, 如何能够迅速查问题? 好一点的情况可能是 python 应用层查日志发现是系统底层处理异常了, 于是又叫 C++ 同事来查, 如果 C++ 这边能够迅速定位出错误告知 python 层这边还好, 如果错误好排查, 可能就是各个开发层的都在一起查到底是哪里引起的当然可能这样说比较笼统, 但是却引发了一个问题:
当系统出现问题后, 如何根据日志迅速的定位问题出在一个应用层?
在平常的工作中如何根据日志分析出一个请求到系统主要在那个应用层耗时较大?
在平常的工作中如何获取一个请求到达系统后在各个层测日志汇总?
针对以上问题, 我们想要实现的一个解决方案是:
把机器上的日志实时收集, 统一的存储到中心系统
然后再对这些日志建立索引, 通过搜索即可以找到对应日志
通过提供界面友好的 web 界面, 通过 web 即可以完成日志搜索
关于实现这个系统时可能会面临的问题:
实时日志量非常大, 每天几十亿条(虽然现在我们公司的系统还没达到这个级别)
日志准实时收集, 延迟控制在分钟级别
能够水平可扩展
关于日志收集系统, 业界的解决方案是 ELK
ELK 的解决方案是通用的一套解决方案, 所以不免就会产生以下的几个问题:
运维成本高, 每增加一个日志收集, 都需要手动修改配置
监控缺失, 无法准确获取 logstash 的状态
无法做定制化开发以及维护
针对这种情况, 其实我们想要的系统是 agent 可以动态的获取某个服务器我们需要监控哪些日志
以及那些日志我们需要收集, 并且当我们需要收集日志的服务器下线了, 我们可以动态的停止收集
当然这些实现的效果最终也是通过 web 界面呈现
日志收集系统设计
主要的架构图为
关于各个组件的说明:
Log Agent, 日志收集客户端, 用来收集服务器上的日志
Kafka, 高吞吐量的分布式队列, linkin 开发, apache 顶级开源项目
ES,elasticsearch, 开源的搜索引擎, 提供基于 http restful 的 web 接口
Hadoop, 分布式计算框架, 能够对大量数据进行分布式处理的平台
关于 Kakfa 的介绍
Apache Kafka 是一个分布式发布 - 订阅消息系统和一个强大的队列, 可以处理大量的数据, 并使您能够将消息从一个端点传递到另一个端点 Kafka 适合离线和在线消息消费 Kafka 消息保留在磁盘上, 并在群集内复制以防止数据丢失 Kafka 构建在 ZooKeeper 同步服务之上 它与 Apache Storm 和 Spark 非常好地集成, 用于实时流式数据分析
注: 这里关于 Kafka 并不会介绍太多, 只是对基本的内容和应用场景的说明, 毕竟展开来说, 这里的知识也是费非常多的
Kafka 中有几个基本的消息术语需要了解:
Kafka 将消息以 topic 为单位进行归纳
将向 Kafka topic 发布消息的程序成为 producers.
将预订 topics 并消费消息的程序成为 consumer.
Kafka 以集群的方式运行, 可以由一个或多个服务组成, 每个服务叫做一个 broker.
Kafka 的优点:
可靠性 - Kafka 是分布式, 分区, 复制和容错的
可扩展性 - Kafka 消息传递系统轻松缩放, 无需停机
耐用性 - Kafka 使用分布式提交日志, 这意味着消息会尽可能快地保留在磁盘上, 因此它是持久的
性能 - Kafka 对于发布和订阅消息都具有高吞吐量 即使存储了许多 TB 的消息, 它也保持稳定的性能
Kafka 非常快, 并保证零停机和零数据丢失
Kafka 的应用场景:
异步处理, 把非关键流程异步化, 提高系统的响应时间和健壮性
应用解耦, 通过消息队列
流量削峰
关于 ZooKeeper 介绍
ZooKeeper 是一种分布式协调服务, 用于管理大型主机在分布式环境中协调和管理服务是一个复杂的过程 ZooKeeper 通过其简单的架构和 API 解决了这个问题 ZooKeeper 允许开发人员专注于核心应用程序逻辑, 而不必担心应用程序的分布式特性
Apache ZooKeeper 是由集群 (节点组) 使用的一种服务, 用于在自身之间协调, 并通过稳健的同步技术维护共享数据 ZooKeeper 本身是一个分布式应用程序, 为写入分布式应用程序提供服务
ZooKeeper 主要包含几下几个组件:
Client(客户端): 我们的分布式应用集群中的一个节点, 从服务器访问信息对于特定的时间间隔, 每个客户端向服务器发送消息以使服务器知道客户端是活跃的类似地, 当客户端连接时, 服务器发送确认码如果连接的服务器没有响应, 客户端会自动将消息重定向到另一个服务器
Server(服务器): 服务器, 我们的 ZooKeeper 总体中的一个节点, 为客户端提供所有的服务向客户端发送确认码以告知服务器是活跃的
Ensemble:ZooKeeper 服务器组形成 ensemble 所需的最小节点数为 3
Leader: 服务器节点, 如果任何连接的节点失败, 则执行自动恢复 Leader 在服务启动时被选举
Follower: 跟随 leader 指令的服务器节点
ZooKeeper 的应用场景:
服务注册 & 服务发现
配置中心
分布式锁
Zookeeper 是强一致的多个客户端同时在 Zookeeper 上创建相同 znode, 只有一个创建成功
关于 Log Agent
这个就是我们后面要通过代码实现的一步分内容, 主要实现的功能是:
类似于我们在 linux 下通过 tail 的方法读日志文件, 讲读取的内容发给 Kafka
这里需要知道的是, 我们这里的 tailf 是可以动态变化的, 当配置文件发生变化是, 可以通知我们程序自动增加需要增加的 tailf 去获取相应的日志并发给 kafka producer
主要由一下几部目录组成:
- Kafka
- tailf
- configlog
小结
以上是对整个要开发的系统的一个总的概括, 以及架构的一个构建, 并且各个组件的实现, 接下来会一个一个实现每个部分的功能, 下一篇文章会实现上述组件中 log Agent 的开发
来源: https://www.cnblogs.com/zhaof/p/8641951.html