tedsuo

Btw, if you are interested in distributed tracing, including the W3C and opentelemetry, we blog a weekly roundup about it here: https://lightstep.com/blog/category/distributed-tracing/

Actually, OpenTelemetry is compatible with OpenTracing, so the boom is still relevant. The distributed tracing APIs are very similar, but OpenTelemtry also includes metrics.

Thanks for rooting! I’m sorry it looks confusing. It took several iterations for the humans to converge on a single project, and achieve something like consensus about what we wanted. But it feels like we are there - there’s ~100 working on it now, and I don’t see any remaining blockers.

From the inside, it’s felt like steadily rolling up a larger and larger katamari ball, if you remember that game.

Yeah, it’s all getting stitched together. I would expect v1.0 of OpenTelemetry coming in March, with W3C Trace-Context headers as the default format for context propagation.

This is not true. I don’t like having my health care tied to my job - they are orthogonal concerns. But in the US, your employer does not have access to your healthcare records.

Imho, the interest is less about convenience, and more about reducing employment (fedex/amazon’s interest), combined with alphabet doing its reflexive moonshot thing. There isn’t a huge consumer demand for drones; like google glass, I expect that they will be taken aback at how negative the reaction is.

I suspect that fb is dialing back their ambitions with libra, to something that is more like a regular money transfer service. PayPal and other partners would naturally be less interested in that; it’s just more competition.

I posted this article because I found precise mobile tracking such as this to be a genuine privacy violation. IMHO, this is much more invasive that passively tracking web activity.

Cool beans!

Hi Mycoliza! One of the authors of OpenTelemetry here. It would be great to see an OpenTelemetry implementation in Rust. If you're interested in bootstrapping a group to work on that, please let me know!

The article only mentions Android. Does anyone know what the process is for iPhones at the border?

Can’t believe they didn’t mention the cherry (pepperoni?) on top: PepsiCo also got Gorbachev to huck some Pizza Hut for them: https://youtu.be/fgm14D1jHUw

It's getting started soon: https://github.com/open-telemetry/community/blob/master/comm...

We have a very performant prototype!

One usde case I am excited about: taking the OpenTelemetry C++ SDK, and binding it to the OpenTelemetry interfaces in other languages, such as Ruby and Python.

Some runtimes may see a performance boost by running the observability code independently from the GIL, GC, etc.

Hi all! Author here; happy to answer any questions about the OpenTelemetry merger.

Contracts aside there’s a real issue: the human is there primarily to deal with other humans and all the random issues that pop up (which, as a regular bart rider, I assure you are plentiful).

You could shift the model around and maybe have a “station attendant” rather than a “driver,” but it’s an issue that I don’t see addressed in many autonomous conversations. The bus driver doesn’t just drive the bus, they also regulate and deal with all the bullshit happening on and around the bus.

Automation-in-public has so many issues beyond it’s closed-course equivalent, where you simply have to drive the vehicle. It will be a much bigger adjustment than just high quality autopilot.

This gets at my concern though - it is not that we don’t know how to build skyscrapers safely. It is that there is now positive evidence that those construction and engineering techniques are not being applied properly, at least in some cases.

For me, the question is not about whether high quality projects are going to be okay. The question is: on what basis do I believe there has been sufficient oversight to guarantee the soundness of new construction?

I can remember talking to SPUR members in 2001 about how problematic it was to extend downtown development into SOMA, etc, due to liquefaction and uncertainty. When the building craze hit, it felt like it brushed these concerns aside, rather than answer them. Now we have leaning buildings that don’t meet basic construction requirements. It doesn’t inspire a lot of faith.

For those without a WSJ account: http://archive.is/PZ4YB

Yes!! We are very interested in resolving these API differences. In my opinion OpenCensus is great and if it could become the “standard” client for OpenTracing it would make me really happy.

If you’re interested in getting involved, we’re kicking off a documentation overhaul and looking for language maintainers (especially ruby), come say hi in our gitter channel if you’re interested or have any questions! https://gitter.im/opentracing/public

One of the big arguments against public transit is that it's infeasible to dig tunnels. If this project succeeds, I wonder what kind of contorted logic will arise, arguing that digging tunnels for cars is feasible, but digging tunnels for subways is still infeasible?

I'm not sure that the person you're responding to is advocating for guns. They are just pointing out that violent people don't stop being violent just because guns are removed from the picture.

For example, handguns and other concealable weapons were almost non-existent in Australia when I was living there. As a side effect, there were a lot of fistfights; far more than I've ever seen at equivalent bars/pubs in the US. That sucked, but I still found it preferable to being shot/mugged at gunpoint.

Likewise, acid attacks are terrible, and there are possibly more of them since guns and knives are less accessible. Doesn't mean that overall things are worse because of the ban.

I like Andrew Ng... but multiple upvotes for a placeholder site with no content or explanation? Really?

I recommend separating collection from instrumentation. Always instrument at the source, so that you can instrument the flow of your entire application. If the caller decides there is something about the code flow that is worth recording, it can trigger collection of the entire trace.

^ EDIT: Since this is the top comment, I should clarify that I don’t think the author is dumb or anything; 1. in particular is fairly common advice. The issue is not the error wrapping itself, but the smell that your logging solution is probably not recording causality.

And as for 2., I recall a hilarious incident with an email alert turning a deployment into a spambot, so... :)

The most common problem is that code executing at that point can hang in unexpected ways, preventing shutdown. It's a real bummer when that happens. I've even seen it happen with logging written the wrong way, where the code attempts to flush the logs to ensure they are written... and hangs.

Meanwhile, the crazy code that panicked is still running it's other goroutines - remember, you called recover! - so maybe now the webserver still has an open port and is allowing your users to access whatever strange state is left inside... gonzo things really can happen if you let a corrupted program stay on rather than shutting it down immediately. Even if nothing bad is happening, you still are out of commission for that entire period.

The point is, murphy's law always comes into play. So if we're talking about production best practices, consider that "most likely fine" means "definitely not fine at scale over time". Just make sure that whatever you're doing during shutdown can't block.

I totally agree, there's no need to log that you bubbled an error. My recommendation is to have the function that generates the error also log it internally. That way, you don't need to log any returned errors at all, unless you are calling a 3rd party library that can't log it's own error.

Oh god, there is some terrible advice in that article.

1. Don’t wrap errors, log.

Errors have two purposes - control flow for your application, and information for the developer and operator. If you are already logging the flow of your program, there is no need to wrap an error and create a call stack - you already have the call stack. If you cannot follow the control flow from your logs, you need to improve your logging, because you will also need to debug production problems that do not produce a literal error object.

And if you want more causality than you can get out of your logging, consider upgrading from logging to tracing. I contribute to http://opentracing.io so naturally that’s the tracing API I would suggest you look at.

2. Do not do anything with panics except recover from them or exit.

If you have a panic that you cannot recover from (and in general, that should be all of them), then it means your application is in a unknowable state. While Go is not as unsafe as C, any and all state in your program could be bad, and it is completely unclear what is still working and what is not. Nothing you do at this point is safe. For the love of god, do not hang your application and prevent it from exiting by trying to send a Slack message. Your goal should be to restart your program from a fresh clean state as quickly as possible, not to tie it up on the way out. Let the program exit and have an external monitoring program, whose state is NOT corrupted because its in a separate process, do all of the triage and reporting.

Good tip, though I always feel a pang of irony when I learn something like this while procrastinating.

Another set of masterful distributed system engineers you can look at are the US founding fathers. Like any implementation, it's far from perfect, but I marvel at a system of government with enough fault tolerance, failover, and backups built in to survive as long as it has.

you don't need a range or a channel to iterate over a collection or read a stream to the end.