.. _loki_startup:

==========================
Loki日志聚合系统快速起步
==========================

Loki是受 :ref:`prometheus` 启发的水平可扩展、高可用、多租户日志聚合系统。Loki的设计非常经济高效且易于操作。

**Loki 不索引日志的内容，而是为每个日志流建立一组标签** 这意味着不能实现灵活的全文搜索(相比较 :ref:`elasticsearch` )，但是带来了高效率的数据存储(占用极少的磁盘空间)以及适合预知查询组合方式(标签查询)的快速日志搜索。

Loki 日志聚合系统是 :ref:`grafana` Labs于 2018年开发的平台，具备以下优点:

- 非常容易集成到Kubernetes集群和 :ref:`prometheus` + :ref:`grafana` (可视化展示)
- 可以采集任何格式的日志
- 运行成本低: 存储数据少且写入快速，索引占用空间也很小，能够实现快速查询

工作原理
===========

.. figure:: ../../../_static/kubernetes/monitor/loki/logs-loki-diagram.svg

- 使用 ``Promtail`` 作为日志采集器: 结合Prometheus的 :ref:`prometheus_service_discovery` 以及类似功能，实现在存储到Loki之前就完成日志的标签(labeling), 转换(transforming) 和 过滤(filtering)
- 在 ``Loki`` 中存储日志: **Loki不对日志文本进行索引** ! 相反，存储对象是直接在数据流中进行分组 并且 使用标签(labels)进行索引。这意味着降低成本，也意味着能够实现毫秒级的查询
- 使用 ``LogQL`` 查询语言: 在 :ref:`grafana` 中剋直接使用 ``LogQL`` 查询和可视化日志，也可以使用 ``LogCLI`` 实现命令行功能
- 基于日志告警: 在输入的日志数据上可以通过 ``Loki`` 设置告警，告警可以发送给 :ref:`alertmanager` 路由给合适的处理团队

典型的Loki日志软件栈包括以下3个组件:

- Agent: 也就是 ``Promtail`` ，负责抓取日志，通过添加标签和通过一个Loki的HTTP API将日志流化并推送到Loki
- Loki: 主要服务器负责日志存储以及处理查询(有3种不同部署模式)
- :ref:`grafana` : 查询和显示日志数据，也可以通过 ``LogCLI`` 命令行查询日志

特点
=======

- Loki是受 :ref:`prometheus` 启发的水平可扩展、高可用、多租户的日志聚合系统
- Loki与Prometheus的区别在于: Loki关注日志而不是metrics，Loki通过推送而不是拉取来收集日志(主流的日志采集系统都是这样)
- Loki设计经济高效且高度可扩展: 与其他日志系统不同(例如 :ref:`elasticsearch` )，Loki不对日志内容索引，而只对日志的元数据索引，作为每个日志流的一组标签
- 日志流(log stream)是一组共享相同标签的日志: 标签帮助Loki在数据存储中找到日志流，所以拥有高质量的标签是高效执行查询的关键

.. note::

   我理解Loki的日志标签类似于关系型数据库的表结构，预先创建好Label就相当于数据库的字段，就能够根据字段(标签)进行查询

   优点是存储空间占用小，查询迅速。

   缺点是只有预先知道(设置)的标签才能提供查询，难以适应千变万化的日志查询需求

- 日志数据被压缩以块的形式存储在对象存储中，例如 Amazon Simple Storage Service (S3) 或 Google Cloud Storage (GCS) ，甚至可以为了开发或概念验证存储在文件系统中
- 小索引和高度压缩的块简化了操作并显著降低了Loki的成本

.. note::

   日志存储在S3或GCS云存储中，表明Loki更适合部署在特定的云计算服务商平台，实际上这也显示了Loki的定位，就是基于云计算(厂商)部署，为了节约云计算费用，舍弃了高级的日志内容索引，而针对特定查询场景进行优化(很多初级用户可能只需要基础的特定查询)可以极大降低运营成本。