Loki-distributed是Loki的分布式部署模式，包含多个组件：Distributor、Ingester、Query Frontend、Querier等。每个组件的作用需要理清楚。比如Distributor负责接收日志，验证并分发到Ingester；Ingester处理日志的分块和写入存储；Querier处理查询请求，从存储中获取数据。

然后是Promtail，作为日志收集客户端，类似于Fluentd或Filebeat，但专为Loki设计。需要解释Promtail如何发现日志文件，添加标签，通过HTTP推送日志到Loki。标签的作用很重要，因为它决定了日志的存储和查询方式，标签设计不当会影响效率。

整体架构图‌

+----------------+       +---------------+       +------------+       +------------+
|   Promtail     | --->  |  Distributor  | --->  |  Ingester  | --->  | S3/MinIO   |
| (日志采集客户端)|       | (日志分发层)  |       | (日志写入层)|       | (对象存储) |
+----------------+       +---------------+       +------------+       +------------+
                               ↑                                        ↑
                               |                                        |
                          +------------+                         +------------+
                          |  Querier   | <----------------------|  Query      |
                          | (查询执行层)|                         | Frontend    |
                          +------------+                         +------------+

组件详解‌

1. Loki-distributed‌

Loki 的分布式部署模式，由以下微服务组成：

 Distributor‌
‌作用‌：接收 Promtail 的日志流，进行数据校验和负载均衡
‌原理‌：
通过 ‌一致性哈希‌ 将日志分发给多个 Ingester
使用 ‌gRPC 流式传输‌ 降低网络开销
‌关键配置‌：replication_factor: 2（副本冗余）

 Ingester‌
‌作用‌：日志分块压缩，写入持久化存储
‌原理‌：
将日志按 chunk_target_size (默认 1.5MB) 分块
使用 ‌Snappy 压缩算法‌ 减少存储体积
通过 ‌WAL (预写日志)‌ 保证数据可靠性
‌无状态关键‌：chunk_idle_period: 1h（超时后强制写入存储）

 Querier‌
‌作用‌：执行日志查询请求，聚合多数据源结果
‌原理‌：
从 ‌对象存储（S3）‌ 拉取历史数据
实时查询 ‌Ingester 内存‌ 中的最新日志
‌优化手段‌：query_store: true（启用存储缓存）
Query Frontend‌
‌作用‌：查询请求的流量网关和加速器
‌原理‌：
拆分大范围查询为多个子查询（‌分片并行‌）
使用 ‌Redis‌ 缓存高频查询结果
 2. Promtail‌
 Loki 官方日志采集客户端

处理流水线‌

读取日志 → 解析标签（Labels） → 动态处理（Pipeline） → 推送至 Loki

数据流分析‌

Promtail → Distributor → Ingester → 对象存储
                                ↓
                                WAL（故障恢复）

查询路径‌

用户请求 → Query Frontend → Querier → Ingester（实时数据）
                              ↓
                             对象存储（历史数据）

开始安装部署

#获取loki-distributed的安装包
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
## 编辑成你喜欢的样子
helm pull grafana/loki-distributed --untar 

我是全部设置成单副本的

安装 Promtail

helm pull grafana/promtail --untar

cat promtail-minio-values.yaml 
rbac:
  pspEnabled: false
config:
  clients:
    #写上网关地址
    - url: http://loki-distributed-gateway/loki/api/v1/push
helm -n loki  install promtail promtail  -f ./promtail/values.yaml

最后部署grafana

#获取密码登陆
kubectl get secret --namespace loki grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

日志查询不再演示了

最后上传日志到S3或者MiniO

在实际生产环境中，日志数据的保留时间通常取决于多个因素，包括：

1. 合规性要求：某些行业（如金融、医疗等）可能有法律法规要求保留日志数据的时间。

2. 业务需求：不同的业务可能对日志的使用频率和分析需求不同。例如，某些团队可能需要能够访问过去几个月或几年的日志，而其他团队可能只需要最近几周的日志。

3. 存储成本：保留时间越长，所需的存储空间就越大，因此需要考虑存储成本。

4. 性能考虑：长时间保留大量日志可能会影响查询性能，因此需要在性能和数据保留之间找到一个平衡。

常见的保留策略

