You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Problem
At present, the AWS S3 exporter in the OpenTelemetry Collector does not provide a way to specify the S3 storage class during uploads. For cost optimization and to meet various data retention requirements, users often need to store data in specific S3 storage classes such as:
STANDARD_IA (Standard-Infrequent Access) ONEZONE_IA (One Zone-Infrequent Access) GLACIER, DEEP_ARCHIVE, etc.
Without this feature, users have to manually configure lifecycle rules on their buckets or use external processes to transition data between storage classes, which adds complexity API costs and overhead.
Proposed Solution:
Modify the existing AWS S3 exporter to include support for setting the S3 storage class when uploading objects to S3. The storage class would be configurable in the exporter’s configuration file, similar to how other S3 options (like bucket name and key) are handled.
Something like:
ifconfig.S3Uploader.StorageClass!="" {
storageClass=config.S3Uploader.StorageClass
}
_, err=uploader.Upload(&s3manager.UploadInput{
Bucket: aws.String(config.S3Uploader.S3Bucket),
Key: aws.String(key),
Body: reader,
ContentEncoding: &encoding,
StorageClass: aws.String(storageClass), // Set the storage class here
})
Proposal Implementation Details:
New Configuration Option:
Add a new storage_class field to the aws_s3 exporter configuration. This field would allow users to specify the desired storage class for their S3 objects.
Example YAML config:
exporters:
aws_s3:
bucket: "my-bucket"storage_class: "STANDARD_IA"# New field to specify storage class
Modify S3 Upload Logic:
Update the S3 upload logic to include the StorageClass parameter when calling the S3 API. If the storage_class is not specified, it should default to STANDARD.
Backward Compatibility:
The change is backward compatible, with the STANDARD storage class used as the default value if the storage_class field is not provided.
Describe the solution you'd like
The user can specify the desired S3 storage class via the exporter’s configuration.
Objects uploaded to S3 will be stored in the specified storage class.
If no storage class is specified, the objects will default to the STANDARD storage class.
Proper documentation is updated to reflect the new configuration option.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
Component(s)
exporter/awss3
Is your feature request related to a problem? Please describe.
Problem
At present, the AWS S3 exporter in the OpenTelemetry Collector does not provide a way to specify the S3 storage class during uploads. For cost optimization and to meet various data retention requirements, users often need to store data in specific S3 storage classes such as:
STANDARD_IA
(Standard-Infrequent Access)ONEZONE_IA
(One Zone-Infrequent Access)GLACIER
,DEEP_ARCHIVE
, etc.Without this feature, users have to manually configure lifecycle rules on their buckets or use external processes to transition data between storage classes, which adds complexity API costs and overhead.
Proposed Solution:
Modify the existing AWS S3 exporter to include support for setting the S3 storage class when uploading objects to S3. The storage class would be configurable in the exporter’s configuration file, similar to how other S3 options (like bucket name and key) are handled.
Something like:
Proposal Implementation Details:
New Configuration Option:
Add a new storage_class field to the aws_s3 exporter configuration. This field would allow users to specify the desired storage class for their S3 objects.
Example YAML config:
Modify S3 Upload Logic:
Update the S3 upload logic to include the StorageClass parameter when calling the S3 API. If the storage_class is not specified, it should default to STANDARD.
Backward Compatibility:
The change is backward compatible, with the STANDARD storage class used as the default value if the storage_class field is not provided.
Describe the solution you'd like
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: