We’d like feedback on the `CallId` feature. If you...
# ktoro
orangy
09/19/2018, 10:35 AM
We’d like feedback on the
CallIde
enleur
09/19/2018, 11:04 AMwe have our own version of that feature, but planning to replace with Jaeger/Zipkin solution
enleur
09/19/2018, 11:05 AMalso we have micrometer.io integration to provide prometheus endpoint, which is almost standard in kubernetes environment
o
orangy
09/19/2018, 11:08 AM
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-TraceIde
enleur
09/19/2018, 11:25 AMI hope so. Now i’m using something like this https://gist.github.com/enleur/9e65fa005cbb881176df282aa63f8bd0
c
cy
09/19/2018, 12:30 PMIt will be something like this for now
Copy code
install(CallLogging) {
mdc("span_id") { call -> call.request.header("X─B3-SpanId") ?: UUID.randomUUID().toString() }
}👍 1
k
kenkyee
09/19/2018, 1:03 PMMicrometer is a good facade to hook in
c
cy
09/19/2018, 1:15 PM@enleur please note that
UUID.randomUUID()m
mp
09/19/2018, 1:19 PManother 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
09/19/2018, 1:20 PMYou only use the entropy pool once at initialization, so you won't block later.
c
cy
09/19/2018, 1:21 PMOn server you may need haveged to avoid it
m
mp
09/19/2018, 1:21 PMhavaged is no longer recommended btw
mp
09/19/2018, 1:22 PMunfortunately 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
09/19/2018, 1:23 PMI think OpenBSD was the first to do it mostly right, but newish Linux + glibc also have support IIRC
e
enleur
09/19/2018, 1:23 PM@cy it’s not really blocking, it’s just CPU intensive operation 🙂
m
mp
09/19/2018, 1:23 PMIt can block on entropy pool starvation. I have seen it in practice...
c
cy
09/19/2018, 1:23 PMIt is using SecureRandom that reads /dev/random by default
cy
09/19/2018, 1:24 PMIt's quite easy to see it
cy
09/19/2018, 1:24 PMSome distributions doesn't have haveged so you can face it
m
mp
09/19/2018, 1:25 PMwith modern CSPRNGs there is a basically unlimited supply of randomness once the pool has been initialized, but not everyone is using those...
c
cy
09/19/2018, 1:25 PMoops, sorry for offtop
m
mp
09/19/2018, 1:26 PMtrue that 🙂 Hopefully this digression was informative
mp
09/19/2018, 1:27 PMFor more about CSPRNG / /dev/random / etc, see archives of http://www.metzdowd.com/mailman/listinfo/cryptography
mp
09/19/2018, 1:27 PMthere was a HUGE thread a few months back that dug deep
d
dave08
09/20/2018, 2:37 AM@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
e
enleur
09/20/2018, 7:48 AM@dave08 I think it should go as a separate package to avoid io.dropwizard.metrics dependencies
➕ 1
d
dave08
09/20/2018, 7:56 AMTrue, 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...
e
enleur
09/20/2018, 8:06 AM@dave08 https://gist.github.com/enleur/f9e0fb7da9496464bc76132d74e910e1 check our solution, might help
d
dave08
09/20/2018, 5:13 PMThanks, I'll a look as soon as a have a chance 🙂