配置集群的时候需要用到共享磁盘。如果要用VMware ESXi虚拟机做测试，可以为虚拟机创建共享磁盘。下面通过示例介绍。

（1）新建两台虚拟机A1、A2，最初虚拟机A1、A2各有一块磁盘，大小为60GB，用来安装操作系统。也可以直接从模板部署两台安装好操作系统的虚拟机，这可根据实际情况选择。

（2）修改A1虚拟机配置，添加2块新硬盘（厚置备磁盘），大小分别为1GB、500GB（其他大小也可以，根据实际情况创建即可）。

（3）修改A2虚拟机配置，添加第（2）步创建的两块硬盘，修改虚拟机配置，允许使用虚拟硬盘。

（4）配置群集，使用共享磁盘。

下面介绍关键的配置步骤，本文以vSphere 6.5为例。

（1）在Windows 7的管理工作站中使用IE 11登录vSphere Web Client 6.5，选择配置好的Windows Server 2016模板部署虚拟机，如图1所示。

![在vSphere中为虚拟机创建共享磁盘_共享存储](http://pic.nexopera.tech/639816feaca5c.png)



图1 从模板部署虚拟机

（2）为该虚拟机输入名称，在本示例虚拟机名称为WS16R2-A1，在“选择计算资源”对话框，为此虚拟机选择目标计算资源，在“选择存储”对话框，为此虚拟机选择要存储配置和磁盘文件的数据存储。

（3）在“选择克隆选项”对话框选择“自定义操作系统”、“创建后打开虚拟机电源”对话框，在“自定义客户机操作系统”对话框选择规范文件，在“用户设置”对话框中设置计算机名称，在此命名为ServerA，如图2所示。

（4）在“即将完成”对话框中显示了部署选项，检查无误之后单击“完成”按钮，完成虚拟机的创建。

![在vSphere中为虚拟机创建共享磁盘_共享存储_02](http://pic.nexopera.tech/639816fe9fa0f.png)



图2 设置计算机名称

（5）参照（1）～（4）的步骤从模板部署第二台虚拟机，设置虚拟机名称为WS16R2-A2，这些不再介绍。

（6）启动这两台虚拟机，等系统定制完成之后，关闭这两台虚拟机的电源。

（7）等虚拟机关闭之后，修改第一台虚拟机（名称为WS16R2-A1）的配置，分别添加1块或多块磁盘。本示例中添加1块1GB和1块500GB大小的虚拟硬盘（1GB用作仲裁磁盘。实际上在Windows Server 2016中做故障转移群集不需要仲裁磁盘），如图3所示，磁盘置备选择“厚置备置零”。

（8）检查“硬盘1”的虚拟设备节点属性，默认情况下，硬盘1使用SCSI控制器0的“SCSI(0:0)”节点。

![在vSphere中为虚拟机创建共享磁盘_vSphere_03](http://pic.nexopera.tech/639816fe9c664.png)



图3 厚置备置零磁盘 

（9）在“新设备”下拉列表中选择“SCSI控制器”，SCSI总线共享为“虚拟”。

（10）修改1GB硬盘使用新添加的SCSI控制器，在“虚拟设备节点”下拉列表中选择“新SCSI控制器”，SCSI选择1:0，如图4所示。



![在vSphere中为虚拟机创建共享磁盘_RAC_04](http://pic.nexopera.tech/639816fea4db0.png)



图4 为1GB选择SCSI（1：0）

（11）修改500GB硬盘使用“新SCSI控制器”“SCSI（1：1）”。设置完成后单击“确定”按钮保存退出。

（12）修改WS16R2-A2虚拟机的设置，添加“SCSI控制器”，在“SCSI总线共享”下拉列表中选择“虚拟”。

（13）修改WS16R2-A2虚拟机的设置，添加硬盘选择“现有硬盘”，在“选择文件”对话框浏览选择WS16R2-A1虚拟机目录中的WS16R2-A1_1.vmdk虚拟硬盘文件，这是在WS16R2-A1虚拟机添加的大小为1GB的虚拟硬盘，如图5所示。



![在vSphere中为虚拟机创建共享磁盘_vSphere_05](http://pic.nexopera.tech/639816fe91860.png)



图5 选择WS16R2-A1_1.vmdk虚拟硬盘文件

（14）返回WS16R2-A2虚拟机设置对话框，添加了大小为1GB的现有硬盘文件，在“虚拟设备节点”选择“新SCSI控制器”“SCSI（1：0）”，为WS16R2-A2虚拟机添加现有硬盘，选择WS16R2-A1目录中的WS16R2-A1_2.vmdk文件。

（15）返回WS16R2-A2虚拟机设置对话框，添加了大小为500GB的现有硬盘文件，在“虚拟设备节点”选择“新SCSI控制器”“SCSI（1：1）”，确认“SCSI控制器0”的“SCSI总线共享”为无，“SCSI控制器1”的“SCSI总线共享”为“虚拟”，如图6所示。单击“确定”按钮完成设置。



![在vSphere中为虚拟机创建共享磁盘_共享存储_06](http://pic.nexopera.tech/639816fe8d7ca.png)



图6 检查确认SCSI总线共享属性

（16）启动WS16R2-A1、WS16R2-A2虚拟机，启动时无报错表示设置正确。

当WS16R2-A1、WS16R2-A2两台虚拟机启动之后，可以做“共享磁盘”的实验。本节以“故障转移群集为例”，主要步骤如下。

（1）打开任意一台虚拟机的“计算机管理→存储→磁盘管理”，可以看到有两块新的磁盘，如图7所示。应将这两个磁盘联机、初始化、分区并使用NTFS文件系统格式化。

![在vSphere中为虚拟机创建共享磁盘_共享存储_07](http://pic.nexopera.tech/639816ffd07d6.png)



图7 新添加的磁盘

（2）为两台虚拟机设置IP地址，本示例中为WS16R2-A1虚拟机设置172.18.96.58的IP地址，为WS16R2-A2虚拟机设置172.18.96.59的IP地址。

（3）为两台虚拟机编辑c:\windows\system32\drivers\etc\hosts文件，添加如下两行。

172.18.96.58 servera

172.18.96.59 serverb

（4）为这两台虚拟机安装“故障转移群集”功能，安装完成故障转移群集之后，打开“故障转移群集管理器”，新建群集，添加ServerA和ServerB两台服务器，如图8所示。



![在vSphere中为虚拟机创建共享磁盘_RAC_08](http://pic.nexopera.tech/639816ffd27c3.png)



图8 添加群集服务器

（5）在“验证警告”对话框单击“是”按钮，在“测试选项”对话框单击“运行所有测试”。

（6）在“用于管理群集的访问点”对话框输入群集名称并设置群集的访问地址，在本示例中设置群集访问地址为172.18.96.57，如图9所示。在“摘要”对话框中单击“完成”按钮完成群集的创建。

![在vSphere中为虚拟机创建共享磁盘_Oracle_09](http://pic.nexopera.tech/6398170008cd0.png)



图9设置群集名称和访问地址

（7）在“存储→磁盘”中添加磁盘，然后将添加的磁盘转换为“群集共享卷”，如图10所示。



![在vSphere中为虚拟机创建共享磁盘_vSphere_10](http://pic.nexopera.tech/6398170043ead.png)



图10 群集共享卷

（8）打开“资源管理器”，在C盘的ClusterStorage中可以看到2个目录，分别名为Volume1及Volume2，这就是两块共享磁盘对应的访问点。

关于群集的使用以及其他的配置，本文不做过多介绍。


在vSphere中为虚拟机创建共享磁盘



### **前言**

  Cron 表达式，是应用在 Unix 和类 Unix 操作系统之中，让脚本、任务定时进行周期性重复的执行。Cron 表达式有着丰富的表达能力，能够适应各种时间表达需求。本页整理了一些基本语法和常用样例，供大家参考。



#### **Cron 是什么？**

  首先在了解 cron 表达式之前，先谈谈 crontab 定时任务；日常在开发或运维中，经常遇到一些周期性执行的任务或需求，比如说，每隔一段时间执行一个脚本，每周一执行一个命令或操作。而 linux 已经给我们提供了一个便捷的方式 -- crontab 定时任务；crontab 就是一个自定义定时器，我们可以利用 crontab 命令在固定的间隔时间执行指定的系统指令或 shell script 脚本。而这个时间间隔的写法与我们平常用到的 cron 表达式相似。作用都是通过利用字符或命令去设置定时周期性地执行一些操作。

  我们可以将 cron 表达式看作一个以 5 或 6 个字符串空格隔开的字符串。这个 5 或 6 个空格将字符串划分为 6 或 7 个域，每个域代表着不同的含义。默认从左到右为：" `秒 分 小时 日 月 星期几 年份` "。



![image-20220721143613775](http://pic.nexopera.tech/62d8f3de2cfe3.png)



| 域   | 字段         | 含义         | 范围或通配符                                                 | 必填 |
| ---- | ------------ | ------------ | ------------------------------------------------------------ | ---- |
| 秒   | Seconds      | 秒           | `0-59` 或 `,-*/`                                             | 是   |
| 分   | Minutes      | 分钟         | `0-59` 或 `,-*/`                                             | 是   |
| 时   | Hours        | 小时         | `0-23` 或 `,-*/`                                             | 是   |
| 日   | Day-of-Month | 日期         | `1-31` 或 `,-*?/LW`                                          | 是   |
| 月   | Month        | 月份         | `1-12` （或 `JAN-DEC`）或者 `,- * /`                         | 是   |
| 星期 | Day-of-Week  | 每星期的周几 | `1-7`（或 `SUN`，`MON`，`TUE`，`WED`，`THU`，`FRI`，`SAT`）或者 `, - * ? / L #` | 是   |
| 年   | Year         | 年份         | `1970-2099` 或 `- * /`                                       | 否   |



**例子**

- 每天中午12点触发

```
0 0 12 * * ?
```



- 每天上午10:15触发

```
0 15 10 ? * *
```



- 每天上午10:15触发

```
0 15 10 * * ?
```



- 每天上午10:15触发

```
0 15 10 * * ? *
```



- 2005年的每天上午10:15触发

```
0 15 10 * * ? 2005
```



- 在每天下午2点到下午2:59期间的每1分钟触发

```
0 * 14 * * ?
```



- 在每天下午2点到下午2:55期间的每5分钟触发

```
0 0/5 14 * * ?
```



- 在每天下午2点到2:55期间和下午6点到6:55期间的每5分钟触发

```
0 0/5 14,18 * * ?
```



- 在每天下午2点到下午2:05期间的每1分钟触发

```
0 0-5 14 * * ?
```



- 每年三月的星期三的下午2:10和2:44触发

```
0 10,44 14 ? 3 WED
```



- 周一至周五的上午10:15触发

```
0 15 10 ? * MON-FRI
```



- 每月15日上午10:15触发

```
0 15 10 15 * ?
```



- 每月最后一日的上午10:15触发

```
0 15 10 L * ?
```



- 每月的最后一个星期五上午10:15触发 

```
0 15 10 ? * 6L
```



- 2002年至2005年的每月的最后一个星期五上午10:15触发

```
0 15 10 ? * 6L 2002-2005
```



- 每月的第三个星期五上午10:15触发

```
0 15 10 ? * 6#3
```



**详解**

- `,`：表示列出**枚举值**。如在月中的值为 `1，3`, 则表示一月份和 3 月份都触发事件。

- `*`：表示匹配该域**任意值**，如小时的字段为 `*` 时，表示每一小时都触发事件

- `?`：表示**不指定值**，用于日期和星期字段之间进行`互斥`。通常在日期和星期字段中的一个指定值，另外一个用 `?` 表示不指定值。个人理解就是忽略该字段的值，直接根据另外一个字段的值进行执行。比如说：日期为 `2`，则星期应为 `?`;

- `-`：表示**范围，一个连续触发的区间**。如：时的值为 `9-12`，则表示 9-12 小时中的每个小时都触发事件。

- `/`：表示**间隔时间触发事件（开始时间 / 时间间隔）**。如：在分钟值为 `0/15`，则表示从 0 分开始，每隔 15 分钟触发一遍事件。

- `#`：表示**该月第 n 个星期 x (x#n)**，仅用星期域。如：星期：`6#3`，表示该月的第三个星期五。

- `L`：表示**最后（最后一天或最后一个星期几）**；仅出现在日和星期的域中。用在日则表示该月的最后一天，用在星期则表示该月的最后一个星期 X。如：星期域上的值为 5L，则表示该月最后一个星期的星期四。在使用`'L'` 时，不要指定列表`','` 或范围`'-'`，否则易导致出现意料之外的结果。

- `W`：仅用在日的域中，表示距离当月给定日期最近的工作日（周一到周五）。

  如：`"4W"` 表示距离 4 号最近的工作日（**当月的**）触发事件；（1）当 4 号就是工作日时，则表示当天触发；当 4 号为周六时，则表示 3 号（周五）触发；（2）当 4 号为周日时，则表示在 5 号（周一）触发；再如：`"1W"` 表示距离 1 号最近的工作日触发事件，但是，**该工作日只算当月的**。假如当月 1 号是周六，则 "`1W`" 表示在当月 3 号（周一）触发事件。就算上个月的最后一天是工作日，也不会触发事件。

- `LW`：`‘L’`和`'W'` 可以一起组合在日字段使用。表示当月的最后一个工作日触发事件。

Cron表达式详解

![Linux服务之AutoFs挂载服务](http://pic.nexopera.tech/62f5c83bb306f.jpg)

**Linux服务之AutoFs挂载服务**

------

无论是`Samba`服务还是`NFS`服务，都要把挂载信息写入到`/etc/fstab`中，这样远程共享资源就会自动随服务器开机而进行挂载。虽然这很方便，但是如果挂载的远程资源太多，则会给网络带宽和服务器的硬件资源带来很大负载。如果在资源挂载后长期不使用，也会造成服务器硬件资源的浪费。可能会有读者说，可以在每次使用之前执行`mount`命令进行手动挂载。这是一个不错的选择，但是每次都需要先挂载再使用，您不觉得麻烦吗？

`autofs`自动挂载服务可以帮我们解决这一问题。与`mount`命令不同，`autofs`服务程序是一种`Linux`系统守护进程，当检测到用户试图访问一个尚未挂载的文件系统时，将自动挂载该文件系统。换句话说，我们将挂载信息填入`/etc/fstab`文件后，系统在每次开机时都自动将其挂载，而`autofs`服务程序则是在用户需要使用该文件系统时才去动态挂载，从而节约了网络资源和服务器的硬件资源。

```bash
[root@localhost ~]# yum install autofs
Loaded plugins: langpacks, product-id, subscription-manager
......
Running transaction
Installing : hesiod-3.2.1-3.el7.x86_64 1/2
Installing : 1:autofs-5.0.7-40.el7.x86_64 2/2
Verifying : hesiod-3.2.1-3.el7.x86_64 1/2
Verifying : 1:autofs-5.0.7-40.el7.x86_64 2/2
Installed:
autofs.x86_64 1:5.0.7-40.el7
Dependency Installed:
hesiod.x86_64 0:3.2.1-3.el7
Complete!
```

处于生产环境中的`Linux`服务器，一般会同时管理许多设备的挂载操作。如果把这些设备挂载信息都写入到`autofs`服务的主配置文件中，无疑会让主配置文件臃肿不堪，不利于服务执行效率，也不利于日后修改里面的配置内容，因此在 autofs 服务程序的主配置文件中需要按照**“挂载目录 子配置文件”**的格式进行填写。挂载目录是设备挂载位置的上一级目录。

例如，光盘设备一般挂载到`/media/cdrom`目录中，那么挂载目录写成`/media`即可。对应的子配置文件则是对这个挂载目录内的挂载设备信息作进一步的说明。子配置文件需要用户自行定义，文件名字没有严格要求，但后缀必须以`.misc`结束。具体的配置参数如第`7`行的加粗字所示。

```bash
[root@localhost ~]# vim /etc/auto.master
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
/media /etc/iso.misc
/misc /etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
# "nosuid" and "nodev" options unless the "suid" and "dev"
# options are explicitly given.
/net -hosts
#
# Include /etc/auto.master.d/*.autofs
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
+auto.master
```

在子配置文件中，应按照**“挂载目录 挂载文件类型及权限 :设备名称”**的格式进行填写。例如，要把光盘设备挂载到`/media/iso`目录中，可将挂载目录写为`iso`，而`-fstype`为文件系统格式参数，`iso9660`为光盘设备格式，`ro`、`nosuid`及`nodev`为光盘设备具体的权限参数，`/dev/cdrom`则是定义要挂载的设备名称。配置完成后再顺手将`autofs`服务程序启动并加入到系统启动项中：

```bash
[root@localhost ~]# vim /etc/iso.misc
iso   -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom

[root@localhost ~]# systemctl start autofs
[root@localhost ~]# systemctl enable autofs
ln -s '/usr/lib/systemd/system/autofs.service' '/etc/systemd/system/multi-user.target.wants/autofs.service'
```

接下来将发生一件非常有趣的事情。我们先查看当前的光盘设备挂载情况，确认光盘设备没有被挂载上，而且`/media`目录中根本就没有`iso`子目录。但是，我们却可以使用`cd`命令切换到这个`iso`子目录中，而且光盘设备会被立即自动挂载上。我们也就能顺利查看光盘内的内容了。

```bash
[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rhel-root 18G 3.0G 15G 17% /
devtmpfs 905M 0 905M 0% /dev
tmpfs 914M 140K 914M 1% /dev/shm
tmpfs 914M 8.9M 905M 1% /run
tmpfs 914M 0 914M 0% /sys/fs/cgroup
/dev/sda1 497M 119M 379M 24% /boot
[root@linuxprobe ~]# cd /media

[root@localhost media]# ls
[root@localhost media]# cd iso

[root@localhost iso]# ls -l
total 812
dr-xr-xr-x. 4 root root 2048 May 7 2017 addons
dr-xr-xr-x. 3 root root 2048 May 7 2017 EFI
-r--r--r--. 1 root root 8266 Apr 4 2017 EULA
-r--r--r--. 1 root root 18092 Mar 6 2012 GPL
dr-xr-xr-x. 3 root root 2048 May 7 2017 images
dr-xr-xr-x. 2 root root 2048 May 7 2017 isolinux
dr-xr-xr-x. 2 root root 2048 May 7 2017 LiveOS
-r--r--r--. 1 root root 108 May 7 2017 media.repo
dr-xr-xr-x. 2 root root 774144 May 7 2017 Packages
dr-xr-xr-x. 24 root root 6144 May 7 2017 release-notes
dr-xr-xr-x. 2 root root 4096 May 7 2017 repodata
-r--r--r--. 1 root root 3375 Apr 1 2017 RPM-GPG-KEY-redhat-beta
-r--r--r--. 1 root root 3211 Apr 1 2017 RPM-GPG-KEY-redhat-release
-r--r--r--. 1 root root 1568 May 7 2017 TRANS.TBL
```

```bash
[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rhel-root 18G 3.0G 15G 17% /
devtmpfs 905M 0 905M 0% /dev
tmpfs 914M 140K 914M 1% /dev/shm
tmpfs 914M 8.9M 905M 1% /run
tmpfs 914M 0 914M 0% /sys/fs/cgroup
/dev/cdrom 3.5G 3.5G 0 100% /media/iso
/dev/sda1 497M 119M 379M 24% /boot
```


Linux服务之AutoFs挂载服务

### 前言

 在对公司容器云的日志方案进行设计的时候，发现主流的 ELK (Elasticsearch, Logstash, Kibana) 或者 EFK (Elasticsearch, Filebeat or Fluentd, Kibana) 比较重，再加上现阶段对于 ES 复杂的搜索功能很多都用不上，最终选择了 Grafana 开源的 Loki 日志系统。下面我们来介绍下 Loki 的一些基本概念和架构，当然 EFK 作为业界成熟的日志聚合解决方案也是大家应该需要熟悉和掌握的;

### 简介

 Loki 是 Grafana Labs 团队最新的开源项目，是一个水平可扩展，高可用性，多租户的日志聚合系统。它的设计非常经济高效且易于操作，因为它不会为日志内容编制索引，而是为每个日志流编制一组标签，专门为 Prometheus 和 Kubernetes 用户做了相关优化。该项目受 Prometheus 启发，官方的介绍就是： Like Prometheus,But For Logs.，类似于 Prometheus 的日志系统;

项目地址：https://github.com/grafana/loki/
​

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

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

### 架构说明

![img](http://pic.nexopera.tech/1871335-20210618165258336-1222022683.png)

#### 组件说明

**Promtail 作为采集器,类比filebeat**



**loki相当于服务端,类比es**



**loki进程包含四种角色**
**querier 查询器**
**inester 日志存储器**
**query-frontend 前置查询器**
**distributor 写入分发器**

可以通过loki二进制的 -target 参数指定运行角色
​

#### read path

查询器接受HTTP/1 数据请求
查询器将查询传递给所有ingesters请求内存中的数据
接收器接受读取的请求,并返回与查询匹配的数据(如果有)
如果没有接受者返回数据, 则查询器会从后备存储中延迟加载数据并对其执行查询;
查询器将迭代所有接收到的数据并进行重复数据删除, 从而通过HTTP/1连接返回最终数据集;

#### write path

![img](http://pic.nexopera.tech/1871335-20210618165310711-2146766392.png)

分发服务器收到一个HTTP/1请求,以存储流数据;
每个流都使用散列环散列;
分发程序将每个流发送到适当的inester和其副本(基于配置的复制因子);
每个实例将为流的数据创建一个块或将其追加到现有块中, 每个租户和每个标签集的块都是唯一的;
分发服务器通过HTTP/1链接以成功代码作为响应;
​

### 部署

#### 本地化模式安装

##### 下载promtail和loki二进制

```
wget  https://github.com/grafana/loki/releases/download/v2.2.1/loki-linux-amd64.zip
wget https://github.com/grafana/loki/releases/download/v2.2.1/promtail-linux-amd64.zip
```

##### 安装promtail

```
$ mkdir /opt/app/{promtail,loki} -pv

# promtail配置文件
$ cat <<EOF> /opt/app/promtail/promtail.yaml
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /var/log/positions.yaml # This location needs to be writeable by promtail.

client:
  url: http://localhost:3100/loki/api/v1/push

scrape_configs:
 - job_name: system
   pipeline_stages:
   static_configs:
   - targets:
      - localhost
     labels:
      job: varlogs
      host: yourhost
      __path__: /var/log/*.log
EOF
  
# 解压安装包
unzip promtail-linux-amd64.zip
mv promtail-linux-amd64 /opt/app/promtail/promtail

# service文件
$ cat <<EOF >/etc/systemd/system/promtail.service
[Unit]
Description=promtail server
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/opt/app/promtail/promtail -config.file=/opt/app/promtail/promtail.yaml
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=promtail
[Install]
WantedBy=default.target
EOF
  
systemctl daemon-reload
systemctl restart promtail
systemctl status promtail
```

##### 安装loki

```
$ mkdir /opt/app/{promtail,loki} -pv

# promtail配置文件
$ cat <<EOF> /opt/app/loki/loki.yaml
auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096

ingester:
  wal:
    enabled: true
    dir: /opt/app/loki/wal
  lifecycler:
    address: 127.0.0.1
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1
    final_sleep: 0s
  chunk_idle_period: 1h       # Any chunk not receiving new logs in this time will be flushed
  max_chunk_age: 1h           # All chunks will be flushed when they hit this age, default is 1h
  chunk_target_size: 1048576  # Loki will attempt to build chunks up to 1.5MB, flushing first if chunk_idle_period or max_chunk_age is reached first
  chunk_retain_period: 30s    # Must be greater than index read cache TTL if using an index cache (Default index read cache TTL is 5m)
  max_transfer_retries: 0     # Chunk transfers disabled

schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

storage_config:
  boltdb_shipper:
    active_index_directory: /opt/app/loki/boltdb-shipper-active
    cache_location: /opt/app/loki/boltdb-shipper-cache
    cache_ttl: 24h         # Can be increased for faster performance over longer query periods, uses more disk space
    shared_store: filesystem
  filesystem:
    directory: /opt/app/loki/chunks

compactor:
  working_directory: /opt/app/loki/boltdb-shipper-compactor
  shared_store: filesystem

limits_config:
  reject_old_samples: true
  reject_old_samples_max_age: 168h

chunk_store_config:
  max_look_back_period: 0s

table_manager:
  retention_deletes_enabled: false
  retention_period: 0s


ruler:
  storage:
    type: local
    local:
      directory: /opt/app/loki/rules
  rule_path: /opt/app/loki/rules-temp
  alertmanager_url: http://localhost:9093
  ring:
    kvstore:
      store: inmemory
  enable_api: true
EOF

# 解压包
unzip loki-linux-amd64.zip 
mv loki-linux-amd64 /opt/app/loki/loki
      
# service文件

$ cat <<EOF >/etc/systemd/system/loki.service
[Unit]
Description=loki server
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/opt/app/loki/loki -config.file=/opt/app/loki/loki.yaml
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=loki
[Install]
WantedBy=default.target
EOF

systemctl daemon-reload
systemctl restart loki
systemctl status loki
```

### 使用

#### grafana上配置loki数据源

![img](http://pic.nexopera.tech/1871335-20210618165321171-1216234508.png)

grafana-loki-dashsource
在数据源列表中选择 Loki，配置 Loki 源地址：

![img](http://pic.nexopera.tech/1871335-20210618165332738-1807986028.png)

grafana-loki-dashsource-config
源地址配置 [http://loki:3100](http://loki:3100/) 即可，保存。
保存完成后，切换到 grafana 左侧区域的 Explore，即可进入到 Loki 的页面

![img](http://pic.nexopera.tech/1871335-20210618165344770-591040125.png)

grafana-loki
然后我们点击 Log labels 就可以把当前系统采集的日志标签给显示出来，可以根据这些标签进行日志的过滤查询：
![img](http://pic.nexopera.tech/1871335-20210618165408795-395363757.png)

grafana-loki-log-labels
比如我们这里选择 /var/log/messages，就会把该文件下面的日志过滤展示出来，不过由于时区的问题，可能还需要设置下时间才可以看到数据:

![img](http://pic.nexopera.tech/1871335-20210618165420576-583363230.png)

s

grafana-loki-logs
这里展示的是 promtail 容器里面 / var/log 目录中的日志
promtail 容器 / etc/promtail/config.yml
​



```
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

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

scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log
```

这里的 job 就是 varlog，文件路径就是 / var/log/*log
​

#### 在grafana explore上配置查看日志

```
查看日志 rate({job="message"} |="kubelet"
```

**算 qps rate({job="message"} |="kubelet" [1m])**

#### 只索引标签

之前多次提到 loki 和 es 最大的不同是 loki 只对标签进行索引而不对内容索引 下面我们举例来看下

#### **静态标签匹配模式**

以简单的 promtail 配置举例

配置解读

```
scrape_configs:
 - job_name: system
   pipeline_stages:
   static_configs:
   - targets:
      - localhost
     labels:
      job: message
      __path__: /var/log/messages
```

- 上面这段配置代表启动一个日志采集任务
- 这个任务有 1 个固定标签job="syslog"
- 采集日志路径为 /var/log/messages , 会以一个名为 filename 的固定标签
- 在 promtail 的 web 页面上可以看到类似 prometheus 的 target 信息页面

**可以和使用prometheus一样的标签匹配语句进行查询**
**​**

{job="syslog"}



```
scrape_configs:
 - job_name: system
   pipeline_stages:
   static_configs:
   - targets:
      - localhost
     labels:
      job: syslog
      __path__: /var/log/syslog
 - job_name: system
   pipeline_stages:
   static_configs:
   - targets:
      - localhost
     labels:
      job: apache
      __path__: /var/log/apache.log
```

- 如果我们配置了两个 job，则可以使用{job=~”apache|syslog”} 进行多 job 匹配
- 同时也支持正则和正则非匹配

#### 标签匹配模式的特点

------

**原理**

- 和 prometheus 一致，相同标签对应的是一个流 prometheus 处理 series 的模式
- prometheus 中标签一致对应的同一个 hash 值和 refid(正整数递增的 id)，也就是同一个 series
- 时序数据不断的 append 追加到这个 memseries 中
- 当有任意标签发生变化时会产生新的 hash 值和 refid，对应新的 series

loki 处理日志的模式 - 和 prometheus 一致，loki 一组标签值会生成一个 stream - 日志随着时间的递增会追加到这个 stream 中，最后压缩为 chunk - 当有任意标签发生变化时会产生新的 hash 值，对应新的 stream

**查询过程**

- 所以 loki 先根据标签算出 hash 值在倒排索引中找到对应的 chunk?
- 然后再根据查询语句中的关键词等进行过滤，这样能大大的提速
- 因为这种根据标签算哈希在倒排中查找 id，对应找到存储的块在 prometheus 中已经被验证过了
- 属于开销低
- 速度快

#### 动态标签和高基数

所以有了上述知识，那么就得谈谈动态标签的问题了

**两个概念**
何为动态标签：说白了就是标签的 value 不固定
何为高基数标签：说白了就是标签的 value 可能性太多了，达到 10 万，100 万甚至更多

**比如 apache 的 access 日志**

```
11.11.11.11 - frank [25/Jan/2000:14:00:01 -0500] "GET /1986.js HTTP/1.1" 200 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
```

**在promtail中使用regex想要匹配action和status_code两个标签**

```
scrape_configs:
 - job_name: system
   pipeline_stages:
   static_configs:
   - targets:
      - localhost
     labels:
      job: syslog
      __path__: /var/log/syslog
 - job_name: system
   pipeline_stages:
   static_configs:
   - targets:
      - localhost
     labels:
      job: apache
      __path__: /var/log/apache.log

  - job_name: system
    pipeline_stages:
       - regex:
         expression: "^(?P<ip>\\S+) (?P<identd>\\S+) (?P<user>\\S+) \\[(?P<timestamp>[\\w:/]+\\s[+\\-]\\d{4})\\] \"(?P<action>\\S+)\\s?(?P<path>\\S+)?\\s?(?P<protocol>\\S+)?\" (?P<status_code>\\d{3}|-) (?P<size>\\d+|-)\\s?\"?(?P<referer>[^\"]*)\"?\\s?\"?(?P<useragent>[^\"]*)?\"?$"
     - labels:
         action:
         status_code:
    static_configs:
    - targets:
       - localhost
      labels:
       job: apache
       env: dev
       __path__: /var/log/apache.log
```

- 那么对应 action=get/post 和 status_code=200/400 则对应 4 个流

```
11.11.11.11 - frank [25/Jan/2000:14:00:01 -0500] "GET /1986.js HTTP/1.1" 200 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
11.11.11.12 - frank [25/Jan/2000:14:00:02 -0500] "POST /1986.js HTTP/1.1" 200 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
11.11.11.13 - frank [25/Jan/2000:14:00:03 -0500] "GET /1986.js HTTP/1.1" 400 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
11.11.11.14 - frank [25/Jan/2000:14:00:04 -0500] "POST /1986.js HTTP/1.1" 400 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
```

- 那四个日志行将变成四个单独的流，并开始填充四个单独的块。
- 如果出现另一个独特的标签组合（例如 status_code =“500”），则会创建另一个新流

**高基数问题**

- 就像上面，如果给 ip 设置一个标签，现在想象一下，如果您为设置了标签 ip，来自用户的每个不同的 ip 请求不仅成为唯一的流
- 可以快速生成成千上万的流，这是高基数，这可以杀死 Loki

如果字段没有被当做标签被索引,会不会查询很慢
Loki 的超级能力是将查询分解为小块并并行分发，以便您可以在短时间内查询大量日志数据

#### 全文索引问题

- 大索引既复杂又昂贵。通常，日志数据的全文索引的大小等于或大于日志数据本身的大小
- 要查询日志数据，需要加载此索引，并且为了提高性能，它可能应该在内存中。这很难扩展，并且随着您摄入更多日志，索引会迅速变大。
- Loki 的索引通常比摄取的日志量小一个数量级，索引的增长非常缓慢

**加速查询没标签字段**

以上边提到的 ip 字段为例 - 使用过滤器表达式查询

```
{job="apache"} |= "11.11.11.11"
```

**loki查询时的分片(按时间范围分段grep)**

- Loki 将把查询分解成较小的分片，并为与标签匹配的流打开每个区块，并开始寻找该 IP 地址。
- 这些分片的大小和并行化的数量是可配置的，并取决于您提供的资源
- 如果需要，您可以将分片间隔配置为 5m，部署 20 个查询器，并在几秒钟内处理千兆字节的日志
- 或者，您可以发疯并设置 200 个查询器并处理 TB 的日志！

**两种索引模式对比**

- es 的大索引，不管你查不查询，他都必须时刻存在。比如长时间占用过多的内存
- loki 的逻辑是查询时再启动多个分段并行查询

**日志量少时少加标签**

- 因为每多加载一个 chunk 就有额外的开销
- 举例 如果该查询是 {app="loki",level!="debug"}
- 在没加 level 标签的情况下只需加载一个 chunk 即 app="loki" 的标签
- 如果加了 level 的情况，则需要把 level=info,warn,error,critical 5 个 chunk 都加载再查询

**需要标签时再去添加**

- 当 chunk_target_size=1MB 时代表 以 1MB 的压缩大小来切割块
- 对应的原始日志大小在 5MB-10MB，如果日志在 max_chunk_age 时间内能达到 10MB，考虑添加标签

**日志应当按时间递增**

- 这个问题和 tsdb 中处理旧数据是一样的道理
- 目前 loki 为了性能考虑直接拒绝掉旧数据


轻量化日志 Loki 全攻略

30分钟精通Git

Nexopera是一个专注于Linux、网络和运维等领域的博客网站。将为读者提供广泛的相关文章，涵盖操作系统、服务器管理、网络配置、安全性等多个主题。如果你是初学者，希望这里有适合你的内容。

前言

前言

一、版本控制工具

1.1. 什么是版本控制系统？

前言

前言

一、 版本控制工具

1.1. 什么是版本控制系统？

一、版本控制工具