• 短期保留（如 7 天到 30 天）：适用于大多数开发和测试环境，或对实时监控和故障排查有较高需求的场景。

• 中期保留（如 30 天到 90 天）：适用于许多生产环境，允许团队在一定时间内分析历史数据。

• **长期(2年-10年）

Loki分布式版通常包含多个组件，如Ingester、Distributor、Query Scheduler等。根据之前的学习，Ingester负责处理日志流并将其持久化为块，而存储上传可能涉及多个组件。

• Ingester：接收来自Distributor的日志数据，缓存在内存中，形成块（chunks），当满足条件（如时间或大小）时上传到存储。

• Compactor：可能负责压缩和清理旧的索引数据，但不确定是否直接参与上传。

• 其他组件如Distributor主要负责转发日志，Query组件负责查询，可能不直接处理存储上传。

核心上传组件定位

graph LR  
    A[Distributor] --> B[Ingester]  
    B -->|实时日志块| C{MinIO/S3}  
    D[Index Gateway] -->|TSDB索引| C  

• Ingester工作机制

┌──────────────────────────────┐  
|         内存日志块            |  
|  (持续接收Distributor数据)     |  
└───────────────────┬──────────┘  
                    │  
                    ▼  
┌───────────────────────────────────┐  
| 触发上传条件：                     |  
| 1. chunk_idle_period=30m (默认)    |  
| 2. chunk_target_size=1.5MB        |  
| 3. 进程正常关闭/滚动更新           |  
└───────────────────┬───────────────┘  
                    │  
                    ▼  
┌───────────────────────────────────┐  
| 多线程加密压缩 → S3分片上传         |  
| (2025版新增CRC64校验流式传输)       |  
└───────────────────────────────────┘  

Ingester（实时日志上传）

flowchart LR  
    A[Distributor] --> B[Ingester内存缓存]  
    B -->|条件满足时| C{加密压缩}  
    C --> D[S3分片上传]  

参数‌:

loki.config.ingester:  
  chunk_idle_period: 30m  # 空闲超时  
  chunk_target_size: 1MB   # 大小阈值  
  max_chunk_age: 2h       # 兜底最大存活时间  

#日志内容（Ingester上传）‌实时可见
ingester:  
  adaptive_upload: true  # 自动根据S3延迟调整分片大小  
  s3_max_retries: 3      # 增强型断点续传  

Index Gateway（索引同步）

flowchart LR  
    A[TSDB分片生成] --> B[Index Gateway队列]  
    B -->|周期性| C{S3多副本上传}  

YAML
loki.config.storage_config.boltdb_shipper:  
  upload_period: 15m     # 索引上传周期  
  sync_interval: 5m      # 存储同步间隔  

日志压缩

#### loki.config:  
  storage:  
    raw_mode:  
      enabled: true     # 开启实验性直存  
      format: "text"    # 仅支持text/json  
      compression: "none"  # 必须禁用压缩  

‌成本对比

数据类型	存储成本（每TB/月）	典型压缩率
Loki标准存储	$23	10:1
原始日志直存	$190	1:1

• 开发测试环境‌ → 使用Loki实验性直存简化流程
• 生产环境‌ → 采用Promtail双写 + ‌生命周期策略‌（7天后转归档存储）
• 合规审计场景‌ → Lambda镜像备份 + ‌WORM保护

配置values.yaml

  schemaConfig:
    configs:
    - from: "2020-09-07"
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      object_store: s3
      index:
        prefix: loki_index_
        period: 24h

  storageConfig:
    aws:
      endpoint: "172.16.8.104:9000"
      access_key_id: "tw8iFXwkBlrUmNKLp6ei"
      secret_access_key: "GBQW7xObmwcTDo4Yz5b2OH4u73i6sEPGBhnvxvSl"
      insecure: true
      bucketnames: "jbk"
      s3forcepathstyle: true

在更新一下

helm -n loki upgrade loki loki-distributed -f ./loki-distributed/values.yaml

到pods里验证参数是否配置成功

kubectl exec -it -n loki loki-loki-distributed-ingester-0 -- cat  /etc/loki/config/config.yaml

登录minio查看日志是否上传

最后补充日志的保留天数

    table_manager:
      retention_deletes_enabled: true
      retention_period: 2520h

更多详细参数可以参考官网

https://grafana.com/docs/loki/latest/configure/storage/