默认情况下，LangSmith 将运行输入、输出、错误、清单、额外信息和事件存储在 ClickHouse 中。如果您选择，您可以改为将此信息存储在 blob 存储中，这有几个显著的好处。为了在生产部署中获得最佳结果，我们强烈建议使用 blob 存储，它提供以下好处：
  1. 在高跟踪环境中，输入、输出、错误、清单、额外信息和事件可能会使数据库的大小膨胀。
  2. 如果使用 LangSmith 托管 ClickHouse，您可能希望将敏感信息存储在您环境中的 blob 存储中。为了缓解这一点，LangSmith 支持将运行输入、输出、错误、清单、额外信息、事件和附件存储在外部 blob 存储系统中。

​
要求

Azure blob 存储在 Helm chart 版本 0.8.9 及更高版本中可用。从 Helm chart 版本 0.10.43 开始，Azure 中支持删除跟踪项目。
  • 访问有效的 blob 存储服务
  • blob 存储中用于存储数据的存储桶/目录。我们强烈建议为 LangSmith 数据创建单独的存储桶/目录。
    • 如果您使用 TTL，您需要设置生命周期策略来删除旧数据。您可以在此处找到有关配置 TTL 的更多信息。这些策略应镜像您在 LangSmith 配置中设置的 TTL，否则您可能会遇到数据丢失。有关如何为 blob 存储设置 TTL 的生命周期规则，请参阅此处。
  • 允许 LangSmith 服务访问存储桶/目录的凭据
    • 您需要为 LangSmith 实例提供访问存储桶/目录所需的凭据。有关更多信息，请阅读下面的身份验证部分。
  • 如果使用 S3 或 GCS，则为 blob 存储服务提供 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:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "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 安装中的 queue、backend 和 platform-backend 服务中添加 eks.amazonaws.com/role-arn: "<role_arn>" 注释来完成此操作。
  2. 访问密钥和秘密密钥：你可以向 LangSmith 提供访问密钥和秘密密钥。这是向 Amazon S3 进行身份验证的最简单方式。但是，不建议在生产环境中使用，因为它不太安全。
    1. 你需要创建一个附加了策略的用户。然后你可以为该用户配置访问密钥和秘密密钥。
  3. VPC 端点访问：你可以通过 VPC 端点启用对 S3 存储桶的访问，这允许流量从 VPC 安全地流向 S3 存储桶。
    1. 你需要配置 VPC 端点并将其配置为允许访问 S3 存储桶。
    2. 你可以参考我们的公共 Terraform 模块以获取指导和配置示例。

​
S3 的 KMS 加密标头支持

从 LangSmith Helm chart 版本 0.11.24 开始，你可以传递 KMS 加密密钥标头，并通过提供其 ARN 来强制使用特定的 KMS 密钥进行写入。要启用此功能，请在 Helm chart 中设置以下值：
Helm
config:
  blobStorage:
    kmsEncryptionEnabled: true
    kmsKeyArn: <your_kms_key_arn>

​
Google Cloud Storage

要向 Google Cloud Storage 进行身份验证，你需要创建一个具有访问存储桶所需权限的服务账户。 你的服务账户需要 Storage Admin 角色或具有等效权限的自定义角色。这可以限定为 LangSmith 将使用的存储桶。 一旦你有了配置的服务账户，你需要为该服务账户生成一个 HMAC 密钥。此密钥和秘密将用于向 Google Cloud Storage 进行身份验证。

​
Azure Blob Storage

要向 Azure Blob Storage 进行身份验证，你需要使用以下方法之一来授予 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 存储域（例如政府或中国），此覆盖是必需的。

​
CH 搜索

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

​
配置

创建存储桶并获得必要的凭据后，你可以配置 LangSmith 以使用你的 blob 存储系统。 
config:
  blobStorage:
    enabled: true
    engine: "S3" # Or "Azure". This is case-sensitive.
    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 存储

你需要在容器上配置生命周期管理策略，以便使与上述前缀匹配的对象过期。 例如，如果你使用 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
      }
    }
  }
}
Edit the source of this page on GitHub.
Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.