做网站类的书本信息,网络建构是什么意思,网站推广公司 wordpress,无锡做家纺公司网站ELK/EFK日志系统 如果今天谈论到要部署一套日志系统#xff0c;相信用户首先会想到的就是经典的ELK架构#xff0c;或者现在被称为Elastic Stack。 Elastic Stack架构为Elasticsearch Logstash Kibana Beats的组合#xff0c;其中#xff0c;Beats负责日志的采集…ELK/EFK日志系统 如果今天谈论到要部署一套日志系统相信用户首先会想到的就是经典的ELK架构或者现在被称为Elastic Stack。 Elastic Stack架构为Elasticsearch Logstash Kibana Beats的组合其中Beats负责日志的采集 Logstash负责做日志的聚合和处理Elasticsearch作为日志的存储和搜索系统Kibana作为可视化前端展示整体架构如下图所示 此外在容器化场景中尤其是在Kubernetes环境中用户经常使用的另一套框架是EFK架构。 其中E还是ElasticsearchK还是Kibana其中的F代表Fluent Bit一个开源多平台的日志处理器和转发器。 Fluent Bit可以让用户从不同的来源收集数据/日志统一并发送到多个目的地并且它完全兼容Docker和Kubernetes环境。 既生瑜何生亮 ELK 的缺点 最近在对公司容器云的日志方案进行设计的时候发现主流的ELK或者EFK比较重再加上现阶段对于ES复杂的搜索功能很多都用不上最终选择了Grafana开源的Loki日志系统下面介绍下Loki的背景。 背景和动机 当我们的容器云运行的应用或者某个节点出现问题了解决思路应该如下 我们的监控使用的是基于Prometheus体系进行改造的Prometheus中比较重要的是Metric和AlertMetric是来说明当前或者历史达到了某个值Alert设置Metric达到某个特定的基数触发了告警但是这些信息明显是不够的。 我们都知道Kubernetes的基本单位是PodPod把日志输出到stdout和stderr平时有什么问题我们通常在界面或者通过命令查看相关的日志 举个例子当我们的某个Pod的内存变得很大触发了我们的Alert这个时候管理员去页面查询确认是哪个Pod有问题然后要确认Pod内存变大的原因我们还需要去查询Pod的日志如果没有日志系统那么我们就需要到页面或者使用命令进行查询了 如果这个时候应用突然挂了这个时候我们就无法查到相关的日志了所以需要引入日志系统统一收集日志而使用ELK的话就需要在Kibana和Grafana之间切换影响用户体验。 所以 loki的第一目的就是最小化度量和日志的切换成本有助于减少异常事件的响应时间和提高用户的体验。 ELK存在的问题 现有的很多日志采集的方案都是采用全文检索对日志进行索引如ELK方案优点是功能丰富允许复杂的操作。 但是这些方案往往规模复杂资源占用高操作苦难。 很多功能往往用不上大多数查询只关注一定时间范围和一些简单的参数如host、service等使用这些解决方案就有点杀鸡用牛刀的感觉了。 因此Loki的第二个目的是在查询语言的易操作性和复杂性之间可以达到一个权衡。 成本 全文检索的方案也带来成本问题简单的说就是全文搜索如ES的倒排索引的切分和共享的成本较高。 后来出现了其他不同的设计方案如OKlog采用最终一致的、基于网格的分布策略。 这两个设计决策提供了大量的成本降低和非常简单的操作但是查询不够方便。 因此Loki的第三个目的是提高一个更具成本效益的解决方案。