Skip to content
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.

Sign up for GitHub

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 SpanExporter Interface #75

Closed
wants to merge 1 commit into from
Closed

Add SpanExporter Interface #75

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions packages/opentelemetry-types/src/trace/export/SpanExporter.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
/**
* Copyright 2019, OpenTelemetry Authors
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* https://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

import { Span } from '../span';

/**
* An interface that allows different tracing services to export recorded data
* for sampled spans in their own format.
*/
export interface SpanExporter {
/**
* Called to export sampled {@link Span}s.
* @param spans the list of sampled Spans to be exported.
*/
export(spans: Span[]): void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When is this called? We need spans to be grouped by trace, so unless this is called at the end of every trace it wouldn't work for us.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was planning to add a SpanEventListener interface to record start and end of the spans. Exporters would use these methods to collect and store spans locally and export method would run every few secs to export to backend.

interface SpanEventListener {
    onStartSpan(span: Span): void;
    onEndSpan(span: Span): void;
}

interface SpanExporter extends SpanEventListener {}

Let me know if this makes sense, otherwise please suggest an alternatives.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand how this addresses the issue. What we need is to be able to report traces to our backend as traces and not as individual spans. In OpenCensus for example, it's traces that were passed to this method and not individual spans.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume by traces here you mean all of the spans for a given trace that were generated by the process? (Since presumably the full distributed trace is being written by different microservices). Could we implement that behavior by having some kind of buffering adapter that listens for spans and groups them by trace ID and then flushes them once a certain period of time goes by? Or how might the system know that no more spans for a given trace ID within the process will be created?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume by traces here you mean all of the spans for a given trace that were generated by the process?

Yes, but given the recent discussions it seems that exporters will be responsible for handling the batching, in which case my initial concern is solved.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, yeah, I could imagine some batching utilities that exporters could use for common batching strategies, one of which could be grouping by trace ID

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this need will naturally appear if code starts to be duplicated. In the meantime, I wouldn't try to predict how batching will be done. In our case, we batch in very specific ways to optimize calls as much as possible, so we wouldn't be able to use a generic batch utility.


/** Stops the exporter. */
stop(): void;
}