菜单
文档breadcrumb arrow Grafana Lokibreadcrumb arrow 配置breadcrumb arrow 存储
开源

存储

与其他日志系统不同，Grafana Loki 的构建理念是只索引日志的元数据：标签（就像 Prometheus 标签一样）。日志数据本身被压缩并以 chunk 的形式存储在对象存储中，例如 S3 或 GCS，甚至可以存储在本地文件系统上。小型索引和高度压缩的 chunk 简化了操作并显著降低了 Loki 的成本。

Loki 2.8 引入了 TSDB 作为 Single Store 的一种新模式，现已成为在 Loki 中持久化数据的推荐方式。有关 TSDB 的更多详细信息，请参阅管理章节。

Loki 2.0 引入了一种名为“boltdb-shipper”的索引机制，这就是我们现在称之为Single Store 的模式。这种类型只需要一个存储，即对象存储，用于同时存储索引和 chunk。有关“boltdb-shipper”的更多详细信息，请参阅管理章节。

在 Loki 2.0 之前，chunk 和索引数据存储在不同的后端：chunk 数据使用对象存储（或文件系统），索引数据使用 NoSQL/键值数据库。这些“多存储”后端已被弃用，如下所述。

您可以在管理章节中找到所有存储选项的更多详细信息。

Single Store

Single Store 指使用对象存储作为 Loki 索引及其数据（“chunk”）的存储介质。支持两种模式

从 Loki 2.8 开始，TSDB 索引存储提高了查询性能，降低了总拥有成本 (TCO)，并且与“boltdb-shipper”具有相同的功能奇偶性。TSDB 是 Loki 2.8 及更新版本的推荐索引存储。

BoltDB（已弃用）

在开发期间也称为“boltdb-shipper”（并且仍然是 schema 的 store 名称）。Loki 的单存储配置使用 chunk 存储来同时存储 chunk 和索引，只需要一个存储即可运行 Loki。BoltDB 是 Loki v2.0.0 到 v2.7x 的推荐索引存储。

性能与专用索引类型相当，同时提供了更经济且更简单的部署。使用 Single Store 时，无需额外的Chunk 存储和索引存储。

支持的存储后端

有关支持的后端，请参阅对象存储。

Chunk 存储

文件系统

文件系统是最简单的 chunk 后端，尽管由于它没有复制，也容易发生数据丢失。这在单二进制部署中很常见，对于试用 Loki 或进行本地开发的用户也是如此。它在概念上类似于许多 Prometheus 部署，其中单个 Prometheus 负责监控一组目标。

对象存储

Google Cloud Storage (GCS)

GCS 是 Google 提供的一项托管对象存储服务。它是托管对象存储的良好选择，特别是在您已运行在 GCP 上时，并且是生产环境安全的。

Amazon Simple Storage Service (S3)

S3 是 AWS 的托管对象存储服务。它是托管对象存储的良好选择，特别是在您已运行在 AWS 上时，并且是生产环境安全的。

Azure Blob 存储

Blob 存储是 Microsoft Azure 的托管对象存储服务。它是托管对象存储的良好选择，特别是在您已运行在 Azure 上时，并且是生产环境安全的。您可以通过存储帐户名称和密钥或使用服务主体来认证 Blob 存储访问。

IBM Cloud Object Storage (COS)

COS 是 IBM Cloud 托管对象存储服务。它是托管对象存储的良好选择，特别是在您已运行在 IBM Cloud 上时，并且是生产环境安全的。

百度对象存储 (BOS)

BOS 是百度云托管对象存储服务。

阿里云对象存储服务 (OSS)

OSS 是阿里云托管对象存储服务。

其他值得一提的选项

您可以使用任何可替代的服务，例如实现 S3 API 的服务，如 MinIO。

Cassandra（已弃用）

Cassandra 是一个流行的数据库，也是 Loki 可能的 chunk 存储之一，并且是生产环境安全的。

注意

此 chunk 存储类型已弃用，并可能在 Loki 未来的主要版本中移除。

索引存储

Cassandra（已弃用）

