We’d like feedback on the `CallId` feature. If you have a homebrew version of such a feature, or wou...

# ktor

[orangy]

We’d like feedback on the CallId feature. If you have a homebrew version of such a feature, or would like to try it, please tell us how it works and if it suites your needs. That’s the last feature before we go towards 1.0 and start fixing only bugs and biggest pain points.

[enleur]

we have our own version of that feature, but planning to replace with Jaeger/Zipkin solution

[enleur]

also we have micrometer.io integration to provide prometheus endpoint, which is almost standard in kubernetes environment

[orangy]

We don’t provide a complete tracing solution, of course, but would like an integration with something popular enough. Do I understand it correctly that we need to support Zipking headers, like X-B3-TraceId? That should be easy with call-id feature configuration

[enleur]

I hope so. Now i’m using something like this https://gist.github.com/enleur/9e65fa005cbb881176df282aa63f8bd0

[cy]

It will be something like this for now

install(CallLogging) {
                    mdc("span_id") { call -> call.request.header("X─B3-SpanId") ?: UUID.randomUUID().toString() }
}

[kenkyee]

Micrometer is a good facade to hook in

[cy]

@enleur please note that UUID.randomUUID() is blocking so your server could hang

[mp]

another way to generate random stuff quickly (not cryptograhpically secure! just a "probably unique" thing like UUIDs) is to generate a random HMAC key, then HMAC an incrementing counter every time you need another random string.

[mp]

You only use the entropy pool once at initialization, so you won't block later.

[cy]

On server you may need haveged to avoid it

[mp]

havaged is no longer recommended btw

[mp]

unfortunately the best you can do today, which still isn't great, is run recent kernel + libc with proper syscall wrappers that will block until enough entropy has been gathered on first boot.

[mp]

I think OpenBSD was the first to do it mostly right, but newish Linux + glibc also have support IIRC

[enleur]

@cy it’s not really blocking, it’s just CPU intensive operation 🙂

[mp]

It can block on entropy pool starvation. I have seen it in practice...

[cy]

It is using SecureRandom that reads /dev/random by default

[cy]

It's quite easy to see it

[cy]

Some distributions doesn't have haveged so you can face it

[mp]

with modern CSPRNGs there is a basically unlimited supply of randomness once the pool has been initialized, but not everyone is using those...

[cy]

oops, sorry for offtop

[mp]

true that 🙂 Hopefully this digression was informative

[mp]

For more about CSPRNG / /dev/random / etc, see archives of http://www.metzdowd.com/mailman/listinfo/cryptography

[mp]

there was a HUGE thread a few months back that dug deep

[dave08]

@enleur @kenkyee There' an open pull request for Micrometer.io, it would be great to have feedback and I could finish it up. I use it internally, but it would be nice to provide the main metrics people use https://github.com/ktorio/ktor/pull/480

[enleur]

@dave08 I think it should go as a separate package to avoid io.dropwizard.metrics dependencies

[dave08]

True, would you know how to seperate them? I don't really know advanced Gradle well enough... @enleur. Otherwise, anything else missing? I was about to add a histogram, but not sure if it's better for the user to configure them according to their own SLAs...

[enleur]

@dave08 https://gist.github.com/enleur/f9e0fb7da9496464bc76132d74e910e1 check our solution, might help

[dave08]

Thanks, I'll a look as soon as a have a chance 🙂