mfikes

(ns api-server.file-io
  (:use [clojure.tools.logging :only (info warn error)])
  (:import (java.nio.channels CompletionHandler AsynchronousFileChannel)
           (java.nio ByteBuffer)
           (java.nio.file.attribute FileAttribute)
           (java.nio.file StandardOpenOption)
           (java.util.concurrent Executors))
  (:require [clojure.core.async :as async :refer [chan go put! close!]]
            [clojure.java.io :as io]))

codefromthecrypt

I've had many people ask me questions about OpenTracing, often in relation to OpenZipkin. I've seen assertions about how it is vendor neutral and is the lock-in cure. This post is not a sanctioned, polished or otherwise muted view, rather what I personally think about what it is and is not, and what it helps and does not help with. Scroll to the very end if this is too long. Feel free to add a comment if I made any factual mistakes or you just want to add a comment.

So, what is OpenTracing?

OpenTracing is documentation and library interfaces for distributed tracing instrumentation. To be "OpenTracing" requires bundling its interfaces in your work, so that others can use it to time distributed operations with the same library.

So, who is it for?

OpenTracing interfaces are targeted to authors of instrumentation libraries, and those who want to collaborate with traces created by them. Ex something started a trace somewhere and I add a notable event to that trace. Structure logging was recently added to O