Cassandra 也可用于索引存储，除了boltdb-shipper 之外，它是唯一可用于索引的非云服务，具有横向伸缩性和可配置的复制。如果您已经运行 Cassandra，或者在本地部署，或者不想使用托管云服务，它是一个不错的选择。

注意

此索引存储类型已弃用，并可能在 Loki 未来的主要版本中移除。

BigTable（已弃用）

Bigtable 是 Google 提供的一项云数据库服务。如果您已经在 GCP 中运行或希望在 GCP 中运行，并且已经在使用它（由于其高昂的固定成本），它是一个不错的托管索引存储选择。

注意

此索引存储类型已弃用，并可能在 Loki 未来的主要版本中移除。

DynamoDB（已弃用）

DynamoDB 是 AWS 提供的一项云数据库服务。它是一个不错的托管索引存储选择，特别是如果您已在 AWS 中运行。

注意

此索引存储类型已弃用，并可能在 Loki 未来的主要版本中移除。

速率限制

DynamoDB 容易受到速率限制的影响，特别是由于过度消耗所谓的预置容量。这可以通过表管理器中的provisioning 配置来控制。

BoltDB（已弃用）

BoltDB 是一个磁盘上的嵌入式数据库。它没有复制，因此不能用于高可用性或集群 Loki 部署，但通常与 filesystem chunk 存储搭配使用，用于概念验证部署、试用 Loki 和开发。boltdb-shipper 旨在支持使用 boltdb 作为索引的集群部署。

注意

此索引存储类型已弃用，并可能在 Loki 未来的主要版本中移除。

Schema 配置

Loki 旨在实现向后兼容，在其开发过程中进行了许多内部更改，以促进更好、更高效的存储/查询。Loki 允许逐步升级到这些新的存储 schemas，并且可以透明地跨它们进行查询。这使得升级变得轻而易举。例如，从 2023-07-01 开始，从使用 v11 schema 的 BoltDB 迁移到使用 v13 schema 的 TSDB 的配置如下所示

yaml 
schema_config:
  configs:
    - from: 2019-07-01
      store: boltdb
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h
    - from: 2023-07-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

对于 2023-07-01 之前摄入的所有数据，Loki 使用了带有 v11 schema 的 BoltDB，之后切换到使用 v13 schema 的更有效的 TSDB。这极大地简化了升级，确保可以轻松利用新的存储优化。这些配置应该保持不变，只要您关注数据保留。

表管理器（已弃用）

Loki 中的一个子组件是 table-manager。它负责预创建和过期索引表。这有助于将 Loki 的写入和读取分散到一组不同的索引中，以防止无限制增长。

yaml 
table_manager:
  # The retention period must be a multiple of the index / chunks
  # table "period" (see period_config).
  retention_deletes_enabled: true
  # This is 15 weeks retention, based on the 168h (1week) period durations used in the rest of the examples.
  retention_period: 2520h

更多信息，请参阅表管理器文档。

Provisioning

对于 AWS DynamoDB，您可能还需要调整表的预置吞吐量。这既是为了防止表被速率限制，也是为了避免不必要的成本。默认情况下，Loki 为 DynamoDB 表使用如下预置容量策略

yaml 
table_manager:
  index_tables_provisioning:
    # Read/write throughput requirements for the current table
    # (the table which would handle writes/reads for data timestamped at the current time)
    provisioned_write_throughput: <int> | default = 3000
    provisioned_read_throughput: <int> | default = 300

    # Read/write throughput requirements for non-current tables
    inactive_write_throughput: <int> | default = 1
    inactive_read_throughput: <int> | Default = 300

请注意，还有其他 DynamoDB provisioning 选项，包括 DynamoDB 自动扩展和按需容量。有关更多信息，请参阅 table_manager 块文档中的provisioning 配置。

升级 Schemas

当新 schema 发布并且您想利用它带来的优势时，您可以做到！Loki 可以透明地跨 schema 边界查询和合并数据，因此不会中断服务，升级也很容易。

首先，您需要在 schema_config 中创建一个新的 period_config 条目。这里要记住的重要一点是，将其设置在未来某个时间点，然后将配置文件更改部署到 Loki。这使得表管理器能够在写入之前提前创建所需的表，并确保现有数据不会按照新 schema 的方式查询。

