Skip to main content

启用 Blob 存储

默认情况下，LangSmith 将运行输入、输出、错误、清单、额外信息和事件存储在 ClickHouse 中。如果您愿意，也可以将这些信息存储在对象存储（blob storage）中，这具有几个显著优势：

  1. 在高追踪环境中，输入、输出、错误、清单、额外信息和事件可能会使数据库的大小膨胀。
  2. 如果使用 LangSmith Managed ClickHouse，您可能希望将敏感信息存储在位于您环境中的 blob 存储中。 为了解决这个问题，LangSmith 支持将运行输入、输出、错误、清单、附加数据、事件和附件存储在外部 blob 存储系统中。

需求​

注意

Azure blob storage 在 Helm chart 版本 0.8.9 及更高版本中处于 Beta 阶段。
在测试版期间，删除跟踪项目 不受支持。

  • 访问有效的 blob 存储服务
  • 存储数据的 blob 存储中的桶/目录。我们强烈建议为 LangSmith 数据创建单独的桶/目录。
    • 如果您使用 TTL（生存时间），您需要设置生命周期策略以删除旧数据。您可以在此处查看有关配置 TTL 的更多信息。这些策略应与您 LangSmith 配置中设置的 TTL 保持一致，否则可能会导致数据丢失。 请在此处查看如何为 blob 存储设置 TTL 的生命周期规则。
  • 允许 LangSmith 服务访问存储桶/目录的凭据
    • 您需要向您的 LangSmith 实例提供必要的凭据以访问该存储桶/目录。有关更多信息，请阅读下面的认证 部分。
  • 如果使用 S3 或 GCS，您的对象存储服务需要一个 API 地址
    • 这将是 LangSmith 用于访问您对象存储系统的 URL
    • 对于 Amazon S3，这将是 S3 端点的 URL。例如：https://s3.amazonaws.com 或 https://s3.us-west-1.amazonaws.com（如果使用区域端点）。
    • 对于 Google Cloud Storage，这将是 GCS 端点的 URL。例如：https://storage.googleapis.com

身份验证​

Amazon S3​

要认证访问 Amazon S3，您需要创建一个 IAM 策略，为您的存储桶授予管理员权限。 这将类似于以下内容：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

一旦您有了正确的策略，就有两种方式可以通过 Amazon S3 进行身份验证：

  1. （推荐）服务账户的 IAM 角色: 您可以为您的 LangSmith 实例创建一个 IAM 角色，并将策略附加到该角色上。 然后，您可以将该角色提供给 LangSmith。 这是在生产环境中使用 Amazon S3 进行身份验证的推荐方式。
    1. 您需要创建一个带有策略附加的IAM角色。
    2. 您需要允许LangSmith服务帐户假设该角色。1号，2号和3号服务帐户需要能够假设该角色。
      服务帐户名称

      如果您使用的是自定义发布名称，则服务帐户名称将会不同。您可以通过在您的集群中运行10号来查找服务帐户名称。

    3. 您需要向LangSmith提供角色ARN。您可以这样做，通过在Helm Chart安装中添加11号注释到12号，13号和14号服务。
  2. Access Key and Secret Key: You can provide LangSmith with an access key and secret key. This is the simplest way to authenticate with Amazon S3. However, it is not recommended for production use as it is less secure
    1. You will need to create a user with the policy attached. Then you can provision an access key and secret key for that user.

Google Cloud Storage​

为了通过 Google Cloud Storage 进行身份验证，您需要创建一个 service account，并具有访问您的存储桶所需的权限。

您的服务账号需要Storage Admin角色或具有等效权限的自定义角色。这可以限制在LangSmith将使用的存储桶范围内。

一旦你拥有了一个配置的服务账号，你需要生成一个 凭据 用于该服务账号。这个密钥和密码将被用来认证与Google Cloud Storage的连接。

Azure Blob Storage​

要使用Azure Blob Storage进行身份验证，您需要使用以下方法之一授予LangSmith工作负载权限以访问您的容器（按优先级顺序列出）:

  1. 存储帐户和访问密钥
  2. 连接字符串
  3. Workload identity (recommended), managed identity, or environment variables supported by DefaultAzureCredential. This is the default authentication method when configuration for either option above is not present.
    1. To use workload identity, add the label azure.workload.identity/use: true to the queue, backend, and platform-backend deployments. Additionally, add the azure.workload.identity/client-id annotation to the corresponding service accounts, which should be an existing Azure AD Application's client ID or user-assigned managed identity's client ID. See Azure's documentation for additional details.
注意

一些部署可能需要使用服务URL覆盖而不是默认服务URL（https://<storage_account_name>.blob.core.windows.net/）进一步定制连接配置。例如，为了使用不同的Blob存储域（例如政府或中国），这种覆盖是必要的。

<p>默认情况下，LangSmith 仍然会在 ClickHouse 中存储用于搜索的令牌。如果您使用的是 LangSmith 托管的 Clickhouse，您可能需要禁用此功能，以避免将潜在的敏感信息发送给 ClickHouse。您可以在您的 blob 存储配置中进行此操作。</p>

配置​

在创建存储桶并获取必要的凭证后，您可以配置 LangSmith 来使用您的 blob 存储系统。


