Skip to main content

启用 Blob 存储

默认情况下,LangSmith 将运行输入、输出、错误、清单(manifests)、附加信息(extras)和事件存储在 ClickHouse 中。如果您愿意,也可以选择将这些信息存储在 Blob 存储中,这种方式具有若干显著优势:

  1. 在高追踪(trace)环境下,输入、输出、错误、清单(manifests)、额外信息(extras)和事件可能会使数据库的体积急剧膨胀。
  2. 如果使用 LangSmith 托管的 ClickHouse,您可能希望将敏感信息存储在位于您环境中的 Blob 存储中。 为缓解此问题,LangSmith 支持将运行输入(run inputs)、输出(outputs)、错误(errors)、清单(manifests)、附加信息(extras)、事件(events)和附件(attachments)存储在外部 Blob 存储系统中。

要求​

笔记

Azure Blob 存储功能在 Helm 图表版本 0.8.9 及更高版本中以 Beta 版本形式提供。
处于测试阶段时,删除跟踪项目不支持。

  • 访问有效的 Blob 存储服务
  • 您 Blob 存储中用于存储数据的存储桶/目录。我们强烈建议为 LangSmith 数据单独创建一个存储桶/目录。
    • 如果您使用了生存时间(TTL)功能,则需要设置生命周期策略以删除过期数据。有关配置TTL的更多信息,请参阅此处。这些策略应与您在LangSmith配置中设置的TTL保持一致,否则可能导致数据丢失。 有关如何为Blob存储设置TTL生命周期规则,请参阅此处。
  • 允许 LangSmith 服务访问存储桶/目录的凭据
    • 您需要为 LangSmith 实例提供访问存储桶/目录所需的凭据。有关更多信息,请参阅下方的认证章节。
  • 如果使用 S3 或 GCS,请提供您的对象存储服务的 API URL
    • 这将是 LangSmith 用于访问您的 Blob 存储系统的 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 服务账号承担该角色。langsmith-queue, langsmith-backend,以及langsmith-platform-backend服务账号将需要能够承担该角色。
      服务账号名称

      如果您使用了自定义的发布名称,则服务账号名称会有所不同。您可以通过在集群中运行 kubectl get serviceaccounts 来查找服务账号名称。

    3. 您需要向 LangSmith 提供角色 ARN。您可以通过在 Helm Chart 安装中为 eks.amazonaws.com/role-arn: "<role_arn>"、queue 和 backend 服务添加 platform-backend 注解来实现此操作。
  2. 访问密钥和密钥:您可以向 LangSmith 提供访问密钥(access key)和密钥(secret key)。这是与 Amazon S3 进行身份验证的最简单方法。但不建议在生产环境中使用,因为其安全性较低。
    1. 您需要创建一个已附加该策略的用户,然后可为该用户配置访问密钥(Access Key)和密钥(Secret Key)。

Google Cloud Storage​

要使用 Google Cloud Storage 进行身份验证,您需要创建一个具有访问存储桶所需权限的 service account。

您的服务账号需要具备 Storage Admin 角色,或具备同等权限的自定义角色。该权限可限定为 LangSmith 将要使用的存储桶。

在创建好服务账号后,您需要为该服务账号生成一个 HMAC key。此密钥和密钥密码将用于向 Google Cloud Storage 进行身份验证。

Azure Blob 存储​

要使用 Azure Blob 存储 进行身份验证,您需要采用以下任一方法, 授予 LangSmith 工作负载访问您的 容器 的权限(按优先级顺序列出):

  1. 存储账户和访问密钥
  2. 连接字符串
  3. 工作负载身份(推荐)、托管标识或受支持的环境变量DefaultAzureCredential当上述任一选项的配置均不存在时,此为默认的身份验证方法。
    1. 如需使用工作负载标识,请向 azure.workload.identity/use: true、queue 和 backend 部署添加标签 platform-backend。此外,还需向对应的服务账号添加 azure.workload.identity/client-id 注解,该注解应为现有 Azure AD 应用程序的客户端 ID 或用户分配的托管标识的客户端 ID。 更多详细信息,请参阅 Azure 官方文档。
笔记

某些部署可能需要使用服务 URL 覆盖(而非默认服务 URL(https://<storage_account_name>.blob.core.windows.net/))进一步自定义连接配置。例如,若需使用不同的 Blob 存储域(如政府云或中国区),则必须进行此覆盖。

默认情况下,LangSmith 仍会在 ClickHouse 中存储用于搜索的令牌。如果您使用的是 LangSmith 托管的 ClickHouse,您可能希望禁用此功能,以避免将潜在的敏感信息发送至 ClickHouse。您可以在 Blob 存储配置中执行此操作。

配置​

创建存储桶并获取必要的凭据后,您可以配置 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 密钥(Secret),该密钥中包含认证信息。 建议采用此方式,而非直接在配置中提供访问密钥和密钥。 有关预期的密钥名称,请参阅 生成的密钥模板。

TTL 配置​

如果在 LangSmith 中使用 TTL(生存时间) 功能,则还需为您的 Blob 存储配置 TTL 规则。存储在 Blob 存储中的跟踪信息位于特定的前缀路径下,该路径决定了数据的 TTL。当某个跟踪记录的保留期限被延长时,其对应的 Blob 存储路径也会相应变更,以确保与新的延长保留期限相匹配。

以下 TTL 前缀被使用:

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

如果您已在 LangSmith 配置中自定义了 TTL(生存时间),则需要相应调整 Blob 存储配置中的 TTL,以保持一致。

Amazon S3​

如果使用 S3 作为您的对象存储,您需要设置一个生命周期过滤器配置,使其匹配上述前缀。有关此配置的详细信息,请参阅 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​

您需要为您正在使用的 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 存储​

您需要在容器上配置生命周期管理策略,以使匹配上述前缀的对象过期。

例如,如果您使用 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 上.