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.

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 option to format span name with context #29

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

vearutop
Copy link
Contributor

This PR adds option to format span name with func(ctx context.Context, baseName string) string.

That can be handy to make spans more relevant to application flow and enable precise tracing.
Somewhat similar approach is used in ochttp.Handler:

    // FormatSpanName holds the function to use for generating the span name
    // from the information found in the incoming HTTP Request. By default the
    // name equals the URL Path.
    FormatSpanName func(*http.Request) string

@basvanbeek
Copy link
Member

Have you considered using local spans instead? the idea of injecting alternate names for ocsql to use through context seems both tedious and error prone. With local spans you can create a parent span around all database operations / transactions that you want to identify as a particular business logic operation.

@vearutop
Copy link
Contributor Author

Yes, I was thinking of local spans, but that seemed extra verbose and less useful.

Generally I want to span only external communications (db calls, http client requests, event publishing, etc...) because internal calculations usually are of much less latency magnitude. That's why ocsql serves a good purpose by automatically creating a span when external call happens.

Higher level business task may or may not invoke db call (can be short-circuited with cache), so if I create a span on parent business task I'll have a bunch of spans that are not relevant to db observability. They are not useful to me.

If I create span just before calling db I would need an abstraction (that understands current business context) to use instead of direct sql.DB/Tx access. But then, having this abstraction to create spans, why would I need ocsql?

I'm using zpages/tracez quite often to get an current overview of external communications. It does not show spans in a tree, but rather as a flat list grouped by span name. sql:query being produced by a variety of different statements does not have enough cardinality to be helpful outside tree representation. Context gives best flexibility to pass optional additional information about some specific tasks (same as *http.Request and context introduced in census-instrumentation/opencensus-go#796).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants