启用 Blob 存储
默认情况下,LangSmith 将运行输入、输出、错误、清单(manifests)、附加信息(extras)和事件存储在 ClickHouse 中。如果您愿意,也可以选择将这些信息存储在 Blob 存储中,这种方式具有若干显著优势:
- 在高追踪(trace)环境下,输入、输出、错误、清单(manifests)、额外信息(extras)和事件可能会使数据库的体积急剧膨胀。
- 如果使用 LangSmith 托管的 ClickHouse,您可能希望将敏感信息存储在位于您环境中的 Blob 存储中。 为缓解此问题,LangSmith 支持将运行输入(run inputs)、输出(outputs)、错误(errors)、清单(manifests)、附加信息(extras)、事件(events)和附件(attachments)存储在外部 Blob 存储系统中。
要求
Azure Blob 存储功能在 Helm 图表版本 0.8.9 及更高版本中以 Beta 版本形式提供。
处于测试阶段时,删除跟踪项目不支持。
- 访问有效的 Blob 存储服务
- 您 Blob 存储中用于存储数据的存储桶/目录。我们强烈建议为 LangSmith 数据单独创建一个存储桶/目录。
- 允许 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 进行身份验证:
- (推荐)服务账户的IAM角色:您可以为 LangSmith 实例创建一个 IAM 角色,并将该策略附加到该角色上。然后,您可将此角色提供给 LangSmith。这是在生产环境中使用 Amazon S3 进行身份验证的推荐方式。
- 您需要创建一个附加了该策略的 IAM 角色。
- 您需要允许 LangSmith 服务账号承担该角色。
langsmith-queue,langsmith-backend,以及langsmith-platform-backend服务账号将需要能够承担该角色。服务账号名称如果您使用了自定义的发布名称,则服务账号名称会有所不同。您可以通过在集群中运行
kubectl get serviceaccounts来查找服务账号名称。 - 您需要向 LangSmith 提供角色 ARN。您可以通过在 Helm Chart 安装中为
eks.amazonaws.com/role-arn: "<role_arn>"、queue和backend服务添加platform-backend注解来实现此操作。
- 访问密钥和密钥:您可以向 LangSmith 提供访问密钥(access key)和密钥(secret key)。这是与 Amazon S3 进行身份验证的最简单方法。但不建议在生产环境中使用,因为其安全性较低。
- 您需要创建一个已附加该策略的用户,然后可为该用户配置访问密钥(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 工作负载访问您的 容器 的权限(按优先级顺序列出):
- 存储账户和访问密钥
- 连接字符串
- 工作负载身份(推荐)、托管标识或受支持的环境变量
DefaultAzureCredential当上述任一选项的配置均不存在时,此为默认的身份验证方法。- 如需使用工作负载标识,请向
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 存储系统。
- Helm
- Docker
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
# In your .env file
FF_BLOB_STORAGE_ENABLED=false # Set to true if you want to enable blob storage
BLOB_STORAGE_ENGINE=S3 # Or Azure
BLOB_STORAGE_BUCKET_NAME=langsmith-blob-storage # Required for using S3. Change to your desired blob storage bucket name
BLOB_STORAGE_API_URL=https://s3.us-west-2.amazonaws.com # Change to your desired blob storage API URL
BLOB_STORAGE_ACCESS_KEY=your-access-key # Change to your desired blob storage access key
BLOB_STORAGE_ACCESS_KEY_SECRET=your-access-key-secret # Change to your desired blob storage access key secret
AZURE_STORAGE_ACCOUNT_NAME=your-storage-account-name # Optional. Only required if using storage account and access key.
AZURE_STORAGE_ACCOUNT_KEY=your-storage-account-key # Optional. Only required if using storage account and access key.
AZURE_STORAGE_CONTAINER_NAME=your-container-name # Required for using Azure blob storage. Change to your desired container name
AZURE_STORAGE_CONNECTION_STRING=BlobEndpoint=https://storagesample.blob.core.windows.net;SharedAccessSignature=signature; # Optional.
AZURE_STORAGE_SERVICE_URL_OVERRIDE=https://your.override.domain.net # Optional
如果使用访问密钥和密钥,您还可以提供一个已存在的 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
}
}
}
}