使用 Loki 搭建个人日志平台

背景

Loki的第一个稳定版本于2019年11月19日发布,是 Grafana Labs 团队最新的开源项目,是一个水平可扩展,高可用性,多租户的日志聚合系统。 Grafana 对 Loki 的描述如下:

Loki: like Prometheus, but for logs. Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus. It is designed to be very cost effective and easy to operate. It does not index the contents of the logs, but rather a set of labels for each log stream.

简单说,Loki 是专门用于聚集日志数据,重点是高可用性和可伸缩性。与竞争对手不同的是,它确实易于安装且资源效率极高。

血衫目前运维大概上百个节点,虽然系统是统一的基线版本且使用docker运行应用,平时相安无事,但变更后的问题排查仍有点心有余悸。对一个火热的日志系统elk也有浅尝辄止,奈何对于非核心应用,多耗散一份算力意味着成本增加和利润的减少,elk对于小团队来说,还是过于笨重。趁着近日的疫情无法外出,调研后将 Loki 上线了生产,可以说是完美契合了中小团队对日志平台的需求。

介绍

与其他日志聚合系统相比,Loki具有下面的一些特性:

  • 不对日志进行全文索引(vs ELK技)。通过存储压缩非结构化日志和仅索引元数据,Loki 操作起来会更简单,更省成本。
  • 通过使用与 Prometheus 相同的标签记录流对日志进行索引和分组,这使得日志的扩展和操作效率更高。
  • 特别适合储存 Kubernetes Pod 日志; 诸如 Pod 标签之类的元数据会被自动删除和编入索引。
  • 受 Grafana 原生支持。

Loki 由以下3个部分组成:

  • loki是主服务器,负责存储日志和处理查询。
  • promtail是代理,负责收集日志并将其发送给 loki 。
  • Grafana用于 UI 展示。

一、安装

Docker-compose.yml 可以参考Loki文档介绍,开箱即用。

version: "3"

networks:
  loki:

services:
  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"
    command: -config.file=/etc/loki/local-config.yaml
    networks:
      - loki

  promtail:
    image: grafana/promtail:latest
    volumes:
      - /var/log:/var/log
    command: -config.file=/etc/promtail/docker-config.yaml
    networks:
      - loki

  grafana:
    image: grafana/grafana:master
    ports:
      - "3000:3000"
    networks:
      - loki

然后直接使用 docker-compose 启动即可:

$ docker-compose up -d

二、使用

安装完成后,访问节点的 3000 端口访问 grafana,默认情况下使用(admin:admin)访问 -> 选择添加数据源:

grafana-loki-dashsource

在数据源列表中选择Loki,配置 Loki 源地址:

grafana-loki-dashsource-configgrafana-loki-dashsource-config

源地址配置http://loki:3100即可,保存。

保存完成后,切换到 grafana 左侧区域的Explore,即可进入到Loki的页面,点击Log labels就可以把当前系统采集的日志标签给显示出来,可以根据这些标签进行日志的过滤查询:

image-20200202180915479

图中显示的label是我自定义的 label,大家可以根据自己的业务需求定义自己的label。

三、配置

从上面的步骤已经可以一窥使用方法了,如果要使用起来,我们还需要了解如下信息:

Loki 的配置

Loki的详细配置,可查看官方文档:https://github.com/grafana/loki/blob/master/docs/README.md

配置相关文档: https://github.com/grafana/loki/blob/v1.3.0/docs/configuration/README.md

我目前均保留了保留默认配置。

promtail的配置

promtail 是 Loki 的官方支持的日志采集端,在需要采集日志的节点上运行采集日志,再统一发送到 Loki 进行处理。我们编写的大多是这一部分。

官方配置说明: https://github.com/grafana/loki/blob/v1.3.0/docs/clients/promtail/configuration.md

除了使用Promtail,社区还有很多采集日志的组件,比如fluentd、fluent bit等,都是比较优秀的。

这里是我的promtail配置,bj1是我的节点,在address等配置会域名解析成ip的方式。

server:
  http_listen_address: bj1
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /etc/promtail/positions.yaml
  sync_period: 10s

