Zipkin is a distributed tracing system

Overview

zipkin

Gitter chat Build Status Maven Central

Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data.

If you have a trace ID in a log file, you can jump directly to it. Otherwise, you can query based on attributes such as service, operation name, tags and duration. Some interesting data will be summarized for you, such as the percentage of time spent in a service, and whether or not operations failed.

Trace view screenshot

The Zipkin UI also presents a dependency diagram showing how many traced requests went through each application. This can be helpful for identifying aggregate behavior including error paths or calls to deprecated services.

Dependency graph screenshot

Application’s need to be “instrumented” to report trace data to Zipkin. This usually means configuration of a tracer or instrumentation library. The most popular ways to report data to Zipkin are via http or Kafka, though many other options exist, such as Apache ActiveMQ, gRPC and RabbitMQ. The data served to the UI is stored in-memory, or persistently with a supported backend such as Apache Cassandra or Elasticsearch.

Quick-start

The quickest way to get started is to fetch the latest released server as a self-contained executable jar. Note that the Zipkin server requires minimum JRE 8. For example:

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar

You can also start Zipkin via Docker.

# Note: this is mirrored as ghcr.io/openzipkin/zipkin
docker run -d -p 9411:9411 openzipkin/zipkin

Once the server is running, you can view traces with the Zipkin UI at http://your_host:9411/zipkin/.

If your applications aren't sending traces, yet, configure them with Zipkin instrumentation or try one of our examples.

Check out the zipkin-server documentation for configuration details, or Docker examples for how to use docker-compose.

Zipkin Slim

The slim build of Zipkin is smaller and starts faster. It supports in-memory and Elasticsearch storage, but doesn't support messaging transports like Kafka or RabbitMQ. If these constraints match your needs, you can try slim like below:

Running via Java:

curl -sSL https://zipkin.io/quickstart.sh | bash -s io.zipkin:zipkin-server:LATEST:slim zipkin.jar
java -jar zipkin.jar

Running via Docker:

# Note: this is mirrored as ghcr.io/openzipkin/zipkin-slim
docker run -d -p 9411:9411 openzipkin/zipkin-slim

Core Library

The core library is used by both Zipkin instrumentation and the Zipkin server. Its minimum Java language level is 6, in efforts to support those writing agent instrumentation.

This includes built-in codec for Zipkin's v1 and v2 json formats. A direct dependency on gson (json library) is avoided by minifying and repackaging classes used. The result is a 155k jar which won't conflict with any library you use.

Ex.

// All data are recorded against the same endpoint, associated with your service graph
localEndpoint = Endpoint.newBuilder().serviceName("tweetie").ip("192.168.0.1").build()
span = Span.newBuilder()
    .traceId("d3d200866a77cc59")
    .id("d3d200866a77cc59")
    .name("targz")
    .localEndpoint(localEndpoint)
    .timestamp(epochMicros())
    .duration(durationInMicros)
    .putTag("compression.level", "9");

// Now, you can encode it as json
bytes = SpanBytesEncoder.JSON_V2.encode(span);

Note: The above is just an example, most likely you'll want to use an existing tracing library like Brave

Storage Component

Zipkin includes a StorageComponent, used to store and query spans and dependency links. This is used by the server and those making collectors, or span reporters. For this reason, storage components have minimal dependencies, but most require Java 8+

Ex.

// this won't create network connections
storage = ElasticsearchStorage.newBuilder()
                              .hosts(asList("http://myelastic:9200")).build();

// prepare a call
traceCall = storage.spanStore().getTrace("d3d200866a77cc59");

// execute it synchronously or asynchronously
trace = traceCall.execute();

// clean up any sessions, etc
storage.close();

In-Memory

The InMemoryStorage component is packaged in zipkin's core library. It is neither persistent, nor viable for realistic work loads. Its purpose is for testing, for example starting a server on your laptop without any database needed.

Cassandra

The Cassandra component uses Cassandra 3.11.3+ features, but is tested against the latest patch of Cassandra 3.11.

This is the second generation of our Cassandra schema. It stores spans using UDTs, such that they appear like Zipkin v2 json in cqlsh. It is designed for scale, and uses a combination of SASI and manually implemented indexes to make querying larger data more performant.

Note: This store requires a job to aggregate dependency links.

Elasticsearch

The Elasticsearch component uses Elasticsearch 5+ features, but is tested against Elasticsearch 6-7.x.

It stores spans as Zipkin v2 json so that integration with other tools is straightforward. To help with scale, this uses a combination of custom and manually implemented indexing.

Note: This store requires a spark job to aggregate dependency links.

Disabling search

The following API endpoints provide search features, and are enabled by default. Search primarily allows the trace list screen of the UI operate.

  • GET /services - Distinct Span.localServiceName
  • GET /remoteServices?serviceName=X - Distinct Span.remoteServiceName by Span.localServiceName
  • GET /spans?serviceName=X - Distinct Span.name by Span.localServiceName
  • GET /autocompleteKeys - Distinct keys of Span.tags subject to configurable whitelist
  • GET /autocompleteValues?key=X - Distinct values of Span.tags by key
  • GET /traces - Traces matching a query possibly including the above criteria

When search is disabled, traces can only be retrieved by ID (GET /trace/{traceId}). Disabling search is only viable when there is an alternative way to find trace IDs, such as logs. Disabling search can reduce storage costs or increase write throughput.

StorageComponent.Builder.searchEnabled(false) is implied when a zipkin is run with the env variable SEARCH_ENABLED=false.

Legacy (v1) components

The following components are no longer encouraged, but exist to help aid transition to supported ones. These are indicated as "v1" as they use data layouts based on Zipkin's V1 Thrift model, as opposed to the simpler v2 data model currently used.

MySQL

The MySQL v1 component uses MySQL 5.6+ features, but is tested against MariaDB 10.3.

The schema was designed to be easy to understand and get started with; it was not designed for performance. Ex spans fields are columns, so you can perform ad-hoc queries using SQL. However, this component has known performance issues: queries will eventually take seconds to return if you put a lot of data into it.

This store does not require a job to aggregate dependency links. However, running the job will improve performance of dependencies queries.

Running the server from source

The Zipkin server receives spans via HTTP POST and respond to queries from its UI. It can also run collectors, such as RabbitMQ or Kafka.

To run the server from the currently checked out source, enter the following. JDK 11 is required to compile the source.

# Build the server and also make its dependencies
$ ./mvnw -q --batch-mode -DskipTests --also-make -pl zipkin-server clean install
# Run the server
$ java -jar ./zipkin-server/target/zipkin-server-*exec.jar

Artifacts

Server artifacts are under the maven group id io.zipkin Library artifacts are under the maven group id io.zipkin.zipkin2

Library Releases

Releases are at Sonatype and Maven Central

Library Snapshots

Snapshots are uploaded to Sonatype after commits to master.

Docker Images

Released versions of zipkin-server are published to Docker Hub as openzipkin/zipkin and GitHub Container Registry as ghcr.io/openzipkin/zipkin. See docker for details.

Javadocs

https://zipkin.io/zipkin contains versioned folders with JavaDocs published on each (non-PR) build, as well as releases.

Comments
  • Simplified span2 format

    Simplified span2 format

    This is a proposal for a simpler json representation for tracers to use when reporting spans. This is a simplification of scope from what was formerly known as Zipkin v2 #939

    Scope

    The scope is only write, and only json. For example, this doesn't imply dropping support for using the same span ID across client and server RPC calls. It does imply converting this to the existing model at the point of collection.

    Format

    The following is the description of the simplified fields. Note that in the case of traceId it is fixed width vs variable. For 64-bit trace ids, simply pad left with 0s.

    {
      "traceId": 16or32lowerHexCharacters,
      "parentId": 16lowerHexCharactersOrAbsentForRoot,
      "id": 16lowerHexCharacters,
      "kind": enum(CLIENT|SERVER|Absent),
      "name": stringOrAbsent,
      "timestamp": uint53EpochMicrosOrAbsentIfIncomplete,
      "duration": uint53MicrosOrAbsentIfIncomplete,
      "localEndpoint": existingEndpointTypeOrAbsent,
      "remoteEndpoint": existingEndpointTypeOrAbsent,
      "annotations": [
        {"timestamp": uint53EpochMicros, "value": string},
        ...
      ],
      "tags": {
        string: string,
        ...
      },
      "debug": trueOrAbsent,
      "shared": trueOrAbsent
    }
    

    Span name and timestamps are allowed to be missing to support late data, which is an edge case when spans are reported twice due to timeouts. Like previous versions, an empty span or service name defers the decision (usually to the other side of a shared span).

    This format applied to a typical client span would look like this:

    {
      "kind": "CLIENT",
      "traceId": "00000000000000005af7183fb1d4cf5f",
      "parentId": "6b221d5bc9e6496c",
      "id": "352bff9a74ca9ad2",
      "name": "query",
      "timestamp": 1461750040359130,
      "duration": 63874,
      "localEndpoint": {
        "serviceName": "zipkin-server",
        "ipv4": "172.19.0.3",
        "port": 9411
      },
      "remoteEndpoint": {
        "serviceName": "mysql",
        "ipv4": "172.19.0.2",
        "port": 3306
      },
      "tags": {
        "sql.query": "select distinct foo from bar"
      }
    }
    

    Impact on tracers

    Tracers are the primary customers of this format, and in doing so they can have a closer alignment between field names and common operations. For example, the following is a "turing complete" span api which has almost direct mapping to this format.

    start()
    name(String name)
    kind(Kind kind)
    remoteEndpoint(Endpoint endpoint)
    annotate(String value)
    tag(String key, String value)
    finish()
    flush() <-- for reporting spans that didn't start and finish locally
    

    It is important to remind that this format does not in any way drop support for the existing one. So old tracers can continue to operate.

    Impact on servers

    Collectors will decode and convert the new spans into the existing span model, backfilling "cs" and "cr" annotations and the "sa" binary annotation to make it appear as if it were sent in the old format. In order to do so, they need to know how to read the format. Choosing only json makes this simpler.

    For http, we can add an endpoint or accept a media type header more specific than json. We could also choose a heuristic route. Kafka and similar systems which don't have headers would need a heuristic approach.

    A heuristic approach would be to look for new fields. For example, startTimestamp or finishTimestamp will always be present in spans, so this can be used to decide which parsing rules to apply.

    FAQ

    Why just json?

    This effort is geared at making tracer development simpler, and having the least scope possible to accomplish that. While thrift was supported in the old model, and has its merits, it is not a great format for people getting started, and it is very hard to debug. Those looking for reduced size of data can compress the spans before they are sent. Those who really like thrift can use the old model.

    Why not special-case the tracer's endpoint?

    The tracer's endpoint (localEndpoint) doesn't change from operation to operation, so you could reasonably ask why this isn't uploaded separate from the span data. The reason is that it lowers the scope of work. Many tracers report by adding spans to a queue flushed occasionally to a message producer. By keeping each span self-contained, this type of logic can be reused with no changes at all.

    Why not change the query api, too?

    This format is simpler because it removes the need to add the endpoint of the tracer to each annotation or tag. This simplification is possible in tracers as they have a one-one relationship with a traced service. At query time, a span can include both a client and a server, so it cannot be represented in this format.

    Why not just remove support for the old model?

    #939 started as an effort to change the semantics of spans to single-host, not just for upload, but also processing, storage and query. After a year of discussion, it is clear this is not a practical or pragmatic first step. Reasons include the benefits of the current model and a general lack of interest. This is a tactical alternative that provides many of the wins without the work of a big bang refactor.

    What about async spans?

    We recently started supporting async/one-way spans via "cs" -> "sr" annotations. Notice the span begins and ends with the request side of the RPC (there's no response sent by the server or received by the client). This translates to the new model as the following: clientSideSpan.start().flush() serverSideSpan.start().flush().

    enhancement model 
    opened by codefromthecrypt 80
  • Adds gRPC endpoint /zipkin.proto3.SpanService/Report

    Adds gRPC endpoint /zipkin.proto3.SpanService/Report

    This adds an opt-in gRPC endpoint for reporting spans. A request to the gRPC /zipkin.proto3.SpanService/Report service is the same proto used with our POST /api/v2/spans, Content-Type: application/x-protobuf endpoint: zipkin.proto3.ListOfSpans.

    This is currently disabled by default, as the feature is experimental. Enable it like so:

    $ COLLECTOR_GRPC_ENABLED=true java -jar zipkin.jar
    

    Under the scenes the runtime is the same as the POST endpoint (Armeria), and uses the same port (9411).


    former description:

    This PR is an offshoot of a discussion in openzipkin/zipkin-api#57 . There are a number of issues that need to be addressed before consideration of merge:

    • [x] Finalize the API and merge it into zipkin-api
    • [ ] Find a zero-duplication and zero-copy approach for the deserialization of spans on the server side
    • [x] Add additional configuration options for configuring the server (i.e. SSL)
    • [ ] Integration test with GCP
    • [ ] Performance testing

    Also, there is still some discussion about whether the project as a whole wants to support a gRPC endpoint in zipkin-server due to potential bloat. See the discussion in zipkin-api#57 for background.

    collector server 
    opened by ewhauser 62
  • Convert to armeria for http engine

    Convert to armeria for http engine

    This is mostly a shotgun attempt. The integration tests are likely failing as the spring boot runner likely wants to open a tomcat port which armeria would conflict with. Not sure about it actually. Anyway, this is a rough start.

    cc @trustin @anuraaga @huydx

    opened by codefromthecrypt 59
  • New datamodel using Cassandra-3.9

    New datamodel using Cassandra-3.9

    Discussions in https://github.com/openzipkin/zipkin/pull/1204 lead to an agreement that upgrading the C* datamodel and taking advantage of latest features may be the best path forward.

    Zipkin Cassandra clusters are expected to be dedicated clusters, therefore should be relatively free to upgrade.

    The new datamodel takes advantage of MATERIALIZED VIEWS and SASI (b-tree secondary indexes).

    It reduces 7 tables down to 2 tables. (Excluding the dependencies table.)

    The new schema is…

    
    CREATE TYPE IF NOT EXISTS endpoint (
        service_name text,
        ipv4         inet,
        ipv6         inet,
        port         smallint,
    );
    
    CREATE TYPE IF NOT EXISTS annotation (
        ts bigint,
        v  text,
        ep frozen<endpoint>
    );
    
    CREATE TYPE IF NOT EXISTS binary_annotation (
        k  text,
        v  blob,
        t  text,
        ep frozen<endpoint>
    );
    
    CREATE TABLE IF NOT EXISTS traces (
        trace_id            varint,
        ts_uuid             timeuuid,
        id                  bigint,
        ts                  bigint,
        span_name           text,
        parent_id           bigint,
        duration            bigint,
        annotations         list<frozen<annotation>>,
        binary_annotations  list<frozen<binary_annotation>>,
        all_annotations     text,
        PRIMARY KEY (trace_id, ts_uuid, id)
    )
        WITH CLUSTERING ORDER BY (ts_uuid DESC)
        AND compaction = {'class': 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy'}
        AND default_time_to_live =  604800;
    
    
    CREATE TABLE trace_by_service_span (
        service_name  text,      // service name
        span_name     text,      // span name, or blank for queries without span name
        bucket        int,       // time bucket, calculated as ts/interval (in microseconds), for some pre-configured interval like 1 day.
        ts            timeuuid,  // start timestamp of the span, truncated to millisecond precision
        trace_id      varint,    // trace ID
        duration      bigint,    // span duration, in microseconds
        PRIMARY KEY ((service_name, span_name, bucket), ts)
    )
       WITH CLUSTERING ORDER BY (ts DESC)
        AND compaction = {'class': 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy'}
        AND default_time_to_live =  259200;
    
    
    CREATE MATERIALIZED VIEW IF NOT EXISTS trace_by_service
        AS SELECT service_name, span_name, bucket, ts, trace_id FROM trace_by_service_span
                WHERE service_name is not null AND span_name is not null AND bucket is not null AND ts is not null
                PRIMARY KEY (service_name, bucket, span_name, ts)
            WITH CLUSTERING ORDER BY (bucket DESC, ts DESC)
        AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 'unchecked_tombstone_compaction': 'true', 'tombstone_threshold': '0.2'}
            AND default_time_to_live =  259200;
    
    CREATE CUSTOM INDEX ON traces (all_annotations) USING 'org.apache.cassandra.index.sasi.SASIIndex'
       WITH OPTIONS = {
        'mode': 'CONTAINS',
        'analyzed': 'true',
        'analyzer_class':'org.apache.cassandra.index.sasi.analyzer.NonTokenizingAnalyzer',
        'case_sensitive': 'false'
       };
    
    CREATE CUSTOM INDEX ON trace_by_service_span (duration) USING 'org.apache.cassandra.index.sasi.SASIIndex'
       WITH OPTIONS = {'mode': 'PREFIX'};
    
    opened by michaelsembwever 50
  • Support async spans

    Support async spans

    We've had many issues about representing one-way activity. This is an attempt to define the most semantic means to address this concern in zipkin v1.

    In zipkin, we have an RPC span, where two hosts participate. They participate by adding bookend annotations to a single span. This allows for many conveniences including hosts able to report incomplete work, and report in any order.

    For example, a typical RPC span is ["cs", "sr", "ss", "cr"], for a dual host (client+server) span, or either of its partial ones ["sr", "ss"](uninstrumented client) and ["cs", "cr"](uninstrumented server).

    The path of least resistance for async (half-duplex, or messaging), is to follow this model. This prevents us from needing to wait for a big-bang zipkin 2 release of the entire ecosystem.

    My proposal is to add a messaging span: "ms" and "mr".

    The message sender adds a "ms" when a one-way message is sent. They are free to add "ws" to indicate it going on the wire.

    The message receiver adds a "mr" when a one-way message is received. They are free to precede that with "wr" to indicate one being processed from the wire.

    This works like the RPC spans, but to pin it down, here are example spans.

    ["mr"] <- message received from an uninstrumented sender. The host of "mr" is the processor. ["ms"] <- message sent to an uninstrumented recipient, or the message was dropped. The host of "mr" is the sender. ["ms", "mr"] <- message sent and received from instrumented hosts. Similarly, the host of "ms" is the sender and the host of "mr" is the receiver.

    The duration of a complete messaging span can be a lot longer than an RPC span, potentially orders of magnitude longer than the processing time. Once we have a means to indicate this (via "ms" "mr"), we can teach the UI to collapse the timeline or do other tricks.

    Messaging spans need to be propagated, just like RPC ones. For example, storing the binary version of a trace id as metadata on the message is appropriate.

    This design adds pressure for "linked traces" especially when messages are needed to create a new outbound activity. This is out of scope of this design, but not precluded by it. In other words, we need to take on "linked traces" separately.

    Fixes #1189 Fixes #925

    enhancement model 
    opened by codefromthecrypt 49
  • Why is the data lost in elasticsearch ?

    Why is the data lost in elasticsearch ?

    I used the zipkin, kafka, and elasticsearch for testing. The elasticsearch was only a node. It wasn't problem that the data was transferred from kafka to zipkin, but the data is lost from zipkin to elasticsearch. I wrote 500000 log-data to kafka, but it was only 212162 in the elasticsearch. The data:

    [{"traceId":"ffffffffffffffff","name":"fermentum","id":"ffffffffffffffff","annotations":[{"timestamp":1466386794757000,"value":"sr","endpoint":{"serviceName":"semper","ipv4":"113.29.89.129","port":2131}},{"timestamp":1466386794757000,"value":"sagittis","endpoint":{"serviceName":"semper","ipv4":"113.29.89.129","port":2131}},{"timestamp":1466386794758000,"value":"montes","endpoint":{"serviceName":"semper","ipv4":"113.29.89.129","port":2131}},{"timestamp":1466386794758000,"value":"augue","endpoint":{"serviceName":"semper","ipv4":"113.29.89.129","port":2131}},{"timestamp":1466386794759000,"value":"malesuada","endpoint":{"serviceName":"semper","ipv4":"113.29.89.129","port":2131}},{"timestamp":1466386794760000,"value":"ss","endpoint":{"serviceName":"semper","ipv4":"113.29.89.129","port":2131}}],"binaryAnnotations":[{"key":"mollis","value":"hendrerit","endpoint":{"serviceName":"semper","ipv4":"113.29.89.129","port":2131}}]}]
    

    "ffffffffffffffff" was replaced in "1-5000000"; It was no regular!!!

    opened by liangman 49
  • RFC: Transition to 128bit trace ids (still 64bit span ids)

    RFC: Transition to 128bit trace ids (still 64bit span ids)

    Many times over the last years, we've had folks ask about 128 bit trace ids.

    There have been a few use-cases mentioned...

    • archiving traces longer than a couple days (concern with collisions when retrieving by id)
    • using externally generated ids as trace identifiers (ex AWS lambda UUID)
    • joining traces that have 128bit identifiers (ex Dapper/Cloud Trace now use 128bit trace ids)

    Doing this comes at a cost of figuring out how to do interop, but that's well-charted territory:

    • Zipkin already decouples trace ids from span/parent ids; This reduces scope to only trace ids.
    • Zipkin trace identifier encoding is hex, which is easy to widen and detect.
    • There exists practice of people padding 64bit ids to 128 bit, and bit choosing to reduce to 64 bit.
    • Cassandra and MySQL support blobs in key clauses, and elasticsearch can as easily index a hex string of length 16 as it can one of length 32.

    Practically speaking we'd need to do the following to make this possible:

    • B3 - Update both http and binary forms to optionally accept wider trace ids
    • Thrift - add an optional binary field to hold the wider id
    • Model - Add Span.Builder.traceId(blob) and pad .traceId(long) to fit 128bits
    • Storage
      • overload getTraceById to accept a 128bit blob.
      • add 128bit column to mysql
      • add 128bit index to cassandra
      • write both 64 and 128bit ids until Model v2

    Provided we don't creep scope to also change span, parent id encoding, I think we can actually do this, and end up with an incremental win on the model that can help us bridge into systems that use wider ids increasingly often.

    model 
    opened by codefromthecrypt 43
  • Save trace to permanent store

    Save trace to permanent store

    Ref: #1093 Quick (and dirty) implementation of save trace. Sending out for review to get some feedback.

    Following @adriancole suggestion of deploying Zipkin Server twice, one backed by regular datastore and one with permanent datastore.

    Adding Save Trace button on the UI. Clicking this butting will make an AJAX request to backend api /api/v1/save/trace/<trace_id>, and on receiving this request, zipkin server will pull spans for this trace, and POST them to permanent store using api /api/v1/spans

    Address of permanent datastore server can be configured by property zipkin.permanent.store

    enhancement ui 
    opened by naoman 41
  • Configurable cassandra driver's read timeout

    Configurable cassandra driver's read timeout

    On large datasets I've noticed frequent com.datastax.driver.core.OperationTimedOutException Default timeout is 12 seconds, which is quite small. Please add configuration flag for this parameter (for query service), so it can be overriden. Or provide a way to override it in config.

    enhancement cassandra 
    opened by drax68 40
  • Enhance UX of Searchbar and make code simpler and more streamlined

    Enhance UX of Searchbar and make code simpler and more streamlined

    resolve #3007

    I think the current search bar has the following problems

    • Because it uses external libraries such as react-select, the design and keyboard operations are not fully controlled by lens side.
    • The implementation is more complex than it needs to be.
    • The design is also a bit confusing (especially lookback and limit).
    • It is hard to make unit tests because its implementation is too complex.

    So I decided to reimplement it from scratch.

    This PR will accomplish the following

    • Independence from difficult-to-control external libraries.
    • Code will be simpler and the code lines will be fewer.
    • Become testable.
    • UI will probably be easier to understand.
    • It will be more extensible & customizable in the future because it does not depend on external libraries.
    • TypeScriptize search bar!

    GIFs

    Lookback

    lookback

    Searchbar

    searchbar

    enhancement ui 
    opened by tacigar 39
  • Migrate from okhttp to armeria

    Migrate from okhttp to armeria

    Fixes #2646

    I haven't gotten to skim through this myself yet, so there's probably silly cleanups needed still, but feel free to take an initial look too if you have time. I also haven't run the integration tests yet.

    In a followup PR, I'll probably migrate from moshi to jackson since we already depend on the latter through armeria / spring, so we can remove moshi and okio for a few hundred K of library savings. The fact that we don't natively use okio buffers now makes using moshi more complicated, and probably slower.

    opened by anuraaga 39
  • Update packages of Lens

    Update packages of Lens

    • Replace fortawesome(fontawesome) packages with Material-ui's icons.
      • Since material-ui/icons had similar icons, there was no need to add more dependency packages.
    • Remove enzyme packages.
      • It was used to test only one small component. Otherwise, testing-library was used instead, so we should follow that..
    • Update lingui packages to 3.15.0.
    • Update classnames to 2.3.2.
    • Update history to 5.3.0.
    • Update lodash to 4.17.21.
    • Update prop-types to 15.8.1.
    • Update recharts to 2.2.0.
    • Update shortid to 2.2.16.
    • Update styled-components to 5.3.6.
    • Update vizceral-react to 4.8.0.
    opened by tacigar 0
  • UI Search stops working

    UI Search stops working

    Describe the Bug

    I'm running Zipkin in a Kubernetes deployment and storing tracers in ELastic Search. All fine, but sometimes some miss behaviors happens, like:

    • Today, doing some basic researches to test query performance seems to make the application stops working. I literally did nothing, only researches, but it stopped working.
    • If I redeploy my deployment it looses the "link" between Zipkin and Elastic Search so I have to change the ES_INDEX variable to make it work again but it will create a new index from scratch.

    Response error and UI error

    image image

    The query

    [query](curl -X GET "http://zipkin.url/zipkin/api/v2/traces?serviceName=SERVICE_NAME&spanName=%2Fv6%2Fblock-account%2F%3Cstring%3Auser_ting%3E%2Fconfirm-block&limit=10" -H "accept: application/json")

    The log error

    it's the same for all the cases and situations when it stops**

    2022-12-05 22:19:17.942  WARN [/] 1 --- [orker-epoll-2-3] z.s.i.BodyIsExceptionMessage             : Unexpected error handling request.
    
    com.linecorp.armeria.server.RequestTimeoutException: null
            at com.linecorp.armeria.server.RequestTimeoutException.get(RequestTimeoutException.java:36) ~[armeria-1.17.2.jar:?]
            at com.linecorp.armeria.internal.common.CancellationScheduler.invokeTask(CancellationScheduler.java:467) ~[armeria-1.17.2.jar:?]
            at com.linecorp.armeria.internal.common.CancellationScheduler.lambda$setTimeoutNanosFromNow0$13(CancellationScheduler.java:293) ~[armeria-1.17.2.jar:?]
            at com.linecorp.armeria.common.RequestContext.lambda$makeContextAware$3(RequestContext.java:555) ~[armeria-1.17.2.jar:?]
            at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98) [netty-common-4.1.78.Final.jar:4.1.78.Final]
            at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:153) [netty-common-4.1.78.Final.jar:4.1.78.Final]
            at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) [netty-common-4.1.78.Final.jar:4.1.78.Final]
            at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) [netty-common-4.1.78.Final.jar:4.1.78.Final]
            at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) [netty-common-4.1.78.Final.jar:4.1.78.Final]
            at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:391) [netty-transport-classes-epoll-4.1.78.Final.jar:4.1.78.Final]
            at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) [netty-common-4.1.78.Final.jar:4.1.78.Final]
            at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.78.Final.jar:4.1.78.Final]
            at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.78.Final.jar:4.1.78.Final]
            at java.lang.Thread.run(Unknown Source) [?:?]
    

    Steps to Reproduce

    Deploy Zipkin through Kubernetes make it work and then just redeploy the Zipkin part. It won't be able to search the same index, you'll have to set the ES_INDEX variables with a completely different index name so it will get back to work.

    Expected Behaviour

    Sometimes we have to redeploy the Zipkin part because we have to increase heap memory, for example. If I do it, Zipkin stops working. I could be able to delete the deployment, recreate and all should work properly, unless I change the ES_INDEX variable on purpose.

    bug 
    opened by jeff-lemos 2
  • Specify color for application instead of it being generated from the name.

    Specify color for application instead of it being generated from the name.

    Feature

    Specify color for application instead of it being generated from the name. (/traces page)

    Rationale

    To cases are an issue

    1. two of our servers generate basically the same color
    2. We are starting to tag local logs with "local service 1", which makes it a different color. Its easier to follow if the same services is always the same color.

    Example Scenario

    In a system of micro serves there is likely to be app names that generate similar colors.

    enhancement 
    opened by sirmspencer 0
  • Not able to upgrade os packages of docker image

    Not able to upgrade os packages of docker image

    Describe the Bug

    When I want to update the os packages of the docker image, then I receive the following errors:

    • ERROR: ca-certificates-bundle-20220614-r2: trying to overwrite etc/ssl1.1/cert.pem owned by libcrypto1.1-1.1.1n-r0.
    • ERROR: ca-certificates-bundle-20220614-r2: trying to overwrite etc/ssl1.1/certs owned by libcrypto1.1-1.1.1n-r0.

    Steps to Reproduce

    Steps to reproduce the behavior:

    1. Create a dockerfile containing the following:
    FROM openzipkin/zipkin:2.23
    
    USER root
    RUN apk upgrade --no-cache
    
    USER zipkin
    
    1. Run the docker build command docker build -t test .

    Expected Behaviour

    The expected behaviour is that the packages are upgraded and the docker build does not fail.

    bug 
    opened by wim-de-groot 0
Releases(2.24.0)
  • 2.24.0(Dec 19, 2022)

    What's Changed

    • Revamp trace page by @tacigar in https://github.com/openzipkin/zipkin/pull/3486
    • Upgrade to latest docker image and update a few libraries with CVEs by @llinder in https://github.com/openzipkin/zipkin/pull/3488
    • Render ingress host by @tobihein in https://github.com/openzipkin/zipkin/pull/3483

    Full Changelog: https://github.com/openzipkin/zipkin/compare/2.23.19...2.24.0

    Source code(tar.gz)
    Source code(zip)
  • 2.23.19(Oct 5, 2022)

    What's Changed

    • Remove exception on traceIds of length 15 by @rogierslag in https://github.com/openzipkin/zipkin/pull/3471
    • Fix docker readme docker-compose links by @ikaila in https://github.com/openzipkin/zipkin/pull/3469
    • Upgrade to latest Java base container, update Armeria and Spring deps by @llinder in https://github.com/openzipkin/zipkin/pull/3472
    • fix some typos by @cuishuang in https://github.com/openzipkin/zipkin/pull/3464

    Full Changelog: https://github.com/openzipkin/zipkin/compare/2.23.18...2.23.19

    Source code(tar.gz)
    Source code(zip)
  • 2.23.18(Sep 21, 2022)

    What's Changed

    • Upgrade jackson and spring to resolve CVEs by @llinder in https://github.com/openzipkin/zipkin/pull/3462
    • Upgrade java base container by @llinder in https://github.com/openzipkin/zipkin/pull/3463

    Full Changelog: https://github.com/openzipkin/zipkin/compare/2.23.17...2.23.18

    Source code(tar.gz)
    Source code(zip)
  • zipkin-0.3.0(Jan 27, 2022)

  • 2.23.16(Jan 4, 2022)

    What's Changed

    • Fixes CVE-2021-44832 by @aegliv in https://github.com/openzipkin/zipkin/pull/3414

    New Contributors

    • @aegliv made their first contribution in https://github.com/openzipkin/zipkin/pull/3414

    Full Changelog: https://github.com/openzipkin/zipkin/compare/2.23.15...2.23.16

    Source code(tar.gz)
    Source code(zip)
  • 2.23.15(Dec 19, 2021)

    What's Changed

    • Update log4j to 2.17 to address CVE-2021-45105 in https://github.com/openzipkin/zipkin/pull/3411

    Full Changelog: https://github.com/openzipkin/zipkin/compare/2.23.14...2.23.15

    Source code(tar.gz)
    Source code(zip)
  • 2.23.14(Dec 16, 2021)

    What's Changed

    • Add Helm chart by @jonkerj in https://github.com/openzipkin/zipkin/pull/3378
    • Add Helm CD for linting PRs and releasing charts by @jonkerj in https://github.com/openzipkin/zipkin/pull/3398
    • log4j 2 fix for CVE-2021-44228 by @uzshao in https://github.com/openzipkin/zipkin/pull/3402
    • Upgrade Armeria to fix CVE-2021-43795 by @llinder in https://github.com/openzipkin/zipkin/pull/3403
    • Support docker image for s390x and bump base java container 15.0.5_p3 by @BbolroC in https://github.com/openzipkin/zipkin/pull/3384
    • Upgrade log4j to 2.16 with further CVE fixes by @llinder in https://github.com/openzipkin/zipkin/pull/3406

    New Contributors

    • @jonkerj made their first contribution in https://github.com/openzipkin/zipkin/pull/3378
    • @uzshao made their first contribution in https://github.com/openzipkin/zipkin/pull/3402
    • @BbolroC made their first contribution in https://github.com/openzipkin/zipkin/pull/3384

    Full Changelog: https://github.com/openzipkin/zipkin/compare/2.23.9...2.23.14

    Source code(tar.gz)
    Source code(zip)
  • 2.23.9(Dec 23, 2021)

    What's Changed

    • Bump 14 to 15 because of tomcat deps in 14 by @llinder in https://github.com/openzipkin/zipkin/pull/3395

    Full Changelog: https://github.com/openzipkin/zipkin/compare/2.23.8...2.23.9

    Source code(tar.gz)
    Source code(zip)
  • 2.22.1(Oct 31, 2020)

    Zipkin 2.22.1 starts publishing multi-architecture Docker images, also to GitHub Container Registry.

    Most of this effort is to help end users avoid Docker Hub pull rate limits that apply November 1st.

    If you want to change your build or deployment process to use a non rate-limited image, it is as easy as this:

    -docker run -d -p 9411:9411 openzipkin/zipkin-slim
    +docker run -d -p 9411:9411 ghcr.io/openzipkin/zipkin-slim
    

    OpenZipkin are a volunteer team. The work done here came in service to you and traded off days, evenings and weekends to deliver on time. If you are happy with the help you've had these last over 5 years, please ensure you've starred our repo or drop by to say thanks on gitter.

    If you have time to help us continue to serve others, please stop by on gitter with a suggestion of what you'd like to help with or a request for what might be a neat way to start. Our community has grown a lot over the years, but it is always in need of more hands!

    Multi-architecture Docker images

    Zipkin's Docker image is now available for arm64 architecture. This eases Raspberry Pi (RPI) K8s deployment and Amazon EKS on AWS Graviton2 as you no longer have to build your own image. This also enables users who use Zipkin in their build pipeline to be unblocked from switching to arm64.

    Zipkin's server is written in Java, and hosts web assets run in a client's browser. White there are a few optional native optimizations at the Netty (I/O) layer, it has no operating system or architecture restrictions. That said, a significant amount of our user base use our Docker images. These users are restricted to our OS and architecture choices, as manifest in the Docker build. To allow arm64 was a bigger change than it seemed. We use Alpine Linux and our JDK distribution had to change because Zulu (or former choice) didn't support arm64. Also, publishing multi-architecture seems simple, but it is definitely more complicated, especially on developer laptops. We had to perform significant build work, including use of buildx and qemu to emulate arm64 when not running it. Many thanks to the lead @adrianfcole and advice by @dmfrey, @odidev and @anuraaga.

    While users can now use arm64, our job isn't quite over. We also want to run our own build on Arm64! This allows us to do integration tests. While we surmounted some hurdles running our NPM build on Alpine, but @odidev noticed a blocker on [Cassandra](https://issues.apache.org/jira/browse/CASSANDRA-16212#]. After that, we'd still need to update our GitHub actions and Travis jobs to use the arch (ex for pull requests). If you are interested in this and can lend a hand, please say so on this issue.

    We now publish our Docker images to both Docker Hub and GitHub Container Registry

    Zipkin is a technology often integrated into other stacks. We've always been conscious about our impacts here. Apart from optional storage and messaging transports, we've never required a multi-image deployment even when Zipkin is run in different roles. This has helped you download (docker pull) less often.

    We also made the lower overhead "openzipkin/zipkin-slim" image, as well test Kafka and storage images which share layers. Our base layer uses a custom "jlinked" JRE image which is less than 100MB. We almost famously guard any changes to the server that would bloat anything. We aren't done, but our volunteers have put immense effort on your behalf to keep you pulling less and less often.

    Many open source developers were nervous for good reason about Docker Hub's usage policy starting November 1st. This implies three things for open source developers using Docker Hub (ex. docker pull openzipkin/zipkin).

    • you likely have to authenticate now
    • you are restricted to 200 pulls per 6hrs
    • images you make that aren't pulled in 6 months will (eventually) be purged

    The first point impacts people's pipelines. In any open community authenticating can be a pain. Using personal credentials for community work can feel conflicted. The second point is more dire. Many are simply not aware how often the pull from Docker Hub!

    For example, OpenZipkin community defines "latest", the default tag, as "latest release" meaning that if you run docker pull openzipkin/zipkin, it will only consume your pull request quota if you are rebuilding your image cache, or we released a new version. While we release new versions somewhat often, it isn't enough to worry about. However, many projects treat "latest" as every commit. This means depending on what image you depend on, it could change more than once per hour. To run tests in some projects require pulling such images. To amplify this, some developers volunteer time on many projects. The amplification of these factors means that a volunteer making no money at all can become forced into a subscription to pay for the privilege to do that.

    The final point on retention is also tricky. Many expect images to never disappear. While we always want people to upgrade, we don't want people to be surprised that something they've cached in house for a while cannot be rebuilt.

    OpenZipkin is and will always be free in spirit and practice. We will not force our volunteers or end users into any subscription. To address this issue quickly, we decided to publish images also to GitHub Container Registry. This is currently free and not rate-limited on consumption. If that changes, we will publish issues also to another registry :P

    For those reading this and wondering what this means, it means the following. Our primary source of images is now here. The top-level images, including our server and test backends are also pushed to Docker Hub for convenience.

    If you want to change your build or deployment process to use a non rate-limited image, it is as easy as this:

    -docker run -d -p 9411:9411 openzipkin/zipkin-slim
    +docker run -d -p 9411:9411 ghcr.io/openzipkin/zipkin-slim
    

    The full impact of this required a lot of change to our build process, even if GitHub Container Registry is pretty easy. For example, to set descriptions there, we had to add some standard labels to our images. While we were at it, we added more labels:

    docker inspect --format='{{json .Config.Labels}}'  ghcr.io/openzipkin/zipkin-slim|jq
    {
      "alpine-version": "3.12.1",
      "java-version": "15.0.1_p9",
      "maintainer": "OpenZipkin https://gitter.im/openzipkin/zipkin",
      "org.opencontainers.image.authors": "OpenZipkin https://gitter.im/openzipkin/zipkin",
      "org.opencontainers.image.description": "Zipkin slim distribution on OpenJDK and Alpine Linux",
      "org.opencontainers.image.source": "https://github.com/openzipkin/zipkin",
      "org.opencontainers.image.version": "2.22.1",
      "zipkin-version": "2.22.1"
    }
    

    This process was a lot of work and we thank @adriancole for the bulk of it. However, it was not possible without team input, particularly credential management and other knowledge sharing to make practice sustainable. Thanks also to @anuraaga @jorgheymans @jcchavezs and @abesto for inputs and review.

    Source code(tar.gz)
    Source code(zip)
  • 2.22.0(Oct 26, 2020)

    Zipkin 2.22 includes major improvements to the UI and Cassandra storage. It deprecates the v1 "cassandra" storage type, for the more modern "cassandra3" used for the last 2 years.

    Before we dive into features, we'd like to thank folks who are less often thanked. People whose impacts aren't always spectacular new features, but without which nothing would really work well.

    Features deliver while others need support. Our MVP @jorgheymans closed out over 60 issues since last release, while also doing a great amount of support on gitter. In cases change wasn't appropriate, you've noticed personal and thoughtful summaries. Jorg's work is a great example of community championship and we are grateful for his help.

    Features also require attention. Code review makes contributors feel less alone and the resulting change better. @anuraaga has reviewed over 80 pull requests since our last minor release. Especially UI code can feel alone sometimes, and Rag's thoughtful feedback on code has clearly helped @tacigar deliver more of it.

    Features need partnership. Zipkin's server, Elasticsearch and Stackdriver implementations are written in Armeria and @minwoox is our Armeria MVP. Min-Woo owned migration of Zipkin to Armeria 1.0 and again to 1.2, including glitches and experience improvements. Often these changes requires several rounds to polish and releases to coordinate. The only way this all worked was Min-Woo's ownership in both Armeria and our use of it.

    Features need good advice. We'd finally like to thank @xeraa from Elasticsearch, @adutra and @olim7t from Datastax, and @jeqo from Confluent. We've updated quite a lot of code that required expert insight into how backends work, or our use of their drivers, and roadmap items. Jorge has been particularly applied in this, developing features in Kafka that would allow better storage implementation. All these folks are excellent stewards and gave heaps of advice to help keep us on the right path, which in turn keeps implementations relevant for you.

    Let's now get on to some notable features in Zipkin 2.22

    UI improvements

    @tacigar led another great round of visible and invisible improvements to Zipkin's UI, Lens.

    The first thing you will notice is a renovated sidebar and header design. Controls and links moved to the top of the display, revealing significantly more white space below. Brighter text and a while underline hints subtly which screen you are on, leaving your attention for the results below it:

    List view

    The search controls are redesigned for effortless transitions between mouse and keyboard, or no mouse at all. Here's a search sequence using only the keyboard to execute a search. Search Bar UX

    Settings such as how far to look back and the time range have been tucked away neatly to reserve space. Don't worry though, all features are still around! Hidden controls

    Those interested in underneath will appreciate the migration to TypeScript, redux and react-use, which reduced the code involved and increased the quality. There are more features in store, such as how to better render span counts. Please help Igarashi-san and the team by providing your feedback. It matters and makes UI development less lonely!

    Cassandra

    Over two years ago @michaelsembwever designed and @llinder co-implemented the "cassandra3" storage type. This writes data natively in Zipkin v2 format, reducing translation overhead and improving CQL experience. This requires a minimum version of Cassandra 3.11.3, released over two years ago. We deprecated the "cassandra" storage type, otherwise known as "Cassandra v1", for removal in Zipkin 2.23.

    We hope you understand that limited resource means making hard decisions, and we don't take this lightly. However, we do feel two years is enough time to settle and please do contact us if you have concerns on gitter.

    Meanwhile we've overhauled the code so that we can use the more modern Datastax Driver v4. This came with thanks to @adutra and @olim7t who gave months of advice during the process. The good news is this puts us in a good place to focus on new features as Cassandra 4 readies for prime time.

    Docker

    All Zipkin images now have HEALTHCHECK instructions, which can be used in Docker natively or in readiness probes. We switched from Distroless back to Alpine to reduce image heft further. Zipkin 2.22 images run on the very latest: JRE 15 patch 1. We overhauled our docker-compose examples as well added a new repository of Java based examples. If you'd like to perform similar for other languages, please volunteer on gitter!

    Other news

    There are too many changes to detail all the last six months, but here's a summary of impactful ones to end users:

    • @ccharnkij added support for ES 7.8 composeable templates (with support by @xeraa!)
    • @fredy-virguez-adl made the UI show multi-line tags
    • @ronniekk corrected our docker health check
    • @anuraaga added Dev Tools instructions for UI development.
    • @jorgheymans added instructions on how to enable TLS on the server.
    • @jorgheymans added docs on Elasticsearch data retention
    • @jorgheymans and @jeqo added Kafka operational notes
    • @uckyk completed the chinese translation of our UI
    • @jeqo upgraded our Kafka drivers to latest version
    • @hanahmily made ES_CREDENTIALS_FILE work on the slim distribution
    • @adriancole added ES_SSL_NO_VERIFY for test environments
    Source code(tar.gz)
    Source code(zip)
  • 2.21.1(Apr 16, 2020)

    Zipkin 2.21 Adds an archive trace feature to the UI and dynamic Elasticsearch credentials support

    Archive Trace

    Sites like Yelp have multiple tiers of storage. One tier includes 100% traces at a short (an hour or less) TTL. Later are normal sampling, either via a rate limit or low percentage. Some sites even have a tier that never expires. In such setups, there is tension. For example, the 100% tier is great for customer support as they can always see traces. However, the traces can expire in the middle of the incident! who wants a dead link?! Even normal trace storage is typically bounded by 3-7 day TTL. This becomes troublesome in issue trackers like Jira as the link is again, not permanent.

    This problem is not as simple as it sounds. For example, it might seem correct to add tiering server-side. However, not all storage even support a TTL concept! Plus, multi-tiered storage is significantly more complex to reason with at the code abstraction vs the HTTP abstraction. @drolando from Yelp detailed these pros and cons, as well false starts here.

    The ultimate solution by Daniele, and adopted by the Zipkin team in general, was to leverage HTTP as opposed to bind to specific implementation code. In other words, everything is handled in the browser. This allows the archive target to not only be Zipkin, but anything that speaks its format including clones and vendors.

    You can now set the following properties to add an "Archive Trace" button"

    ZIPKIN_UI_ARCHIVE_POST_URL=https://longterm/api/v2/spans
    ZIPKIN_UI_ARCHIVE_URL=https://longterm/zipkin/trace/{traceId}
    

    These are intentionally different as some vendors have a different read back expression than zipkin, even when their POST endpoint is the same.

    When you click archive, you'll see a message like below confirming where the trace went, in case you want to copy/paste it into your favorite issue tracker.

    archive

    Many thanks to @drolando for making this feature a reality, as well @anuraaga @jcchavezs @jeqo @shakuzen and @tacigar who gave feedback that led to the polished end state.

    Dynamic Elasticsearch Credentials

    Our Elasticsearch storage component has supported properties based changes to credentials since inception. While few knew about it, this didn't imply env variables, as file based always worked. Even with this flexibility, those running a non-buffered transport (like Kafka) would drop data when there's a password change event. This is incidentally routinely the case as HTTP and gRPC are quite common span transports. @basvanbeek noticed that even though the server restarts quickly (seconds or less), this drop is a bad experience. It is becoming commonplace for file-based updates to push out through services like Vault, and the restart gap could be tightened.

    @hanahmily stepped in to make reading passwords more dynamic, something pretty incredible to do for a first-time committer! At the end of 2 weeks of revisions, Gao landed a very simple option that covers the requirements, closing the auth-fail gap to under a second.

    • ES_CREDENTIALS_FILE: An absolute path of the file.
    • ES_CREDENTIALS_REFRESH_INTERVAL: Refresh interval in seconds.

    Thanks very much to @anuraaga and @jorgheymans for all the feedback and teamwork to get this together.

    Minor changes

    • @jorgheymans added instructions for running lens behind a reverse proxy
    • @tacigar @anuraaga @drolando fixed a few UI glitches
    • ES_ENSURE_TEMPLATES=false is now available for sites who manage Elasticsearch schema offline
    • ZIPKIN_UI_DEPENDENCY_ENABLED=false is now available for sites who will never run zipkin-dependencies
    Source code(tar.gz)
    Source code(zip)
  • 2.20.0(Mar 3, 2020)

    Zipkin 2.20 is our first big release of 2020.

    Most notably, the Lens UI is now default, retiring the classic UI. This is a big deal for many sites, and your continued feedback is especially important now. Please send any praise, concern or questions to Gitter and add issues as appropriate.

    First, let's thank @eirslett and @zeagord for leading the last incarnation of the classic UI. Since @eirslett rewrote the former scala+javascript UI into a single-page, pure javascript 5 years ago, we had 38 contributors. @eirslett set the architecture in place for an order of magnitude more people to become involved, and for a new leader @zeagord to emerge. The classic UI had deceptively simple features, in so far as they are hard to replicate. This is evidenced by so few efforts managing to come close to feature parity, even with a lot of full time staff allocated to the task. Suffice to say, zipkin-classic is a very very good product and has a special place in the history of open source distributed tracing, especially volunteer open source.

    Next, let's thank LINE for contributing a new codebase to the project, and further the time of @tacigar to move mountains to push UX forward while simultaneously reaching for feature parity. Along the way, @drolando played MVP of testing, finding all the edge cases in practice at Yelp. Finally, we owe as a community a great thanks to @anuraaga who single-handedly filled all the remaining feature gaps to ensure this release would have the least disruption to you. The last year and a half has not been easy, but we think it has been worth it, as you can now reach a new UI without the trouble of a platform switch.

    While we noted MVPs, it is ultimately you, the end users and sites who have been with us years or only days. Please do engage if you have suggestions or contributions to offer. We're only a chat away!

    As a finale, let's look at a trace from Netflix from the last version of the classic UI and our new UI Lens. We think you'll agree, they are both good products. Here's to another 5 years!


    Classic

    Screenshot 2020-03-03 at 1 22 39 PM Screenshot 2020-03-03 at 1 22 47 PM Screenshot 2020-03-03 at 1 23 20 PM

    Lens

    Screenshot 2020-03-03 at 1 23 49 PM Screenshot 2020-03-03 at 1 24 07 PM Screenshot 2020-03-03 at 1 24 36 PM Source code(tar.gz)
    Source code(zip)
  • 2.19.2(Nov 19, 2019)

    This is a patch release that fixes a regression in handling of certain span names and adds a feature to control server timeout of queries.

    Bugfixes

    • JSON API response that includes whitespace in names (such as service names) correctly escapes strings #2915

    New Features

    • The QUERY_TIMEOUT environment variable can be set to a duration string to control how long the server will wait while serving a query (e.g., search for traces) before failing with a timeout. For example, when increasing the client timeout of Elasticsearch with ES_TIMEOUT it is often helpful to increase QUERY_TIMEOUT to a larger number so the server waits longer than the Elasticsearch client. #2809
    Source code(tar.gz)
    Source code(zip)
  • 2.19.1(Nov 1, 2019)

    Zipkin 2.19 completely revamps the "Lens" UI to help with large traces and large service graphs. This was a large effort with many thanks to @tacigar @bulicekj for coding, @anuraaga @dvkndn and @Imballinst reviewing and @drolando on Q/A and prod testing!

    Let's dive right in, using test data from SmartThings you can try yourself!

    After doing a search, you'll see a result of an elaborate trace. Notice our new logo is here now!

    Screenshot 2019-11-01 at 8 15 26 AM

    By clicking on this, you can scroll to the span of interest. Notice the annotation and tag details are on a collapsible panel on the right. Screenshot 2019-11-01 at 8 16 12 AM

    Notice, we've removed the mini-map, as we have a better way to get to a relevant place in the trace. In a large trace like this, causal relationships are not easy to see even if you can get to the right place quickly. Instead, we've implemented a "re-root" feature which allows you to pretend a large trace begins at a span of interest. Double-clicking the Bookie span now looks as if it was a smaller trace, much easier to understand. Double-clicking will reset back.

    Screenshot 2019-11-01 at 8 16 44 AM

    We've also cleaned up the dependencies screen. The normal search looks similar though a lot of refactoring has taken place under the covers.

    Screenshot 2019-11-01 at 8 17 15 AM

    As before, if you hovered over the "bookie" service, you can see connected relationships, as unconnected ones are greyed out

    Screenshot 2019-11-01 at 8 17 28 AM

    This may be a fine view for a graph of only a dozen services, but if there are hundreds or more, we have a similar problem to the trace screen. We're lucky that @bulicekj contributed an idea from the haystack-ui. Basically, with a filter list, we can perform a similar optimization on the dependencies screen as we do in the re-root screen. In this case, we also search for "bookie"

    Screenshot 2019-11-01 at 8 17 44 AM

    As mentioned above, this was a large effort, demanding a lot of code, review time, and practice from sites. If you enjoy this, star our repo or stop by and say thanks on gitter. Gitter is also a good place to suggest how we can improve, so that your ideas are the next to release!

    Minor updates

    We've had some minor updates worth mentioning also. For example, you can set ZIPKIN_UI_USE_LENS=true to always use Lens until it is default.

    • @jeqo fixed where we accidentally stopped publishing JVM metrics
    • @adriangonz updated our zipkin-junit base dependency from OkHttp 3.x to 4.x
    • @anuraaga implemented credential redaction when Elasticsearch logging is on
    • @jeqo updated to latest Armeria, adjusting for new blocking annotations
    • @drolando contributed a test trace from Yelp
    • @drolando upped the hard limit of cassandra span names from 1-10k.
    Source code(tar.gz)
    Source code(zip)
  • 2.18.3(Oct 23, 2019)

    Zipkin 2.18 refactors and migrates our docker images into the main repository and introduces the "zipkin-slim" distribution.

    openzipkin/docker-zipkin attic'd

    The openzipkin/docker-zipkin repository is no longer used after @anuraaga completed migration to publication in this repository. This simplifies step count for maintainers, employing DockerHub hooks as a part of an automated deployment flow. This also allows us to have better CI of our images

    zipkin-slim

    The slim build of Zipkin is smaller and starts faster. It supports in-memory and Elasticsearch storage, but doesn't support messaging transports like Kafka or RabbitMQ. If these constraints match your needs, you can try slim like below:

    Running via Java:

    curl -sSL https://zipkin.io/quickstart.sh | bash -s io.zipkin:zipkin-server:LATEST:slim zipkin.jar
    java -jar zipkin.jar
    

    Running via Docker:

    docker run -d -p 9411:9411 openzipkin/zipkin-slim
    

    This build is with thanks to a lot of help and review under the covers by @anuraaga and @jorgheymans. For example, Jorg helped reduce the size by changing from log4j2 to slf4j (log4j2's dependency size is quite large). Rag performed a lot of code work and review to apply shortcuts mentioned in @dsyer's spring boot startup bench project: https://github.com/dsyer/spring-boot-startup-bench. We had review help and troubleshooting also from @jeqo and @devinsba. It was truly a team effort. We also had a lot of work on the docker side by @anuraaga, who helped cut our image layer tremendously (~100M).

    Here is are stats on the version before we started bootstrap work (v 2.16.2). This is the "JVM running for" time best in 10 on the same host. Your mileage may vary.

    Type           | Invocation | Startup | Size
    -------------------------------------------
    zipkin         | Java       | 3.4s    | 55.4M
    zipkin         | Docker     | 5.9s    | 253M
    

    Here are the results using the latest version of Zipkin, also connecting to Elasticsearch storage.

    Type           | Invocation | Startup | Size
    -------------------------------------------
    zipkin         | Java       | 2.6s    | 52.3M
    zipkin         | Docker     | 4.1s    | 154M
    zipkin-slim    | Java       | 2.0s    | 21.6M
    zipkin-slim    | Docker     | 3.1s    | 122MB
    

    We hope you enjoy the snappier times. If you'd like to talk more about this, please jump on Gitter.

    Source code(tar.gz)
    Source code(zip)
  • 2.17.0(Sep 24, 2019)

    Zipkin 2.17 publishes a "master" Docker tag, adds a traceMany endpoint, and improves startup performance.

    Before we get into these features, let's talk about logo :) You'll notice our website has been sporting a new logo designed by LINE recently. Thanks to @making, you can see this when booting zipkin, too!

    Screenshot 2019-09-24 at 8 20 42 PM

    Publishing a "master" docker tag

    We've been doing docker images since 2015. One thing missing for a long time was test images. For example, if you wanted to verify Zipkin before a release in Docker, you'd have to build the image yourself. @anuraaga sorted that out by setting up automatic publication of the master branch as the tag "master" in docker.

    Ex. "latest" is the last release, "master" is the last commit.

    $ docker pull openzipkin/zipkin:master
    

    Probably more interesting to some is how he used this. With significant advice from @bsideup, @anuraaga setup integrated benchmarks of integrated zipkin servers. This allows soak tests without the usual environment volatility.

    https://github.com/openzipkin/zipkin/blob/master/benchmarks/src/test/java/zipkin2/server/ServerIntegratedBenchmark.java

    A keen eye will notice that these benchmarks literally run our sleuth example! This is really amazing work, so let's all thank Rag!

    Api for getting many traces by ID

    While the primary consumer of our api is the Lens UI, we know there are multiple 3rd party consumers. Many of these prefer external discovery of trace IDs and just need an api to grab the corresponding json.

    Here are some use cases:

    • out-of-band aggregations, such histograms with attached representative IDs
    • trace comparison views
    • decoupled indexing and retrieval (Ex lucene over a blob store)
    • 3rd party apis that offer stable pagination (via a cursor over trace IDs).

    of the api was made to me like other endpoints in the same namespace, and be easy to discover. We have a rationale document if you are interested in details.

    Thanks much for the code work from @zeagord and @llinder and api design review by @jcarres-mdsol @jeqo @devinsba and @jcchavezs!

    Quicker startup

    After hearing some complaints, we did a lot of digging in the last release to find ways to reduce startup time. For example, we found some folks were experiencing nearly 10 second delays booting up an instance of Zipkin, eventhough many were in the 3.5s range. Among many things, we turned off configuration not in use and deleted some dependencies we didn't need. Next, we directly implemented our supported admin endpoints with Armeria. Here are those endpoints in case you didn't read our README

    • /health - Returns 200 status if OK
    • /info - Provides the version of the running instance
    • /metrics - Includes collector metrics broken down by transport type
    • /prometheus - Prometheus scrape endpoint

    Off the bat, Zipkin 2.17 should boot faster. For example, one "laptop test" went from "best of 5" 3.4s down to under 3s with no reduction in functionality. While docker containers always start slower than java directly, you should see similar reductions in startup time there, too.

    For those still unsatisfied, please upvote our slim distribution which can put things in the 2s range with the same hardware, for those who are only using in-memory storage or Elasticsearch.

    While we know bootstrap time is unimportant to most sites, it is very important emotionally to some. We'd like to make things as fun as possible, and hope this sort of effort keeps things snappy for you!

    Source code(tar.gz)
    Source code(zip)
  • 2.16.2(Aug 26, 2019)

    Zipkin 2.16 includes revamps of two components, our Lens UI and our Elasticsearch storage implementation. Thanks in particular to @tacigar and @anuraaga who championed these two important improvements. Thanks also to all the community members who gave time to guide, help with and test this work! Finally, thanks to the Armeria project whose work much of this layers on.

    If you are interested in joining us, or have any questions about Zipkin, join our chat channel!

    Lens UI Revamp

    As so much has improved in the Zipkin Lens UI since 2.15, let's look at the top 5, in order of top of screen to bottom. The lion's share of effort below is with thanks to @tacigar who has put hundreds of hours effort into this release.

    To understand these, you can refer to the following images which annotate the number discussed. The first image in each section refers to 2.15 and the latter 2.16.2 (latest patch at the time)

    2 15 search 2 16 search 2 15 detail 2 16 detail 2 15 dependencies 2 16 dependencies

    1. Default search to 15minutes, not 1 hour, and pre-can 5 minute search

    Before, we had an hour search default which unnecessarily hammers the backend. Interviewing folks, we realized that more often it is 5-15minutes window of interest when searching for traces. By changing this, we give back a lot of performance with zero tuning on the back end. Thanks @zeagord for the help implementing this.

    2. Global search parameters apply to the dependency diagram

    One feature of Expedia Haystack we really enjoy is the global search. This is where you can re-use context added by the user for trace queries, for other screens such as network diagrams. Zipkin 2.16 is the first version to share this, as before the feature was stubbed out with different controls.

    3. Single-click into a trace

    Before, we had a feature to preview traces by clicking on them. The presumed use case was to compare multiple traces. However, this didn't really work as you can't guarantee traces will be near eachother in a list. Moreover, large traces are not comparable this way. We dumped the feature for a simpler single-click into the trace similar to what we had before Lens. This is notably better when combined with network improvements described in 5. below.

    4. So much better naming

    Before, in both the trace list and also detail, names focused on the trace ID as opposed to what most are interested in (the top-level span name). By switching this out, and generally polishing the display, we think the user interface is a lot more intuitive than before.

    5. Fast switching between Trace search and detail screen.

    You cannot see 5 unless you are recording, because the 5th is about network performance. Lens now shares data between the trace search and the trace detail screen, allowing you to quickly move back and forth with no network requests and reduced rendering overhead.

    2 15 network 2 16 network

    Elasticsearch client refactor

    Our first Elasticsearch implementation allowed requests to multiple HTTP endpoints to failover on error. However, it did not support multiple HTTPS endpoints, nor any load balancing features such round-robin or health checked pools.

    For over two years, Zipkin sites have asked us to support sending data to an Elasticsearch cluster of multiple https endpoints. While folks have been patient, workarounds such as "setup a load balancer", or change your hostnames and certificates, have not been received well. It was beyond clear we needed to do the work client-side. Now, ES_HOSTS can take a list of https endpoints.

    Under the scenes, any endpoints listed receive periodic requests to /_cluster/health. Endpoints that pass this check receive traffic in a round-robin fashion, while those that don't are marked bad. You can see detailed status from the Prometheus endpoint:

    $ curl -sSL localhost:9411/prometheus|grep ^armeria_client_endpointGroup_healthy
    armeria_client_endpointGroup_healthy{authority="search-zipkin-2rlyh66ibw43ftlk4342ceeewu.ap-southeast-1.es.amazonaws.com:443",ip="52.76.120.49",name="elasticsearch",} 1.0
    armeria_client_endpointGroup_healthy{authority="search-zipkin-2rlyh66ibw43ftlk4342ceeewu.ap-southeast-1.es.amazonaws.com:443",ip="13.228.185.43",name="elasticsearch",} 1.0
    

    Note: If you wish to disable health checks for any reason, set zipkin.storage.elasticsearch.health-check.enabled=false using any mechanism supported by Spring Boot.

    The mammoth of effort here is with thanks to @anuraaga. Even though he doesn't use Elasticsearch anymore, he volunteered a massive amount of time to ensure everything works end-to-end all the way to prometheus metrics and client-side health checks. A fun fact is Rag also wrote the first Elasticsearch implementation! Thanks also to the brave who tried early versions of this work, including @jorgheymans, @jcarres-mdsol and stanltam

    If you have any feedback on this feature, or more questions about us, please reach out on gitter

    Test refactoring

    Keeping the project going is not automatic. Over time, things take longer because we are doing more, testing more, testing more dimensions. We ran into a timeout problem in our CI server. Basically, Travis has an absolute time of 45 minutes for any task. When running certain integration tests, and publishing at the same time, we were hitting near that routinely, especially if the build cache was purged. @anuraaga did a couple things to fix this. First, he ported the test runtime from classic junit to jupiter, which allows more flexibility in how things are wired. Then, he scrutinized some expensive cleanup code, which was unnecessary when consider containers were throwaway. At the end of the day, this bought back 15 minutes for us to.. later fill up again :smile: Thanks, Rag!

    Small changes

    Background on Elasticsearch client migration

    The OkHttp java library is everywhere in Zipkin.. first HTTP instrumentation in Brave, the encouraged way to report spans, and relevant to this topic, even how we send data to Elasticsearch!

    For years, the reason we didn't support multiple HTTPS endpoints was the feature we needed was on OkHttp backlog. This is no criticism of OkHttp as it is both an edge case feature, and there are ways including layering a client-side load balancer on top. This stalled out for lack of volunteers to implement the OkHttp side or an alternative. Yet, people kept asking for the feature!

    We recently moved our server to Armeria, resulting in increasing stake, experience and hands to do work. Even though its client side code is much newer than OkHttp, it was designed for advanced features such as client-side load balancing. The idea of re-using Armeria as an Elasticsearch client was interesting to @anuraaga, who volunteered both ideas and time to implement them. The result was a working implementation complete with client-side health checking, supported by over a month of Rag's time.

    The process of switching off OkHttp taught us more about its elegance, and directly influenced improvements in Armeria. For example, Armeria's test package now includes utilities inspired by OkHttp's MockWebServer.

    What we want to say is.. thanks OkHttp! Thanks for the formative years of our Elasticsearch client and years ahead as we use OkHttp in other places in Zipkin. Keep up the great work!

    Source code(tar.gz)
    Source code(zip)
  • 2.15.0(Jul 5, 2019)

    ActiveMQ 5.x span transport

    Due to popular demand, we've added support for ActiveMQ 5.x. Zipkin server will connect to ActiveMQ when the env variable ACTIVEMQ_URL is set to a valid broker. Thanks very much to @IAMTJW for work on this feature and @thanhct for testing it against AWS MQ.

    Ex. simple usage against a local broker

    ACTIVEMQ_URL=tcp://localhost:61616 java -jar zipkin.jar
    

    Ex. usage with docker against a remote AWS MQ failover group

    docker run -d -p 9411:9411 -e ACTIVEMQ_URL='failover:(ssl://b-da18ebe4-54ff-4dfc-835f-3862a6c144b1-1.mq.ap-southeast-1.amazonaws.com:61617,ssl://b-da18ebe4-54ff-4dfc-835f-3862a6c144b1-2.mq.ap-southeast-1.amazonaws.com:61617)' -e ACTIVEMQ_USERNAME=zipkin -e ACTIVEMQ_PASSWORD=zipkin12345678 -e ACTIVEMQ_CONCURRENCY=8 openzipkin/zipkin
    

    Rewrite of Zipkin Lens global search component

    One of the most important roles in open source is making sure the project is maintainable. As features were added in our new UI, maintainability started to degrade. Thanks to an immense amount of effort by @tacigar, we now have new, easier to maintain search component. Under the covers, it is implemented in Material-UI and React Hooks.

    Screenshot 2019-07-05 at 2 54 37 PM

    Behind the crisp new look is clean code that really helps the sustainability of our project. Thanks very much to @tacigar for his relentless attention.

    Refreshed Grafana Dashboard

    While many have tried our Grafana dashboard either directly or via our docker setup, @mstaalesen really dug deep. He noticed some things drifted or were in less than ideal places. Through a couple weeks of revision, we now have a tighter dashboard. If you have suggestions, please bring them to Gitter as well!

    Screenshot 2019-07-05 at 2 41 30 PM

    Small, but appreciated fixes

    • Fixes a bug where a Java 8 class could be accidentally loaded when in Java 1.7
    • Ensures special characters are not used in RabbitMQ consumer tags (thx @bianxiaojin)
    • Shows connect exceptions when using RabbitMQ (thx @thanhct)
    • Fixes glitch where health check wasn't reported properly when throttled (thx @lambcode)
    Source code(tar.gz)
    Source code(zip)
  • 2.14.2(May 15, 2019)

    Zipkin 2.14 adds storage throttling and Elasticsearch 7 support. We've also improved efficiency around span collection and enhanced the UI. As mentioned last time, this release drops support for Elasticsearch v2.x and Kafka v0.8.x. Here's a run-down of what's new.

    Storage Throttling (Experimental)

    How to manage surge problems in collector architecture is non-trivial. While we've collected resources for years about this, only recently we had a champion to take on some mechanics in practical ways. @Logic-32 fleshed out concerns in collector surge handling and did an excellent job evaluating options for those running pure http sites.

    Towards that end, @Logic-32 created an experimental storage throttling feature (bundled for your convenience). When STORAGE_THROTTLE_ENABLED=true calls to store spans pay attention to storage errors and adjust backlog accordingly. Under the hood, this uses Netfix concurrency limits.

    Craig tested this at his Elasticsearch site, and it resulted in far less dropped spans than before. If you are interested in helping test this feature, please see the configuration notes and join gitter to let us know how it works for you.

    Elasticsearch 7.x

    Our server now supports Elasticsearch 6-7.x formally (and 5.x as best efforts). Most notably, you'll no longer see colons in your index patterns if using Elasticsearch 7.x. Thank to @making and @chefky for the early testing of this feature as quite a lot changed under the hood!

    Lens UI improvements

    @tacigar continues to improve Lens so that it can become the default user interface. He's helped tune the trace detail screen, notably displaying the minimap more intuitively based on how many spans are in the trace. You'll also notice the minimap has a slider now, which can help stabilize the area of the trace you are investigating.

    Significant efficiency improvements

    Our Armeria collectors (http and grpc) now work natively using pooled buffers as opposed to byte arrays with renovated protobuf parsers. The sum this is more efficient trace collection when using protobuf encoding. Thanks very much to @anuraaga for leading and closely reviewing the most important parts of this work.

    No more support for Elasticsearch 2.x and Kafka 0.8.x

    We no longer support Elasticsearch 2.x or Kafka 0.8.x. Please see advice mentioned in our last release if you are still on these products.

    Scribe is now bundled (again)

    We used to bundle Scribe (Thrift RPC span collector), but eventually moved it to a separate module due to it being archived technology with library conflicts. Our server is now powered by Armeria, which natively supports thrift. Thanks to help from @anuraaga, the server has built-in scribe support for those running legacy applications. set SCRIBE_ENABLED=true to use this.

    Other notable updates

    • Elasticsearch span documents are written with ID ${traceID}-${MD5(json)} to allow for server-side deduplication
    • Zipkin Server is now using the latest Spring Boot 2.1.5 and Armeria 0.85.0
    Source code(tar.gz)
    Source code(zip)
  • v2.13.0(May 1, 2019)

    Zipkin 2.13 includes several new features, notably a gRPC collection endpoint and remote service name indexing. Lens, our new UI, is fast approaching feature parity, which means it will soon be default. End users should note this is the last release to support Elasticsearch v2.x and Kafka v0.8.x. Finally, this our first Apache Incubating release, and we are thankful to the community's support and patience towards this.

    Lens UI Improvements

    Led by @tacigar, Lens has been fast improving. Let's look at a couple recent improvements: Given a trace ID or json, the page will load what you want.

    Open trace json

    Go to trace ID

    Right now, you can opt-in to Lens by clicking a button. The next step is when Lens is default and finally when the classic UI is deleted. Follow the appropriate projects for status on this.

    gRPC Collection endpoint

    Due to popular demand, we now publish a gRPC endpoint /zipkin.proto3.SpanService/Report which accepts the same protocol buffers ListOfSpans message as our POST /api/v2/spans endpoint. This listens on the same port as normal http traffic when COLLECTOR_GRPC_ENABLED=true. We will enable this by default after the feature gains more experience.

    We chose to publish a unary gRPC endpoint first, as that is most portable with limited clients such as grpc-web. Our interop tests use the popular Android and Java client Square Wire. Special thanks to @ewhauser for leading this effort and @anuraaga who championed much of the work in Armeria.

    Remote Service Name indexing

    One rather important change in v2.13 is remote service name indexing. This means that the UI no longer confuses local and remote service name in the same drop-down. The impact is that some sites will have much shorter and more relevant drop-downs, and more efficient indexing. Here are some screen shots from Lens and Classic UIs:

    Schema impact

    We have tests to ensure the server can be upgraded ahead of schema change. Also, most storage types have the ability to automatically upgrade the schema. Here are relevant info if you are manually upgrading:

    STORAGE_TYPE=cassandra

    If you set CASSANDRA_ENSURE_SCHEMA=false, you are opting out of automatic schema management. This means you need to execute these CQL commands manually to update your keyspace

    STORAGE_TYPE=cassandra3

    If you set CASSANDRA_ENSURE_SCHEMA=false, you are opting out of automatic schema management. This means you need to execute these CQL commands manually to update your keyspace

    STORAGE_TYPE=elasticsearch

    No index changes were needed

    STORAGE_TYPE=mysql

    Logs include the following message until instructions are followed:

    zipkin_spans.remote_service_name doesn't exist, so queries for remote service names will return empty.
    Execute: ALTER TABLE zipkin_spans ADD `remote_service_name` VARCHAR(255);
    ALTER TABLE zipkin_spans ADD INDEX `remote_service_name`;
    

    Dependency group ID change

    For those using Maven to download, note that the group ID for libraries changed from "io.zipkin.zipkin2" to "org.apache.zipkin.zipkin2". Our server components group ID changed from "io.zipkin.java" to "org.apache.zipkin"

    This is the last version to support Elasticsearch 2.x

    Elastic's current support policy is latest major version (currently 7) and last minor (currently 6.7). This limits our ability to support you. For example, Elasticsearch's hadoop library is currently broken for versions 2.x and 5.x making our dependencies job unable to work on that range and also work on version 7.x.

    Our next release will support Elasticsearch 7.x, but we have to drop Elasticsearch 2.x support. Elasticsearch 5.x will be best efforts. We advise users to be current with Elastic's supported version policy, to avoid being unable to upgrade Zipkin.

    This is the last version to support Kafka 0.8x

    This is the last release of Zipkin to support connecting to a Kafka 0.8 broker (last release almost 4 years ago). Notably, this means those using KAFKA_ZOOKEEPER to configure their broker need to switch to KAFKA_BOOTSTRAP_SERVERS instead.

    Other notable updates

    • Zipkin Server is now using the latest Spring boot 2.1.4
    Source code(tar.gz)
    Source code(zip)
  • 2.12.6(Mar 10, 2019)

    Zipkin 2.12.6 migrates to the Armeria http engine. We also move to Distroless to use JRE 11 in our docker images.

    Interest in Armeria 3 years ago originated at LINE, a long time supporter of Zipkin. This was around its competency in http/2 and asynchronous i/o. Back then, we were shifting towards a more modular server so that they could create their own. Over time, interest and our use case for Armeria grown. Notably, @ewhauser has led an interest in a gRPC endpoint for zipkin. Typically, people present different listen ports for gRPC, but Armeria allows the same engine to be used for both usual web requests and also gRPC. Moreover, now more than ever LINE, the team behind Armeria are involved deeply in our community, as are former LINE engineers like @anuraaga. So, we had a match of both supply and demand for the technology.

    End users will see no difference in Zipkin after we replaced the http engine. Observant administrators will notice some of the console lines being a bit different. The whole experience has been drop-in thanks to spring boot integration efforts led by @anuraaga @trustin and @hyangtack. For those interested in the technology for their own apps, please check out Armeria's example repository.

    There's more to making things like http/2 work well than the server framework code. For example, there is nuance around OpenSSL which isn't solved well until newer runtimes. For a long time, we used alpine JRE 1.8 because some users were, justifiably or not, very concerned about the size of our docker image. As years passed, we kept hitting fragile setup concerns around OpenSSL. This would play out as bad releases of stackdriver integration, as that used gRPC. As we owe more service to users than perceptions around dist sizes, we decided it appropriate to move a larger, but still slim distroless JRE 11 image.

    The MVP of all of this is @anuraaga, the same person who made an armeria zipkin server at LINE 3 years ago, who today backfilled functionality where needed, and addressed the docker side of things. Now, you can use this more advanced technology without thinking. Thank you, Rag!

    Source code(tar.gz)
    Source code(zip)
  • 2.12.4(Mar 7, 2019)

  • 2.12.3(Mar 2, 2019)

    Zipkin 2.12.3 provides an easy way to preview Lens, our new user interface.

    Introduction to Zipkin Lens

    Zipkin was open sourced by Twitter in 2012. Zipkin was the first OSS distributed tracing system shipped complete with instrumentation and a UI. This "classic" UI persisted in various forms for over six years before Lens was developed. We owe a lot of thanks to the people who maintained this, as it is deployed in countless sites. We also appreciate alternate Zipkin UIs attempts, and the work that went into them. Here are milestones in the classic UI, leading to Lens.

    • Mid 2012-2015 - Twitter designed and maintained Zipkin UI
    • Early 2016 - Eirik and Zoltan team up to change UI code and packaging from scala to pure javascript
    • Late 2016 - Roger Leads Experimental Angular UI
    • Late 2017 to Early 2018 - Mayank Leads Experimental React UI
    • Mid to Late 2018 - Raja renovates classic UI while we investigate options for a standard React UI
    • December 7, 2018 - LINE contributes their React UI as Zipkin Lens
    • Early 2019 - Igarashi and Raja complete Zipkin Lens with lots of usage feedback from Daniele

    Lens took inspiration from other UIs, such as Haystack, and cited that influence. You'll notice using it that it has a feel of its own. Many thanks to the design lead Igarashi, who's attention to detail makes Lens a joy to use. Some design goals were to make more usable space, as well be able to assign site-specific details, such as tags. Lens is not complete in its vision. However, it has feature parity to the point where broad testing should occur.

    screen shot 2019-03-02 at 8 32 22 pm

    Trying out Lens

    We spend a lot of time and effort in attempts to de-risk trying new things. Notably, the Zipkin server ships with both the classic and the Lens UI, until the latter is complete. With design help from @kaiyzen and @bsideup, starting with Zipkin 2.12.3, end users can select the UI they prefer at runtime. All that's needed is to press the button "Try Lens UI", which reloads into the new codebase. There's then a button to revert: "Go back to classic Zipkin".

    gobacktolens

    Specifically the revert rigor was thanks to Tommy and Daniele who insisted on your behalf that giving a way out is as important as the way in. We hope you feel comfortable letting users try Lens now. If you want to prevent that, you can: set the variable ZIPKIN_UI_SUGGEST_LENS=false.

    Auto-complete Keys

    One design goal of Lens was to have it better reflect the priority of sites. The first work towards that is custom search criteria via auto-completion keys defined by your site. This was inspired by an alternative to Lens, Haystack UI, which has a similar "universal search" feature. Many thanks to Raja who put in ground work on the autocomplete api and storage integration needed by this feature. Thanks to Igarashi for developing the user interface in Lens for it.

    To search by site-specific tags, such as environment names, you first need to tell Zipkin which keys you want. Start your zipkin servers with an environment variable like below that includes keys whitelisted from Span.tags. Note that keys you list should have a fixed set of values. In other words, do not use keys that have thousands of values.

    AUTOCOMPLETE_KEYS=client_asg_name,client_cluster_name,service_asg_name,service_cluster_name java -jar zipkin.jar
    

    Here's a screen shot of custom auto-completion, using an example trace from Netflix.

    screen shot 2019-03-02 at 8 15 01 pm

    Feedback

    Maintaining two UIs is a lot of burden on Zipkin volunteers. We want to transition to Lens as soon as it is ready. Please upgrade and give feedback on Gitter as you use the tool. With luck, in a month or two we will be able to complete the migration, and divert the extra energy towards new features you desire, maybe with your help implementing them! Thanks for the attention, and as always star our repo, if you think we are doing a good job for open source tracing!

    Source code(tar.gz)
    Source code(zip)
  • 2.11.1(Aug 5, 2018)

  • 2.11.0(Aug 3, 2018)

    Zipkin 2.11 dramatically improves Cassandra 3 indexing and fixes some UI glitches

    Cassandra 3 indexing

    We've had cassandra3 storage type for a while, which uses SASI indexing. One thing @Mobel123 noticed was particular high disk usage for indexing tags. This resulted in upstream work in cassandra to introduce a new indexing option which results in 20x performance for the type of indexing we use.

    See #1948 for details, but here are the notes:

    1. You must upgrade to Cassandra 3.11.3 or higher first
    2. Choose a path for dealing with the old indexes
    • easiest is re-create your keyspace (which will drop trace data)
    • advanced users can run zipkin2-schema-indexes.cql, which will leave the data alone but recreate the index
    1. Update your zipkin servers to latest patch (2.11.1+)

    Any questions, find us on gitter!

    Thanks very much @michaelsembwever for championing this, and @llinder for review and testing this before release. Thanks also to the Apache Cassandra project for accepting this feature as it is of dramatic help!

    UI fixes

    @zeagord fixed bugs relating to custom time queries. @drolando helped make messages a little less scary when search is disabled. Zipkin's UI is a bit smaller as we've updated some javascript infra which minimizes better. This should reduce initial load times. Thanks tons for all the volunteering here!

    Source code(tar.gz)
    Source code(zip)
  • 2.10.1(Jul 7, 2018)

    Zipkin 2.10 drops v1 library dependency and http read endpoints. Those using the io.zipkin.java:zipkin (v1) java library should transition to io.zipkin.zipkin2:zipkin as the next release of Zipkin will stop publishing updates to the former. Don't worry: Zipkin server will continue accepting all formats, even v1 thrift, for the foreseeable future.

    Below is a story of our year long transition to a v2 data format, ending with what we've done in version 2.10 of our server (UI in nature). This is mostly a story of how you address an big upgrade in a big ecosystem when almost all are volunteers.

    Before a year ago, the OpenZipkin team endured (and asked ourselves) many confused questions about our thrift data format. Why do service endpoints repeat all the time? What are binary annotations? What do we do if we have multiple similar events or binary annotations? Let's dig into the "binary annotation" as probably many reading still have no idea!

    Binary annotations were a sophisticated tag, for example an http status. While the name is confusing, most problems were in being too flexible and this led to bugs. Specifically it was a list of elements with more type diversity than proved useful. While a noble aim, and made sense at the time, binary annotations could be a string, binary, various bit lengths of integer or floating point numbers. Even things that seem obvious could be thwarted. For example, some would accidentally choose the type binary for string, effectively disabling search. Things seemingly simple like numbers were bug factories. For example, folks would add random numbers as an i64, not thinking that you can't fit one in a json number without quoting or losing precision. Things that seemed low-hanging fruit were not. Let's take http status for example. Clearly, this is a number, but which? Is it a 16bit (technically correct) or is it a 32 bit (to avoid signed misinterpretation)? Could you search on it the way you want to (<200 || >299 && !404)? Tricky right? Let's say someone sent it as a different type by accident.. would it mess up your indexing if sent as a string (definitely some will!)? Even if all of this was solved, Zipkin is an open ecosystem including private sites with their private code. How much time does it cost volunteers to help others troubleshoot code that can't be shared? How can we reduce support burden while remaining open to 3rd party instrumentation?

    This is a long winded story of how our version 2 data format came along. We cleaned up our data model, simplifying as an attempt to optimize reliability and support over precision. For example, we scrapped "binary annotation" for "tags". We don't let them repeat or use numeric types. There are disadvantages to these choices, but explaining them is cheap and the consequences are well understood. Last July, we started accepting a version 2 json format. Later, we added a protobuf representation.

    Now, why are we talking about a data format supported a year ago? Because we just finished! It takes a lot of effort to carefully roll something out into an ecosystem as large as Zipkin's and being respectful of the time impact to our volunteers and site owners.

    At first, we ingested our simplified format on the server side. This would "unlock" libraries, regardless of how they are written, and who wrote them, into simpler data.. data that much resembles tracing operations themselves. We next focused on libraries to facilitate sending and receiving data, notably brown field changes (options) so as to neither disrupt folks, nor scare them off. We wanted the pipes that send data to become "v2 ready" so owners can simultaneously use new and old formats, rather than expect an unrealistic synchronous switch of data format. After this, we started migrating our storage and collector code, so that internal functionality resemble v2 constructs even while reading or writing old data in old schemas. Finally, in version 2.10, we changed the UI to consume only v2 data.

    So, what did the UI change include? What's interesting about that? Isn't the UI old? Let's start with the last question. While true the UI has only had facelifts and smaller visible features, there certainly has been work involved keeping it going. For example, backporting of tests, restructuring its internal routing, adding configuration hooks or integration patterns. When you don't have UI staff, keeping things running is what you end up spending most time on! More to the point, before 2.10, all the interesting data conversion and processing logic happened in Java, on the api server. For example, merging of data, correcting clock shifts etc. This setup a hard job for those emulating zipkin.. at least those who emulated the read side. Custom read api servers or proxies can be useful in practice. Maybe you need to stitch in authorization or data filtering logic.. maybe your data is segmented.. In short, while most read scenarios are supported out-of-box, some advanced proxies exist for good reason.

    Here's a real life example: Yelp saves money by not sending trace data across paid links. For example, in Amazon's cloud (and most others), if you send data from one availability zone to another, you will pay for that. To reduce this type of cost, Yelp uses an island + aggregator pattern to save trace data locally, but materialize traces across zones when needed. In their site, this works particularly well as search doesn't use Zipkin anyway: they use a log based tool to find trace IDs. Once they find a trace ID, they use Zipkin to view it.. but still.. doing so requires data from all zones. To solve this, they made an aggregating read proxy. Before 2.10, it was more than simple json re-bundling. They found that our server did things like merging rules and clock skew correction. This code is complex and also high maintenance, but was needed for the UI to work correctly. Since v2.10 moves this to UI javascript, Yelp's read proxy becomes much simpler and easier to maintain. In summary, having more logic in the UI means less work for those with DIY api servers.

    Another advantage of having processing logic in the UI is better answering "what's wrong with this trace?" For example, we know data can be missing or incorrect. When processing is done server-side, there is friction in deciding how to present errors. Do you decorate the trace with synthetic data, or use headers, or some enveloping? If instead that code was in the UI, such decisions are more flexible and don't impact the compatibility of others. While we've not done anything here yet, you can imagine it is easier to show, like color or otherwise, that you are viewing "a bad trace". Things like this are extremely exciting, given our primary goals are usually to reduce the cost of support!

    In conclusion, we hope that by sharing our story, you have better insight into the OpenZipkin way of doing things, how we prioritize tasks, and how seriously we take support. If you are a happy user of Zipkin, find a volunteer who's helped you and thank them, star our repository, or get involved if you can. You can always find us on Gitter.

    Source code(tar.gz)
    Source code(zip)
  • 2.9.4(Jun 16, 2018)

    Zipkin 2.9 reorganizes the project in efforts to reduce future maintenance. This work is important to the long-term health and related to our "v2" project started last year.

    If all goes well, the next server release will remove all dependencies on and stop publishing our "v1" library io.zipkin.java:zipkin.

    Many thanks to continual support and testing by folks notably @rangwea @llinder and @shakuzen as this ground work was a bit bumpy. On that note, please use the latest patch (at the time of writing 2.9.4)!

    Kafka consumers are now v0.10+, not 0.8, by default

    We kept Kafka 0.8 support as default for longer than comfortable based on demand from older Zipkin sites. However, this starts to cause problems notably as folks would use the old KAFKA_ZOOKEEPER approach to connecting just because it was default. This also pins versions in a difficult place, notably when the server is extended. The KAFKA_BOOTSTRAP_SERVERS (v0.10+) approach, which was available as an option before, is now the default mechanism in Zipkin.

    Those using KAFKA_ZOOKEEPER because they still run old 0.8 brokers can still do so. If you are using Docker, there is no change at all. If you are self-packaging a distribution of zipkin, please use these instructions to integrate v0.8 support.

    AWS Elasticsearch Service is now in the zipkin-aws image

    Before, our Amazon integration for Elasticsearch was baked into the default image. This was a historical thing because we didn't have a large repository for Amazon components, yet. This caused dual-repository maintenance, particularly Amazon SDK version ping-pong, and also expertise to be somewhat spread arbitrarily in two repositories. zipkin-aws is now the "one stop shop" for Amazon Web Services integrations with Zipkin (or other libraries like Brave for that matter).

    Those using ES_AWS_DOMAIN or Amazon endpoints in ES_HOSTS need to use a "zipkin-aws" distribution. If you are using Docker, you just switch your image from openzipkin/zipkin to openzipkin/zipkin-aws. If you are self-packaging a distribution of zipkin, please use these instructions to integrate Amazon's Elasticsearch Service.

    "Legacy reads" are now removed from our Elasticsearch storage implementation

    Last year, we had to switch our storage strategy in Elasticsearch as multiple type indexes were dropped in future versions of Elasticsearch. We added a temporary ES_LEGACY_READS_ENABLED flag to allow folks to transition easier. This is now removed.

    By removing this code, we have more "maintenance budget" do discuss other transitions in Elastcisearch. For example, it is hinted that with a certain version range, re-introducing natural tag indexing could be supported. This would imply yet another transition, which is a bitter pill if we also have to support an older transition.

    V1 thrift codec is "re-supported"

    You can now read and write old zipkin thrifts using the io.zipkin.zipkin2:zipkin library. This feature is very undesirable from a code maintenance point of view. However, some projects simply weren't upgrading as they are still running or supporting old zipkin backends that only accept thrift. To allow a longer transition period, we introduced the ability to use thrift (and scribe) again on the client side. The first consumer is Apache Camel. Under the scenes SpanBytesEncoder.THRIFT does the job.

    Note: If you are still writing v1 thrifts, or using Scribe, please consider alternatives! This is not only to receive better support here, but also the myriad of Zipkin clones. Most clones only accept json, so your products will be more supportable as soon as you can transition off thrift.

    Also note: the core jar is still dependency free as we coded the thrift codec directly. A lot of care was taken to pay for this change, by removing other code or sources of bloat from the jar. In fact, our jar is slightly smaller than before we re-added thrift, now a hair below 200KiB.

    Storage and Collector extensions are now "v2 only"

    Before, we had to support two libraries for integrations such as zipkin-gcp: this implied one path for v1 structs and and another for v2 structs. Now that our core library can read both formats, we could dramatically simplify these integrations. End users won't see any change as a part of this process.

    Source code(tar.gz)
    Source code(zip)
  • 2.8.3(May 3, 2018)

    Zipkin 2.8 migrates to Spring Boot v2 and adds a binary data format (proto3). Do not use a version lower than 2.8.3, as we found some issues post-release and resolved them.

    This release is mostly infrastructure. All the help by our community are super appreciated as often such work is hard and thankless. Let's stop that here.. Thank you specifically @zeagord and @shakuzen for working on these upgrades, testing in production and knocking out dents along the way.

    Spring Boot and Micrometer update

    Zipkin internally has been updated to Spring Boot v2 which implies Micrometer for metrics. While features of our service didn't change, this is an important upgrade and has impact to Prometheus configuration.

    Prometheus

    We now internally use Micrometer for metrics on Zipkin server. Some of the prometheus metrics have changed to adhere to standards there. Our grafana setup is adjusted on your behalf, but here are some updates if rolling your own:

    • Counter metrics now properly have _total for sums
      • Ex zipkin_collector_bytes_total, not zipkin_collector_bytes
    • Collector metrics no longer have embedded fields for transport type
      • Ex zipkin_collector_bytes has a tag transport instead of a naming convention
    • Http metrics now have normalized names
      • Ex http_server_requests_seconds_count, not http_requests_total
    • Http metrics have route-based uri tags
      • Ex instead of path which has variables like /api/v2/trace/abcd, uri with a template like /ap1/v2/trace/{traceId}

    Note: the metrics impact is exactly the same prior to the spring boot v2 update. You can update first to Zipkin 2.7.5 to test metrics independently to the other updates.

    Endpoint changes

    If you were using Spring's "actuator" endpoints, they are now under the path /actuator as described in Spring Boot documentation. However, we've reverse mapped a /metrics and /health endpoint compatible with the previous setup.

    Binary Format (protobuf3)

    We've had many requests for an alternative to our old thrift format for binary encoding of trace data. Some had interest in the smaller size (typical span data is half the size as uncompressed json). Others had interest in compatibility guarantees. Last year when we created Zipkin v2, we anticipated demand for this, and settled on Protocol Buffers v3 as the format of choice. Due to a surge of demand, we've added this to Zipkin 2.8

    Impact to configuration

    If using a library that supports this, it is as easy as an encoding choice. For example, switching to Encoding.PROTO3 in your configuration.

    NOTE Servers must be upgraded first!

    Impact to collectors

    Applications will send spans in messages and so our collectors now detect a byte signature of the ListOfSpans type and act accordingly. In http, this is assumed when the content-type application/x-protobuf is used on the /api/v2/spans endpoint. There is no expected impact beyond this except for efficiency gains.

    Impact to hand-coders

    For those of you coding your own, you can choose to use normal protoc, or our standard zipkin2 library. Our bundled SpanBytesEncoder.PROTO3 has no external dependencies. While this added some size, our jar is still less than 200K.

    Source code(tar.gz)
    Source code(zip)
  • 2.7.1(Apr 8, 2018)

    Zipkin 2.7 is maintenance focused. It deprecates custom servers, removes Scribe from our default jar and aligns internals towards future upgrades.

    Explain custom servers are unsupported via deprecation

    Especially lately, we have had a large number of people having problems with unnecessarily custom servers. Some are due to not knowing Sleuth's stream server is obviated by our Rabbit MQ support. Some are due to blogs which unfortunately recommend starting Zipkin in the IDE via a custom server. Some are due to version drift when people change to Spring Boot 2.

    As of Zipkin 2.7, the @EnableZipkinServer annotation is still available, but includes the following notice:


    Custom servers are possible, but not supported by the community. Please use our default server build first. If you find something missing, please gitter us about it before making a custom server.

    If you decide to make a custom server, you accept responsibility for troubleshooting your build or configuration problems, even if such problems are a reaction to a change made by the OpenZipkin maintainers. In other words, custom servers are possible, but not supported.


    Removes Scribe from the default jar, as an optional module

    The long since archived thrift-RPC transport Scribe is no longer in our exec jar file. It is still available in the docker image. We removed this for reasons including support concerns as the library we use hasn't had maintenance in two years. If you are not using Docker, yet using Scribe see our README for more.

    Aligning internals towards Spring Boot 2 upgrade

    Zipkin's server is currently Spring Boot 1.5.x. Our cloud plugins for Amazon, Azure and Google use a module layout removed in Spring Boot 2. To ready for a future upgrade, @zeagord wrote our own layout factory, compatible with both versions. Thanks for the help, Raja!

    Other notes

    • zipkin-zookeeper is now in the attic https://github.com/openzipkin-attic/zipkin-zookeeper
    • @narayaruna fixed a glitch where in Elasticsearch we intended to index 256 characters not 255
    • @narayaruna fixed a glitch where we did client side filtering in Elasticsearch when it wasn't necessary
    • @Logic-32 fixed a bug where SEARCH_ENABLED=false didn't disable UI search controls
    • empty RABBIT_URI properties are now ignored
    Source code(tar.gz)
    Source code(zip)
  • 2.6.1(Mar 17, 2018)

    Zipkin 2.6 adds "View Saved Trace" screen and makes the UI work through Kubernetes ingress controllers. As usual, the updates below are pushed to docker for all of our images at latest version, including the cloud ones: zipkin-aws, zipkin-azure and zipkin-gcp

    View Saved Trace screen

    We've had a myriad of requests, usually those supporting tracing sites, for an ability to view a saved trace. This has come in many forms, from trying to mutate TTL values, to proxying other servers, you name it. Lacking a perfect solution, through the help of @Logic-32 we have a pragmatic one: "View Saved Trace".

    It is very simple, you click it and select a file screen shot 2018-03-17 at 2 28 37 pm

    For example, if you saved an example json, you can see how the UI presents it. screen shot 2018-03-17 at 3 04 38 pm

    Who would use this? Support certainly will as this allows an easier way to get on the same page safely. For example, you can save trace json from an outage. Weeks or years later.. after the data expired.. simply open that file to revisit the topic. Internally, UI dev is easier as there's literally no remote dependency. For example, some motivation for this is testing towards the 10k span problem.

    Why not integrate with S3, data retention policy override, or a remote cluster etc? @naoman helped with a remote zipkin approach. Eventhough it was viable, and good code, integration is very site and security policy specific. This made it too polarizing. It could be that one day there's a separate plugin or utility for aggregating "favorite traces", but at least now you can accomplish similar clicking JSON and saving it to your favorite (potentially cloud-backed) disk :)

    Thanks very much to @Logic-32 for the code here, but also to @naoman who had an alternate solution leading to this.

    Zipkin UI and Kubernetes ingress controller

    Zipkin's UI works via client-side routing based on a path prefix '/zipkin/'. Via a reverse proxy and a replacement filter, you can change this. The nginx ingress of Kubernetes has limited configurability, so was missing the ability to inject the tag remapping depends on.

    @abesto and @wdittmer-mp got to the bottom of this through some epic investigations, leading to Zoltan coding up support for ZIPKIN_UI_BASEPATH, a special hook to handle this case. Yeah.. sounds special case, but k8s is a popular deployment environment... this is not as niche as it sounds!

    Anyway thanks again to Zoltan and Wilfred for getting this to work. Wilfred's shared his setup, which mixes together a bunch of friends like prometheus, grafana and kibana on a bastion host. Have a look!

    Other recent things

    • We now properly process dependency links regardless of B3 or AWS propagation. Thanks to @sokac for getting to the bottom of this
    • @igorwwwwwwwwwwwwwwwwwwww fixed a UI glitch where custom dates weren't refreshed properly
    • @zeagord adjusted config so that you can do ./zipkin.jar instead of java -jar zipkin.jar useful in service run configuration
    • zipkin core api jars now have Java 9 module entries
    • ES_DATE_SEPARATOR= is now permitted for indexes like yyyyMMdd. Thanks @narayaruna for the suggestion
    • There are a number of tweaks to the span detail screen, mostly scrubbing "undefined:0" style glitches for partially defined endpoints.
    Source code(tar.gz)
    Source code(zip)
Owner
Open Zipkin
Open Zipkin
Ray Tracing project from students of the ENSEEIHT Engineering School

Ray-Tracing-N7 This is a school project of students of the ENSEEIHT engineering school, in which we will try to recreate a basic ray tracing system, w

Tibo Mousset 3 Jun 23, 2022
Detect if the system is recording, mirroring, or using AirPlay to stream the contents of the screen.

react-native-is-screen-captured-ios Detect if the system is recording, mirroring, or using AirPlay to stream the contents of the screen. https://devel

Dylan 20 Dec 30, 2022
Slueth(Zipkin) 를 통한 SQS Message Tracing POC(Proof of concept) 입니다.

Sleuth AWS SQS POC 해당 프로젝트는 Slueth(Zipkin) 를 통한 메시지 추적 POC(Proof of concept) 입니다. Rest API 를 통해 POST 요청을 받으면, 메시지를 발행/소비 합니다. 이 과정에서 유지되는 TraceId 를 확인

Hyunjin Jeong 10 Nov 29, 2022
Distributed Tracing, Metrics and Context Propagation for application running on the JVM

Kamon Kamon is a set of tools for instrumenting applications running on the JVM. The best way to get started is to go to our official Get Started Page

Kamon Open Source Project 1.4k Dec 25, 2022
BTrace - a safe, dynamic tracing tool for the Java platform

btrace A safe, dynamic tracing tool for the Java platform Version 2.1.0 Quick Summary BTrace is a safe, dynamic tracing tool for the Java platform. BT

btrace.io 5.3k Jan 9, 2023
Ray Tracing project from students of the ENSEEIHT Engineering School

Ray-Tracing-N7 This is a school project of students of the ENSEEIHT engineering school, in which we will try to recreate a basic ray tracing system, w

Tibo Mousset 3 Jun 23, 2022
Realtime SOS Android Application. Location (GPS + Cellular Network) tracing application by alerting guardians of the User.

WomenSaftey Women Safety Android Application: Realtime SOS Android Application. Designed a Location (GPS + Cellular Network) tracing application by al

jatin kasera 6 Nov 19, 2022
Decorating Spring Boot Reactive WebClient for tracing the request and response data for http calls.

SpringBoot Reactive WebClient ?? Tracing HTTP Request through a single pane of glass Decorating Spring Boot Reactive WebClient for tracing the request

Reactive Learning LLP 7 Jul 13, 2022
Distributed and fault-tolerant realtime computation: stream processing, continuous computation, distributed RPC, and more

IMPORTANT NOTE!!! Storm has Moved to Apache. The official Storm git repository is now hosted by Apache, and is mirrored on github here: https://github

Nathan Marz 8.9k Dec 26, 2022
Apache Pulsar - distributed pub-sub messaging system

Pulsar is a distributed pub-sub messaging platform with a very flexible messaging model and an intuitive client API. Learn more about Pulsar at https:

The Apache Software Foundation 12.1k Jan 4, 2023
Chaos engineering tool for simulating real-world distributed system failures

Proxy for simulating real-world distributed system failures to improve resilience in your applications. Introduction Muxy is a proxy that mucks with y

Matt Fellows 811 Dec 25, 2022
A high available,high performance distributed messaging system.

#新闻 MetaQ 1.4.6.2发布。更新日志 MetaQ 1.4.6.1发布。更新日志 MetaQ 1.4.5.1发布。更新日志 MetaQ 1.4.5发布。更新日志 Meta-ruby 0.1 released: a ruby client for metaq. SOURCE #介绍 Meta

dennis zhuang 1.3k Dec 12, 2022
BAIN Social is a Fully Decentralized Server/client system that utilizes Concepts pioneered by I2P, ToR, and PGP to create a system which bypasses singular hosts for data while keeping that data secure.

SYNOPSIS ---------------------------------------------------------------------------------------------------- Welcome to B.A.I.N - Barren's A.I. Natio

Barren A.I. Wolfsbane 14 Jan 11, 2022
Flash Sale System AKA. seckill system

FlashSaleSystem Project highlights Distributed system scheme From a single machine to a cluster, it is easy to scale horizontally simply by adding ser

wsbleek 12 Sep 13, 2022
Team 5468's 2022 FRC robot code. This code is written in Java and is based off of WPILib's Java control system and utilizes a command based system

FRC 2022 Team 5468's 2022 FRC robot code. This code is written in Java and is based off of WPILib's Java control system and utilizes a command based s

null 4 Oct 4, 2022
Modern configuration library for distributed apps written in Java.

Overview cfg4j ("configuration for Java") is a configuration library for Java distributed apps (and more). Features: Open source Easy to use Auto-relo

cfg4j 544 Nov 23, 2022
Distributed ID Generate Service

Leaf There are no two identical leaves in the world. — Leibnitz 中文文档 | English Document Introduction Leaf refers to some common ID generation schemes

美团 5.7k Dec 29, 2022
Official repository of Trino, the distributed SQL query engine for big data, formerly known as PrestoSQL (https://trino.io)

Trino is a fast distributed SQL query engine for big data analytics. See the User Manual for deployment instructions and end user documentation. Devel

Trino 6.9k Dec 31, 2022