例如，假设现在是 2023-07-14，您想在 20 号开始使用 v13 schema

yaml 
schema_config:
  configs:
    - from: 2019-07-14
      store: tsdb
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h
    - from: 2023-07-20
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

就是这么简单；您刚刚创建了一个从 20 号开始的新条目。

保留

除了 filesystem chunk 存储之外，Loki 不会删除旧的 chunk 存储。这通常通过在您选择的 chunk 存储中配置 TTL（生存时间）来处理（S3/GCS 中的存储桶生命周期，以及 Cassandra 中的 TTL）。目前，当使用 filesystem chunk 存储并且本地磁盘已满时，Loki 也不会删除旧数据——删除仅由保留时长决定。

我们有兴趣在未来的 Loki 版本中添加有针对性的删除（考虑租户或流级别的粒度），并且也可能包含其他策略。

更多信息，请参阅保留配置文档。

示例

单机/本地开发 (boltdb+filesystem)

仓库包含一个可工作的示例，您可能需要 checkout 仓库的某个标签以确保获得兼容的示例。

GCP 部署 (GCS Single Store)

yaml 
storage_config:
  tsdb_shipper:
    active_index_directory: /loki/index
    cache_location: /loki/index_cache
    cache_ttl: 24h # Can be increased for faster performance over longer query periods, uses more disk space
  gcs:
      bucket_name: <bucket>
      service_account: |    
        {
          "type": "service_account",
          ...
        }

schema_config:
  configs:
    - from: 2020-07-01
      store: tsdb
      object_store: gcs
      schema: v13
      index:
        prefix: index_
        period: 24h

service_account 应包含来自 GCP Console client_credentials.json 文件或 GCP 服务帐户密钥的 JSON。如果此值为空，大多数服务将回退到 GCP 的 Application Default Credentials (ADC) 策略。有关 ADC 的更多信息，请参阅Application Default Credentials 工作原理。

预定义的 storage.objectUser 角色（或基于它建模的自定义角色）包含 Loki 运行所需的足够权限。

注意

GCP 建议使用工作负载身份联合而不是服务帐户密钥。

AWS 部署 (S3 Single Store)

yaml 
storage_config:
   tsdb_shipper:
    active_index_directory: /loki/index
    cache_location: /loki/index_cache
    cache_ttl: 24h         # Can be increased for faster performance over longer query periods, uses more disk space
  aws:
    s3: s3://<access_key>:<uri-encoded-secret-access-key>@<region>
    bucketnames: <bucket1,bucket2>

schema_config:
  configs:
    - from: 2020-07-01
      store: tsdb
      object_store: aws
      schema: v13
      index:
        prefix: index_
        period: 24h

如果您不想硬编码 S3 凭据，也可以通过修改 storage_config 部分来配置 EC2 实例角色

yaml 
storage_config:
  aws:
    s3: s3://region
    bucketnames: <bucket1,bucket2>

该角色应附加具有以下权限的策略。

json 
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LokiStorage",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<account_ID>"
                ]
            },
            "Action": [
                "s3:ListBucket",
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::<bucket_name>",
                "arn:aws:s3:::<bucket_name>/*"
            ]
        }
    ]
}

要设置 S3 存储桶以及 IAM 角色和策略

本指南假设已预置了 EKS 集群。

  1. Checkout Loki 仓库并导航到 production/terraform/modules/s3。

  2. 初始化 Terraform terraform init。

  3. 如果尚未导出，请导出 AWS profile 和区域

    bash 
    export AWS_PROFILE=<profile in ~/.aws/config>