config:
  blobStorage:
    enabled: true
    engine: "S3" # Or "Azure"
    chSearchEnabled: true # Set to false if you want to disable CH search (Recommended for LangSmith Managed Clickhouse)
    bucketName: "your-bucket-name"
    apiURL: "Your connection url"
    accessKey: "Your access key" # Optional. Only required if using S3 access key and secret key
    accessKeySecret: "Your access key secret" # Optional. Only required if using access key and secret key
    # The following blob storage configuration values are for Azure and require blobStorage.engine = "Azure". Omit otherwise.
    azureStorageAccountName: "Your storage account name" # Optional. Only required if using storage account and access key.
    azureStorageAccountKey: "Your storage account access key" # Optional. Only required if using storage account and access key.
    azureStorageContainerName: "your-container-name" # Required
    azureStorageConnectionString: "" # Optional.
    azureStorageServiceUrlOverride: "" # Optional 

 backend: # Optional, only required if using IAM role for service account on AWS or workload identity on AKS
   deployment:  # Azure only
     labels:
       azure.workload.identity/use: true
   serviceAccount:
     annotations:
       azure.workload.identity/client-id: "<client_id>" # Azure only
       eks.amazonaws.com/role-arn: "<role_arn>" # AWS only 

 platformBackend: # Optional, only required if using IAM role for service account on AWS or workload identity on AKS
   deployment:  # Azure only
     labels:
       azure.workload.identity/use: true
   serviceAccount:
     annotations:
       azure.workload.identity/client-id: "<client_id>" # Azure only
       eks.amazonaws.com/role-arn: "<role_arn>" # AWS only 

 queue: # Optional, only required if using IAM role for service account on AWS or workload identity on AKS
   deployment:  # Azure only
     labels:
       azure.workload.identity/use: true
   serviceAccount:
     annotations:
       azure.workload.identity/client-id: "<client_id>" # Azure only
       eks.amazonaws.com/role-arn: "<role_arn>" # AWS only
使用现有的密钥

如果使用访问密钥和秘密密钥，您还可以提供一个包含身份验证信息的现有 Kubernetes 密钥。 直接在配置中提供访问密钥和秘密密钥的情况下，建议使用此方法。 有关预期的密钥信息，请参见生成的密钥模板。

TTL 配置​

如果在 LangSmith 中使用 TTL 功能，您还需要为您的 Blob 存储配置 TTL 规则。 存储在 Blob 存储中的跟踪信息会存储在一个特定的前缀路径下，该路径决定了数据的 TTL。 当跟踪的保留时间延长时，其对应的 Blob 存储路径会发生变化，以确保它符合新的延长保留时间。

使用了以下TTL前缀：

  • ttl_s/: 短期TTL，配置为14天。
  • ttl_l/: 长期TTL，配置为400天。

如果你在 LangSmith 配置中自定义了 TTL，你需要调整 Blob 存储配置中的 TTL 以匹配。

Amazon S3​

如果使用S3作为您的Blob存储，您需要设置一个与上述前缀匹配的过滤生命周期配置。您可以在Amazon文档中找到相关信息。

例如，如果您使用 Terraform 来管理您的 S3 存储桶，您可以设置如下内容：

  rule {
    id      = "short-term-ttl"
    prefix  = "ttl_s/"
    enabled = true

    expiration {
      days = 14
    }
  }

  rule {
    id      = "long-term-ttl"
    prefix  = "ttl_l/"
    enabled = true

    expiration {
      days = 400
    }
  }

Google Cloud Storage​

您需要为正在使用的GCS存储桶设置生命周期条件。 您可以在此处找到相关信息：Google文档中， 特别是使用matchesPrefix。

例如，如果您使用 Terraform 来管理您的 GCS 存储桶，您可以设置如下内容：

  lifecycle_rule {
    condition {
      age            = 14
      matches_prefix = ["ttl_s"]
    }
    action {
      type = "Delete"
    }
  }

  lifecycle_rule {
    condition {
      age            = 400
      matches_prefix = ["ttl_l"]
    }
    action {
      type = "Delete"
    }
  }

Azure Blob Storage​

您需要在容器上配置一个生命周期管理策略， 以便使符合上述前缀的对象过期。

例如，如果你正在使用 Terraform 管理你的 Blob 存储容器，你需要设置类似以下的内容：

resource "azurerm_storage_management_policy" "example" {
  storage_account_id = "my-storage-account-id"

  rule {
    name = "base"
    enabled = true
    type = "Lifecycle"
    filters {
      prefix_match = ["my-container/ttl_s"]
      blob_types = ["blockBlob"]
    }
    actions {
      base_blob {
        delete_after_days_since_creation_greater_than = 14
      }
      snapshot {
        delete_after_days_since_creation_greater_than = 14
      }
      version {
        delete_after_days_since_creation_greater_than = 14
      }
    }
  }

  rule {
    name = "extended"
    enabled = true
    type = "Lifecycle"
    filters {
      prefix_match = ["my-container/ttl_l"]
      blob_types = ["blockBlob"]
    }
     actions {
      base_blob {
        delete_after_days_since_creation_greater_than = 400
      }
      snapshot {
        delete_after_days_since_creation_greater_than = 400
      }
      version {
        delete_after_days_since_creation_greater_than = 400
      }
    }
  }
}

此页面有帮助吗？


您可以留下详细的反馈 在 GitHub 上。