clients:
  - url: http://bj1:3100/loki/api/v1/push

scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: system
      app: system
      node: bj1
      __path__: /var/log/*log
- job_name: cron
  static_configs:
  - targets:
      - localhost
    labels:
      job: cron
      app: cron
      node: bj1
      __path__: /var/local/log/cron/*log

四、选择器

对于查询表达式的标签部分,将其包装在花括号中{},然后使用键值对的语法来选择标签,多个标签表达式用逗号分隔,比如:

{app="mysql",name="mysql-backup"}

目前支持以下标签匹配运算符:

  • =等于
  • !=不相等
  • =~正则表达式匹配
  • !~不匹配正则表达式

比如:

{name=~"mysql.+"}
{name!~"mysql.+"}

适用于Prometheus标签选择器规则同样也适用于Loki日志流选择器。

参考资料


【Calico系列】4 数据中心网络简述

本文是 Calico 系列的第四篇文章,上一篇了解了 calico 的组件、架构与原理,这篇学习数据中心的网络设计。本篇的内容为血衫学习文末参考资料后的笔记。

由于网络的水深与个人能力有限,本文不免存在错误之处。如有疑问,请查阅文末参考资料或与我线上/线下讨论。

一、分层网络设计

思科的分层(三层)互连网络模型(hierarchical internetworking model)是工业界设计可靠、可扩展、高性价比的互连网络时广泛采用的模型。

讨论网络设计时,通常根据设备数量将网络分成几类:

  • 小型网络:支持最多 200 个设备
  • 中型网络:支持 200 ~ 1000 个设备
  • 大型网络:支持 1000+ 设备

网络设计随规模和公司需求的不同而不同。例如,小公司的设备数量比较少,因此网络基础 设施就无需像大公司设计的那么复杂。

思科分层网络模型中的三个层:接入层、汇聚层、核心层。

早期网络

早期的网络都是扁平拓扑(flat topology):

img

当更多的设备需要接入网络时,就添加集线器(hub)和交换机(switch)。扁平网络设计 的缺点是很难控制广播流量,或者对特定流量进行过滤。当网络中的设备越来越多时, 响应时间也会越来越慢,最终使得网络不可用。

因此,我们需要一个更好的方案。现在,大部分公司都使用下图所示的分层网络方案:

img

将扁平网络划分成更小、更易管理的组成部分的好处是可以将本地流量限制在本地( local traffic remains local)。只有目的是其他网络的流量才会被传送到更高的层。

一个典型的企业分层局域网(hierarchical LAN)包括三层:

  • 接入层:提供工作组/用户接入网络的功能
  • 汇聚层:提供基于策略的连接功能,控制接入层和核心层的边界
  • 核心层:提供汇聚层交换机之间的高速传输

另一个三层分层网络设计如下图所示,注意其中的每个 building 都是分层网络模型 ,包括了接入层、汇聚层和核心层。

img

注意:设计网络的物理拓扑并没有绝对的规则。虽然很多网络都是基于三层的物理 设备搭建的,但这并不是强制条件。在小一些的网络中,核心层和汇聚层可能会合并为一层,由同一个物理交换机充当,这样网络就变成了两层。这被称为 collapsed core design(塌缩的核心层设计)。

二、传统三层网络架构

一个标准的传统三层的网络结构如下l两张图所示:

img

基于传统的三层架构,基本都是从园区网络设计中复制而来的。

这种架构由核心路由器汇聚路由器接入交换机组成。

随着虚拟化技术的发展,节点虚机vm的数量增多,应用的部署方式越来越分布式,东西向流量( east-west-traffic)越来越大。这些流量需要被高效地处理,并且还要保证低的、可预测的延迟。而虚机互访需要通过层层的上行口,因此三层数据中心架构中的带宽成为了瓶颈。 三层架构的另一个问题是服务器到服务器延迟(server-to-server latency)随着流量路 径的不同而不同

由于传统三层网络架构存在的问题,在2008年一篇文章A scalable, commodity data center network architecture,提出将Clos架构应用在网络架构中。2014年,在Juniper的白皮书中,也提到了Clos架构。

事实已经证明,基于 Clos 网络的 Spine-and-Leaf 架构(Clos network-based Spine-and-Leaf architecture)架构可以提供高带宽、低延迟、非阻塞的服务器到服务器连接。

三、Spine-Leaf 架构

如下图是一个典型的两级 Spine-and-Leaf 拓扑。

img

在以上两级 Clos 架构中,每个低层级的交换机(leaf)都会连接到每个高层级的交换机 (spine),形成一个 full-mesh 拓扑。leaf 层由接入交换机组成,用于连接服务器等 设备。spine 层是网络的骨干(backbone),负责将所有的 leaf 连接起来。 fabric 中的每个 leaf 都会连接到每个 spine,因此任一层中的单交换机故障都不会影响整个网络结构。

如果某个链路被打满了,扩容过程也很直接:添加一个 spine 交换机就可以扩展每个 leaf 的上行链路,增大了 leaf 和 spine 之间的带宽,缓解了链路被打爆的问题。如果接入层 的端口数量成为了瓶颈,那就直接添加一个新的 leaf,然后将其连接到每个 spine 并做相 应的配置即可。这种易于扩展(ease of expansion)的特性优化了 IT 部门扩展网络的过 程。leaf 层的接入端口和上行链路都没有瓶颈时,这个架构就实现了无阻塞(nonblocking)。

在 Spine-and-Leaf 架构中,任意一个服务器到另一个服务器的连接,都会经过相同数量 的设备(除非这两个服务器在同一 leaf 下面),这保证了延迟是可预测的,因为一个包 只需要经过一个 spine 和另一个 leaf 就可以到达目的端。

三、Overlay 网络

现代虚拟化数据中心的网络要加速应用部署和支持 DevOps,必须满足特定的前提 条件。例如,需要支持扩展转发表、扩展网段、L2 segment extension、虚拟设备漂移(mobility)、转发路径优化、共享物理基础设施上的网络虚拟 化和多租户等等。

虽然 overlay 的概念并不是最近才提出的,但因为它可以解决以上提到的问题,因此近几 年这个概念又火了起来。最近专门针对数据中心提出的新的帧封装格式(encapsulation frame format)更是为这个势头添了一把火。这些格式包括:

  • VXLAN:Virtual Extensible LAN
  • NVGRE: Network Virtualization Using Generic Routing Encapsulation
  • TRILL: Transparent Interconnection of Lots of Links
  • LISP: Location/Identifier Separation Protocol

overlay 网络是共享底层网络(underlay network)的节点之间互连形成的虚拟网络,这使得在不修改底层(underlay)网络的情况下,可以部署对网络拓扑有特定要求的应用:

img

overlay 虚拟化带来的好处包括:

  • 优化的设备功能:overlay 网络使得可以根据设备在网络中的位置不同而对设备进行 分类(和定制)。edge 或 leaf 设备可以根据终端状态信息和规模优化它的功能和相关 的协议;core 或 spine 设备可以根据链路状态优化它的功能和协议,以及针对快速收敛 进行优化。
  • fabric 的扩展性和灵活性:overlay 技术使得可以在 overlay 边界设备上进行网络 的扩展。当在 fabric 边界使用 overlay 时,spine 或 core 设备就无 需向自己的转发表中添加终端主机的信息(例如,如果在宿主机内进行 overlay 的封 装和解封装,那 overlay 边界就是在宿主机内部,译者注)。
  • 可重叠的寻址:数据中心中使用的大部分 overlay 技术都支持虚拟网络 ID,用来唯 一地对每个私有网络进行范围限定和识别(scope and identify)。这种限定使得不同租 户的 MAC 和 IP 地址可以重叠(overlapping)。overlay 的封装使得租户地址空间和 underlay 地址空间的管理分开。

四、IP Fabric

IP Fabric指的是在IP网络基础上建立起来的Overlay隧道技术。如下图,基于胖树的Spine+Leaf拓扑结构的IP Fabric组网图 img

在这种组网方式中,任何两台服务器间的通信不超过3台设备,每个Spine和Leaf节点全互连,可以方便地通过扩展Spine节点来实现网络规模的弹性扩展。只要遍历一定数量的交换机,可以在几乎所有数据中心结构体系中的服务器节点之间传输流量,该架构由多条高带宽的直接路径组成,消除了网络瓶颈带来的潜在传输速度下降,从而实现极高的转发效率和低延迟。

根据不同的业务需要,Spine和Leaf之间可以使用IP路由、VXLAN或TRILL等技术。

五、参考资料


【Calico系列】3 Calico的组件、架构与原理

本文是 Calico 系列的第三篇文章,继上一篇了解 BGP 的基本概念,这一篇真正进入 Calico 的笔记。本篇以 Calico 3.4 版本 为基准。

由于网络的水深与个人能力有限,本文不免存在错误之处。如有疑问,请查阅文末参考资料或与我线上/线下讨论。

目录:

  1. Calico架构
  2. Calico 数据路径——路由与iptables

一、Calico架构

img

  • Felix 跑在每个节点上,负责管理node;
  • Orchestrator plugin 适配不同架构的插件;
  • etcd 主要负责网络元数据一致性,确保Calico网络状态的准确性;
  • BGP Client (BIRD) 负责把 Felix 写入Kernel的路由信息 分发到整个 Calico网络;
  • BGP Route Reflector (BIRD) BGP路由反射器,大规模部署时使用,通过一个或者多个BGP Route Reflector来完成集中式的路由分发。

特别地,在 kubernetes 架构中,当 calico 作为策略和网络组件时,实际运行了两类容器:

$ kubectl get po -n kube-system |grep calico

calico-kube-controllers-5f6db94794-cmqs4      1/1       Running   1          74d
calico-node-k92qh                             1/1       Running   1          74d
calico-node-lt7sn                             1/1       Running   1          74d
calico-node-qh596                             1/1       Running   1          74d
calico-node-wt8n9                             1/1       Running   1          74d

在每个节点上运行的calico-node 的pod,pod 内部实际上运行了如下进程:

1579073471763

另外还有一个 kube-controller 的pod:

1579073508360

它们的具体作用后面的文章再做详细介绍.

Felix

Felix 负责最终网络相关的配置,也就是容器网络在 linux 上的配置工作,比如:

  • 更新节点上的路由表项
  • 更新节点上的 iptables 表项

它的主要工作是从 etcd 中读取网络的配置,然后根据配置更新节点的路由和 iptables,felix 的代码在 github projectcalico/felix

Orchestrator Plugin

不同的平台有不同的 plugin,例如 Kubernetes 有 Calico CNI,OpenStack 有 Calico Neutron ML2 mechanism driver,负责calico与各个平台的适配:

  • API 翻译
  • 返回 calico 的网络状态,比如felix探活、标记 endpoints 失败等。

Etcd

Etcd 是一个分布式的键值存储数据库,保存了 calico 网络元数据,用来协调 calico 网络多个节点:

  • 存储
  • 不同组件间交互数据

etcd每个目录保存的数据大致功能如下:

  • /calico/ipam:IP 地址分配管理,保存了节点上分配的各个子网段以及网段中 IP 地址的分配情况
  • /calico/v1:profile 和 policy 的配置信息,节点上运行的容器 endpoint 信息(IP 地址、veth pair interface 的名字等),
  • /calico/bgp:和 BGP 相关的信息,包括 mesh 是否开启,每个节点作为 gateway 通信的 IP 地址,AS number 等

BGP Client (BIRD)

BIRD(BIRD Internet Routing Daemon) 是一个常用的网络路由软件,支持很多路由协议(BGP、RIP、OSPF等),calico 用它在节点之间共享路由信息。

Calico 会在所有跑 Felix 节点部署一个 BGP Client。BGP client 會读取 Felix 在 kernel 中的设定,并将其共享到其他节点。

关于 BIRD 如何配置 BGP 协议,可以参考官方文档

BGP route reflector (BIRD)

全互联模式(full mesh)会造成路由条目过大,无法在大规模集群中部署。使用BGP RR(中心化)的方式交换路由,能够有效降低节点间的连接数。

二、Calico 数据路径——路由与iptables

Calico datapath


1 2 3 4 5 6 92 93 94 95 96