-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an S3 exporter #2835
Comments
@rakyll What format are you thinking for storage? There's some discussion on open-telemetry/opentelemetry-specification#1443 but I don't think we have a good format defined for stored traces yet. |
This can also be a plugin for fileexporter correct? It is just that you write into a remote "file". |
Once open-telemetry/opentelemetry-specification#1443 is addressed, we should follow the specification there. Otherwise, the format needs discussion/proposal. @bogdandrutu It's a good idea. Given it's vendor-specific, my initial suggestion was a standalone exporter. But, we can ask other vendors to implement support for their services and provide the functionality as a part of the fileexporter. |
Should it be a design goal to pick a format (Parquet, ORC, etc.) (or have a pluggable format) that allows for the data to be queried "in-place" by a system like AWS Athena? |
Given the various data formats we have, can we first start build a few popular format like Parquet/ORC/JSON? |
Initial proposal for the S3 exporter design requirements: Exporter feature: File output format related feature: S3 uploader related feature: |
Could this be a generic object storage using a library like https://github.com/chartmuseum/storage (not advocating this particular one, just as an example). Authentication methods may vary across cloud providers so maybe config options may still need to be cloud specific or something like that but using a library that already abstracts across the providers may still make it easier to extend to other providers. It even has one for local usage so makes sense to extend file exporter like @bogdandrutu suggested https://github.com/chartmuseum/storage/blob/main/local.go. |
But I think this exporter is specific to S3 |
Initial code to kick off the discussion |
@emeraldbay why must it be s3 specific? |
Bumps [github.com/prometheus/common](https://github.com/prometheus/common) from 0.19.0 to 0.20.0. - [Release notes](https://github.com/prometheus/common/releases) - [Commits](prometheus/common@v0.19.0...v0.20.0) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This feature is very nice, so that we can archive so much of instrumentation data but still queryable. |
what is the progress on this feature? |
Hey folks, I added a file exporter here: #6712 |
Because this format is not well suited for s3, I have started working on Parquet support for OpenTelemetry. Once OpenTelemetry data can be serialized in Parquet support, we can create a receiver and exporter for Parquet files. |
I'm open to being a sponsor for the Parquet components on contrib. I think it would be a great addition. |
That is great to hear! I'll try and stick to the approach of creating the component structure first. @jpkrohling please see here: #6903 |
Folks, open-telemetry/opentelemetry-proto#346 is ready for review. It is coming together. It is not a final Parquet mapping by any means but it gets us to a suitable support to experiment. |
Is the idea that the stub parquet exporter in #6903 would eventually learn more formats and destinations, as in #6903 (comment)? Or would it be simpler to have one exporter to export text files to disk, another to export parquet files to disk, another to export parquet/json files to s3, etc.? I would be interested in exporting to both s3 and gcs, and happy to write a patch if it would be helpful. |
Recently, I started working on s3 exporter using this work as a baseline. Is anyone working on that actively? |
I don't think anyone is working on this. If you decide to work on this, make sure you have a sponsor first, in order for this component to be accepted as part of the contrib repository. |
👋 I have a personal interest in seeing OTC be able to write telemetry to S3. I feel that not many vendors have this interest, but for a user who wants to store years worth of telemetry and cares about costs, S3 looks like a good path forward. |
I work on a parquet exporter, but no time recently. |
I volunteer to be a sponsor of the initiative. I think parquet exporter would be very useful and it's great to see the work started, though it's probably a somewhat separate item (essentially serialization mechanism). So I think it might be e.g. in some common package and then referenced by fileexporter and s3 exporter. |
I know this component is still marked in-development and not officially in contrib. But to what extent can it already be used ? Would using it risk crashing the entire collector or at worse it won't do its job but leave everything else functioning ? |
Component is in alfa status, however it should be pretty stable. To continue work on that we need a sponsor as mentioned above. |
Hi all, First of all, thank you for everyone being interested in seeing this implemented. The latter has the advantage that it can be implemented sooner and be rather opinionated on how to handle S3 issues / format. I am happy to sponsor either, I would prefer the extension approach however, it depends on what everyone involved prefers? |
It looks like an earlier discussion leaned towards an abstraction for the fileexporter. |
@MovieStoreGuy Just to clarify, in the case of fileexporter, s3 storage would be treated as a kind of remote file system, right? Does fileexporter have similar extensions already? |
Hi @MovieStoreGuy! we also have an interest in this exporter. Is there any active work ongoing on this? |
@guyfrid Work stopped due to lack of sponsor |
I'm looking also for S3 exporter. Having difficulties using otlp with http+json protocol as metrics exporter. I thought using S3 restful api directly using http+json can be a quick alternative. All I can send is http+protobuf or grpc (which isn't supported by s3). AIs someone implemented it and can sens a config.yaml file or investigate it as well. Thanks guys for this useful thread |
I'd like to see this as well. We have a lot of data we ship to S3. I think it would be useful. Thanks |
OK, I can sponsor this. |
If anyone wants to work on this, they should feel free to take it. Unfortunately I'm working on something else nowadays. |
Thank you for your help! We will get it done. |
Hi, @atoulme would like to know if you need any help with this. Interested in contributing and sponsoring (if required) |
No need for a sponsor, this PR is the latest: Once it's in, we have to get the impl right. |
I was unable to use awss3 exporter with the latest release because of the error:
|
The s3 exporter is not code complete yet from what I understand. We have just merged the skeleton of the exporter. |
That's true. There is a second PR with implementation #10000, however it requires some work as interfaces changed during last few months. |
Any idea when this will make its way in? We are also seeing the same unknown error. |
Pinging code owners for exporter/awss3: @atoulme @pdelewski. See Adding Labels via Comments if you do not have permissions to add labels yourself. |
#20912 is open to finish the job, please review. |
I'm unable to pull latest release i.e., |
Take a look at https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions/otelcol-contrib/manifest.yaml#LL39C79-L39C92, it should be released as of |
Various Otel users want to export raw telemetry data for long-term storage and analysis. We should add an S3 exporter that exports the incoming OTLP data points to sharded S3 objects in a bucket. Sharding can be done per telemetry type (metrics, traces, logs) and time (window to be configured by the user). Also we can consider serializing into Ion at the collector optionally.
(You can assign this issue to me.)
The text was updated successfully, but these errors were encountered: