Download the PHP package icyboy/zipkin without Composer
On this page you can find all versions of the php package icyboy/zipkin. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download icyboy/zipkin
More information about icyboy/zipkin
Files in icyboy/zipkin
Informations about the package zipkin
Zipkin instrumentation for PHP
This is a production ready PHP library for Zipkin.
This is a simple example of usage, for a more complete frontend/backend example, check this repository.
Installation
Setup
Tracing
The tracer creates and joins spans that model the latency of potentially distributed work. It can employ sampling to reduce overhead in process or to reduce the amount of data sent to Zipkin.
Spans returned by a tracer report data to Zipkin when finished, or do nothing if unsampled. After starting a span, you can annotate events of interest or add tags containing details or lookup keys.
Spans have a context which includes trace identifiers that place it at the correct spot in the tree representing the distributed operation.
Local Tracing
When tracing local code, just run it inside a span
In the above example, the span is the root of the trace. In many cases,
you will be a part of an existing trace. When this is the case, call
newChild
instead of newTrace
Customizing spans
Once you have a span, you can add tags to it, which can be used as lookup keys or details. For example, you might add a tag with your runtime version.
RPC tracing
RPC tracing is often done automatically by interceptors. Under the scenes, they add tags and events that relate to their role in an RPC operation.
Here's an example of a client span:
One-Way tracing
Sometimes you need to model an asynchronous operation, where there is a
request, but no response. In normal RPC tracing, you use $span->finish()
which indicates the response was received. In one-way tracing, you use
$span->flush()
instead, as you don't expect a response.
Here's how a client might model a one-way operation
And here's how a server might handle this...
Sampling
Sampling may be employed to reduce the data collected and reported out of process. When a span isn't sampled, it adds no overhead (noop).
Sampling is an up-front decision, meaning that the decision to report data is made at the first operation in a trace, and that decision is propagated downstream.
By default, there's a global sampler that applies a single rate to all
traced operations. Sampler
is how you indicate this,
and it defaults to trace every request.
Custom sampling
You may want to apply different policies depending on what the operation is. For example, you might not want to trace requests to static resources such as images, or you might want to trace all requests to a new api.
Most users will use a framework interceptor which automates this sort of policy. Here's how they might work internally.
Propagation
Propagation is needed to ensure activity originating from the same root are collected together in the same trace. The most common propagation approach is to copy a trace context from a client sending an RPC request to a server receiving it.
For example, when an downstream Http call is made, its trace context is sent along with it, encoded as request headers:
The names above are from B3 Propagation, which is built-in to Brave and has implementations in many languages and frameworks.
Most users will use a framework interceptor which automates propagation. Here's how they might work internally.
Here's what client-side propagation might look like
Here's what server-side propagation might look like
Extracting a propagated context
The Extractor
reads trace identifiers and sampling status
from an incoming request or message. The carrier is usually a request object
or headers.
SamplingFlags|TraceContext
is usually only used with $tracer->newChild(extracted)
, unless you are
sharing span IDs between a client and a server.
Implementing Propagation
Extractor
will output a SamplingFlags|TraceContext
with one of the following:
TraceContext
if trace and span IDs were present.SamplingFlags
if no identifiers were present
Current Span
Zipkin supports a "current span" concept which represents the in-flight
operation. Tracer::currentSpan()
can be used to add custom tags to a
span and Tracer::nextSpan()
can be used to create a child of whatever
is in-flight.
A common use case for the current span is to instrument RPC clients. For example:
Setting a span in scope manually
When writing new instrumentation, it is important to place a span you created in scope as the current span.
In edge cases, you may need to clear the current span temporarily. For
example, launching a task that should not be associated with the current
request. To do this, simply pass null to openScope
.
Tests
Tests can be run by