export AWS_REGION=<region of EKS cluster>

  4. 将 OIDC 提供者保存在环境变量中

    bash 
    oidc_provider=$(aws eks describe-cluster --name <EKS cluster> --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")

    有关创建提供者的指南，请参阅IAM OIDC 提供者指南。

  5. 应用 Terraform 模块 terraform -var region="$AWS_REGION" -var cluster_name=<EKS cluster> -var oidc_id="$oidc_provider"

    注意，存储桶名称默认为 loki-data，但可以通过 bucket_name 变量更改。

Azure 部署 (Azure Blob 存储 Single Store)

使用帐户名称和密钥

yaml 
schema_config:
  configs:
  - from: "2020-12-11"
    index:
      period: 24h
      prefix: index_
    object_store: azure
    schema: v13
    store: tsdb
storage_config:
  azure:
    # Your Azure storage account name
    account_name: <account-name>
    # For the account-key, see docs: https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage?tabs=azure-portal
    account_key: <account-key>
    # See https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction#containers
    container_name: <container-name>
    use_managed_identity: <true|false>
    # Providing a user assigned ID will override use_managed_identity
    user_assigned_id: <user-assigned-identity-id>
    request_timeout: 0
    # Configure this if you are using private azure cloud like azure stack hub and will use this endpoint suffix to compose container and blob storage URL. Ex: https://account_name.endpoint_suffix/container_name/blob_name
    endpoint_suffix: <endpoint-suffix>
    # If `connection_string` is set, the values of `account_name` and `endpoint_suffix` values will not be used. Use this method over `account_key` if you need to authenticate via a SAS token. Or if you use the Azurite emulator.
    connection_string: <connection-string>
  tsdb_shipper:
    active_index_directory: /loki/index
    cache_location: /loki/index_cache
    cache_ttl: 24h
  filesystem:
    directory: /loki/chunks

使用服务主体

yaml 
schema_config:
  configs:
  - from: "2020-12-11"
    index:
      period: 24h
      prefix: index_
    object_store: azure
    schema: v13
    store: tsdb
storage_config:
  azure:
    use_service_principal: true
    # Azure tenant ID used to authenticate through Azure OAuth
    tenant_id : <tenant-id>
    # Azure Service Principal ID
    client_id: <client-id>
    # Azure Service Principal secret key
    client_secret: <client-secret>
    # See https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction#containers
    container_name: <container-name>
    request_timeout: 0
  tsdb_shipper:
    active_index_directory: /loki/index
    cache_location: /loki/index_cache
    cache_ttl: 24h
  filesystem:
    directory: /loki/chunks

IBM 部署 (COS Single Store)

yaml 
schema_config:
  configs:
    - from: 2020-10-01
      index:
        period: 24h
        prefix: loki_index_
      object_store: cos
      schema: v13
      store: tsdb

storage_config:
  tsdb_shipper:
   active_index_directory: /loki/index
   cache_location: /loki/index_cache
  cos:
    bucketnames: <bucket1, bucket2>
    endpoint: <endpoint>
    api_key: <api_key_to_authenticate_with_cos>
    region: <region>
    service_instance_id: <cos_service_instance_id>
    auth_endpoint: <iam_endpoint_for_authentication>

本地部署 (Cassandra+Cassandra)

注意

Cassandra 作为 chunk 和索引的存储后端已弃用。

保留此信息供后人参考，但这可能不是常见的配置。Cassandra 应该可以工作，在某些情况下可能更快，但很可能昂贵得多。

yaml 
storage_config:
  cassandra:
    addresses: <comma-separated-IPs-or-hostnames>
    keyspace: <keyspace>
    auth: <true|false>
    username: <username> # only applicable when auth=true
    password: <password> # only applicable when auth=true

schema_config:
  configs:
    - from: 2020-07-01
      store: cassandra
      object_store: cassandra
      schema: v11
      index:
        prefix: index_
        period: 168h
      chunks:
        prefix: chunk_
        period: 168h

本地部署 (MinIO Single Store)

您可以使用 AWS 配置来配置 MinIO，因为 MinIO 实现了 S3 API

yaml 
storage_config:
  aws:
    # Note: use a fully qualified domain name (fqdn), like localhost.
    # full example: http://loki:supersecret@localhost.:9000
    s3: http<s>://<username>:<secret>@<fqdn>:<port>
    s3forcepathstyle: true
  tsdb_shipper:
    active_index_directory: /loki/index
    cache_location: /loki/index_cache
    cache_ttl: 24h         # Can be increased for faster performance over longer query periods, uses more disk space

schema_config:
  configs:
    - from: 2020-07-01
      store: tsdb
      object_store: s3
      schema: v13
      index:
        prefix: index_
        period: 24h