Adrian's comments
diff --git a/Gemfile.lock b/Gemfile.lock
index bad7b96..49f79dd 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -21,14 +21,14 @@
multipart-post (>= 1.2, < 3)
ffi (1.9.10)
gemoji (2.1.0)
- github-pages (66)
+ github-pages (67)
RedCloth (= 4.2.9)
github-pages-health-check (= 1.1.0)
jekyll (= 3.0.3)
jekyll-coffeescript (= 1.0.1)
jekyll-feed (= 0.4.0)
jekyll-gist (= 1.4.0)
- jekyll-github-metadata (= 1.9.0)
+ jekyll-github-metadata (= 1.10.0)
jekyll-mentions (= 1.1.2)
jekyll-paginate (= 1.1.0)
jekyll-redirect-from (= 0.10.0)
@@ -68,7 +68,7 @@
jekyll-feed (0.4.0)
jekyll-gist (1.4.0)
octokit (~> 4.2)
- jekyll-github-metadata (1.9.0)
+ jekyll-github-metadata (1.10.0)
octokit (~> 4.0)
jekyll-mentions (1.1.2)
html-pipeline (~> 2.3)
@@ -112,7 +112,7 @@
redcarpet (3.3.3)
rouge (1.10.1)
safe_yaml (1.0.4)
- sass (3.4.21)
+ sass (3.4.22)
sawyer (0.7.0)
addressable (>= 2.3.5, < 2.5)
faraday (~> 0.8, < 0.10)
@@ -127,8 +127,8 @@
ruby
DEPENDENCIES
- github-pages (= 66)
+ github-pages (= 67)
json
BUNDLED WITH
- 1.11.2
+ 1.12.0.pre.2
diff --git a/index.md b/index.md
index c3932fa..2541962 100644
--- a/index.md
+++ b/index.md
@@ -6,17 +6,12 @@
Zipkin is a distributed tracing system. It helps gather timing data needed to
-troubleshoot latency problems in micro-service architectures. It manages both the
-collection and lookup of this data through a Collector and a Query service.
+troubleshoot latency problems in microservice architectures. It manages both the
+collection and lookup of this data.
Zipkin’s design is based on the
[Google Dapper](http://research.google.com/pubs/pub36356.html) paper.
-Collecting traces helps developers see how
-requests are perform in a distributed system. For example, if we’re having problems with
-user requests timing out, we can look up traced requests that timed out and
-display these in the web UI. We’ll be able to quickly find the service responsible
-for adding the unexpected response time. If the service has been annotated
-adequately, we can also find out where in that service the issue is happening.
+Applications are instrumented to report timing data to Zipkin. The Zipkin UI also presents a Dependency diagram showing how many traced requests went through each application. If you are troubleshooting latency problems or errors, you can filter or sort all traces based on the application, length of trace, annotation, or timestamp. Once you select a trace, you can see the percentage of the total trace time each span takes which allows you to identify the problem application.
## Where to go next?
diff --git a/pages/existing_instrumentations.md b/pages/existing_instrumentations.md
index 46e80d9..33581a5 100644
--- a/pages/existing_instrumentations.md
+++ b/pages/existing_instrumentations.md
@@ -4,8 +4,8 @@
---
Tracing information is collected on each host using the instrumented libraries
-and sent to Zipkin. When the host makes a request to another service, it passes
-a few tracing identifiers along with the request so we can later tie the data
+and sent to Zipkin. When the host makes a request to another application, it passes
+a few tracing identifiers along with the request to Zipkin so we can later tie the data
together into spans.
The following libraries exist to provide instrumentation on various platforms.
diff --git a/pages/instrumenting.md b/pages/instrumenting.md
index 2ff1002..78765c4 100644
--- a/pages/instrumenting.md
+++ b/pages/instrumenting.md
@@ -52,7 +52,7 @@
**BinaryAnnotation**
Binary annotations do not have a time component. They are meant to provide extra
-information about the RPC. For instance, when calling an HTTP service providing
+information about the RPC. For instance when calling an HTTP service, providing
the URI of the call will help with later analysis of requests coming into the
service.
@@ -72,7 +72,7 @@
Trace identifiers
=====
-In order to reassmble a set of spans into a full trace three pieces of
+In order to reassemble a set of spans into a full trace three pieces of
information are required. These are all 64 bits long.
**Trace Id**
@@ -115,27 +115,25 @@
-------------------------------
Trace information needs to be passed between upstream and downstream services in
-order to reassemble a complete trace. Five pieces of information are required:
+order to reassemble a complete trace. Five pieces of information are required:
* Trace Id
* Span Id
* Parent Id
-* Sampled
-* Flags
-
-"Sampled" lets the downstream service know if it should record trace
+* Sampled - Lets the downstream service know if it should record trace
information for the request.
-
-"Flags" provide the ability to create and communicate feature flags. This is how
+* Flags - Provides the ability to create and communicate feature flags. This is how
we can tell downstream services that this is a "debug" request.
-Finagle provides mechanisms for passing this information with Http and Thrift
+Check [here](https://github.com/openzipkin/brave/blob/e474ed1e1cd291c7ebc6830c58fdba0a6318fdd2/brave-http/src/main/java/com/github/kristofa/brave/http/BraveHttpHeaders.java) for the format
+
+Finagle provides mechanisms for passing this information with HTTP and Thrift
requests. Other protocols will need to be augmented with the information for
tracing to be effective.
-**Http Tracing**
+**HTTP Tracing**
-Http headers are used to pass along trace information:
+HTTP headers are used to pass along trace information.
The B3 portion of the header is so named for the original name of Zipkin:
BigBrotherBird.
diff --git a/pages/span_receivers.md b/pages/span_receivers.md
index fe6c893..d564dbc 100644
--- a/pages/span_receivers.md
+++ b/pages/span_receivers.md
@@ -1,20 +1,8 @@
---
-title: Span Receivers
+title: Transports
---
-A `SpanReceiver` is responsible for collecting spans from services, converting
+A transport is responsible for collecting spans from services, converting
them to a Zipkin common Span, and passing them to the storage layer. This
-approach is modular which allows for receivers that accept any type of data
-from any producer. Zipkin comes with a receiver for Scribe and one for
-Kafka.
-
-Scribe Receiver
----------------
-
-Scribe was the logging framework in use at Twitter to transport trace data when
-Zipkin was created.
-
-For small architectures, tracers can be setup to send directly to the Zipkin
-collectors. The `ScribeSpanReceiver` expects a Scribe log entry with a Base64-encoded, binary serialized thrift Span using the "zipkin" category. This
-category is configurable via a command line flag. Finagle-Zipkin does this
-automatically.
+approach is modular which allows for transports that accept any type of data
+from any producer. Zipkin comes with transports for HTTP, Kafka, and Scribe.
