Convert Figma logo to code with AI

openzipkin logobrave

Java distributed tracing implementation compatible with Zipkin backend services.

2,355
713
2,355
115

Top Related Projects

OpenTracing API for Java. 🛑 This library is DEPRECATED! https://github.com/opentracing/specification/issues/163

APM, Application Performance Monitoring System

Distributed tracing for spring cloud

16,917

Zipkin is a distributed tracing system

Quick Overview

Brave is a distributed tracing instrumentation library for Java applications. It helps developers trace requests across multiple services in a microservices architecture, providing insights into latency and dependencies between services. Brave implements the OpenZipkin standard for distributed tracing.

Pros

  • Easy integration with popular Java frameworks and libraries
  • Lightweight and low-overhead implementation
  • Supports both synchronous and asynchronous tracing
  • Extensible with various reporter and sampler options

Cons

  • Primarily focused on Java ecosystem, limiting its use in polyglot environments
  • Requires manual instrumentation for custom components
  • Learning curve for effective use in complex distributed systems
  • May introduce slight performance overhead in high-throughput scenarios

Code Examples

  1. Creating a Tracer:
Tracing tracing = Tracing.newBuilder()
    .localServiceName("my-service")
    .spanReporter(AsyncReporter.create(URLConnectionSender.create("http://localhost:9411/api/v2/spans")))
    .build();
Tracer tracer = tracing.tracer();
  1. Starting and finishing a span:
Span span = tracer.newTrace().name("my-operation").start();
try {
    // Do some work
    span.tag("key", "value");
} finally {
    span.finish();
}
  1. Creating a child span:
Span parentSpan = tracer.currentSpan();
Span childSpan = tracer.newChild(parentSpan.context()).name("child-operation").start();
try {
    // Do some work
} finally {
    childSpan.finish();
}

Getting Started

To use Brave in your Java project, add the following dependency to your Maven pom.xml:

<dependency>
    <groupId>io.zipkin.brave</groupId>
    <artifactId>brave</artifactId>
    <version>5.13.9</version>
</dependency>

For Gradle, add this to your build.gradle:

implementation 'io.zipkin.brave:brave:5.13.9'

Then, create a Tracer and start instrumenting your code as shown in the code examples above.

Competitor Comparisons

OpenTracing API for Java. 🛑 This library is DEPRECATED! https://github.com/opentracing/specification/issues/163

Pros of OpenTracing Java

  • Vendor-neutral API, allowing for greater flexibility in choosing tracing backends
  • Extensive support for various frameworks and libraries
  • More comprehensive context propagation across different execution models

Cons of OpenTracing Java

  • Steeper learning curve due to more complex API
  • Requires more manual instrumentation compared to Brave
  • Less performant in high-throughput scenarios

Code Comparison

OpenTracing Java:

Tracer tracer = GlobalTracer.get();
Span span = tracer.buildSpan("operation").start();
try (Scope scope = tracer.activateSpan(span)) {
    // Your code here
} finally {
    span.finish();
}

Brave:

Span span = tracer.nextSpan().name("operation");
try (SpanInScope ws = tracer.withSpanInScope(span.start())) {
    // Your code here
} finally {
    span.finish();
}

Key Differences

  • OpenTracing Java offers a more generic API, while Brave is more opinionated and Zipkin-centric
  • Brave provides better out-of-the-box performance and easier integration with Spring Boot
  • OpenTracing Java has a larger ecosystem of compatible tracers and integrations

Conclusion

Choose OpenTracing Java for vendor-neutral, flexible tracing across diverse environments. Opt for Brave if you prefer a simpler API, better performance, and tight integration with Zipkin and Spring ecosystems.

APM, Application Performance Monitoring System

Pros of SkyWalking

  • More comprehensive observability platform with APM, metrics, and logging
  • Supports multiple languages and frameworks out-of-the-box
  • Provides a built-in UI for visualization and analysis

Cons of SkyWalking

  • Heavier and more complex to set up and maintain
  • Higher resource consumption due to its full-featured nature
  • Steeper learning curve for newcomers

Code Comparison

SkyWalking (Java agent configuration):

<agent.application_code>MyApp</agent.application_code>
<collector.backend_service>oap-server:11800</collector.backend_service>
<plugin.mongodb.trace_param>true</plugin.mongodb.trace_param>

Brave (Spring Boot configuration):

spring:
  zipkin:
    baseUrl: http://zipkin-server:9411/
  sleuth:
    sampler:
      probability: 1.0

Both projects aim to provide distributed tracing capabilities, but SkyWalking offers a more comprehensive observability solution with built-in visualization tools. Brave, being part of the Zipkin ecosystem, focuses primarily on tracing and integrates well with other Zipkin components. SkyWalking is better suited for large-scale, multi-language environments, while Brave is lighter and easier to integrate into Java applications, especially those already using Spring Boot.

Distributed tracing for spring cloud

Pros of Spring Cloud Sleuth

  • Seamless integration with Spring Boot and Spring Cloud ecosystem
  • Built-in support for various Spring-specific features and configurations
  • Automatic instrumentation for common Spring components

Cons of Spring Cloud Sleuth

  • More tightly coupled with Spring framework, potentially limiting flexibility
  • May have a steeper learning curve for non-Spring developers
  • Slightly heavier dependency footprint compared to Brave

Code Comparison

Spring Cloud Sleuth:

@Bean
public Sampler defaultSampler() {
    return Sampler.ALWAYS_SAMPLE;
}

Brave:

Tracing.newBuilder()
    .localServiceName("my-service")
    .spanReporter(spanReporter)
    .build();

Key Differences

  • Brave is a more lightweight and framework-agnostic tracing library
  • Spring Cloud Sleuth provides deeper integration with Spring ecosystem
  • Brave offers more flexibility for custom implementations and non-Spring projects
  • Spring Cloud Sleuth abstracts some complexity but may limit fine-grained control

Use Cases

  • Choose Spring Cloud Sleuth for Spring-based applications with existing Spring Cloud components
  • Opt for Brave in non-Spring projects or when requiring more customization and portability

Both libraries are actively maintained and provide robust distributed tracing capabilities. The choice between them often depends on the specific project requirements and existing technology stack.

16,917

Zipkin is a distributed tracing system

Pros of Zipkin

  • Full-featured distributed tracing system with a web UI for visualization
  • Supports multiple storage backends (Cassandra, Elasticsearch, MySQL)
  • Provides a complete ecosystem with various language libraries and integrations

Cons of Zipkin

  • More complex setup and configuration compared to Brave
  • Higher resource consumption due to its comprehensive feature set
  • Steeper learning curve for newcomers to distributed tracing

Code Comparison

Zipkin (Java):

Span span = tracer.newTrace().name("encode").start();
try {
  doSomethingExpensive();
} finally {
  span.finish();
}

Brave (Java):

Span span = tracer.nextSpan().name("encode");
try (Tracer.SpanInScope ws = tracer.withSpanInScope(span.start())) {
  doSomethingExpensive();
} finally {
  span.finish();
}

Key Differences

  • Brave is a tracer library, while Zipkin is a complete tracing system
  • Brave can be used as a standalone library or integrated with Zipkin
  • Zipkin offers more out-of-the-box features and visualizations
  • Brave provides more flexibility for custom implementations and integrations

Both projects are part of the OpenZipkin organization and can be used together, with Brave serving as a tracer library that reports to a Zipkin server for a comprehensive tracing solution.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Gitter chat Build Status Maven Central

Brave

Brave is a distributed tracing instrumentation library. Brave typically intercepts production requests to gather timing data, correlate and propagate trace contexts. While typically trace data is sent to Zipkin server, third-party plugins are available to send to alternate services such as Amazon X-Ray.

This repository includes dependency-free Java libraries and instrumentation for common components used in production services. For example, this includes trace filters for Servlet and log correlation for Apache Log4J.

You can look at our example project for how to trace a simple web application.

What's included

Brave's dependency-free tracer library works against JRE6+. This is the underlying api that instrumentation use to time operations and add tags that describe them. This library also includes code that parses X-B3-TraceId headers.

Most users won't write tracing code directly. Rather, they reuse instrumentation others have written. Check our instrumentation and Zipkin's list before rolling your own. Common tracing libraries like JDBC, Servlet and Spring already exist. Instrumentation written here are tested and benchmarked.

If you are trying to trace legacy applications, you may be interested in Spring XML Configuration. This allows you to set up tracing without any custom code.

You may want to put trace IDs into your log files, or change thread local behavior. Look at our context libraries, for integration with tools such as SLF4J.

Version Compatibility policy

All Brave libraries match the minimum Java version of what's being traced or integrated with, and adds no 3rd party dependencies. The goal is to neither impact your projects' choices, nor subject your project to dependency decisions made by others.

For example, even including a basic reporting library, zipkin-sender-urlconnection, Brave transitively includes no json, logging, protobuf or thrift dependency. This means zero concern if your application chooses a specific version of SLF4J, Gson or Guava. Moreover, the entire dependency tree including basic reporting in json, thrift or protobuf is less than 512KiB of jars.

There is a floor Java version of 1.6, which allows older JREs and older Android runtimes, yet may limit some applications. For example, Servlet 2.5 works with Java 1.5, but due to Brave being 1.6, you will not be able to trace Servlet 2.5 applications until you use at least JRE 1.6.

All integrations set their associated library to "provided" scope. This ensures Brave doesn't interfere with the versions you choose.

Some libraries update often which leads to api drift. In some cases, we test versions ranges to reduce the impact of this. For example, we test gRPC and Kafka against multiple library versions.

Artifacts

All artifacts publish to the group ID "io.zipkin.brave". We use a common release version for all components.

Library Releases

Snapshots are uploaded to Sonatype which synchronizes with Maven Central

Library Snapshots

Snapshots are uploaded to Sonatype after commits to master.

Version alignments

When using multiple brave components, you'll want to align versions in one place. This allows you to more safely upgrade, with less worry about conflicts.

You can use our Maven instrumentation BOM (Bill of Materials) for this:

Ex. in your dependencies section, import the BOM like this:

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>io.zipkin.brave</groupId>
        <artifactId>brave-bom</artifactId>
        <version>${brave.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

Now, you can leave off the version when choosing any supported instrumentation. Also, any indirect use will have versions aligned:

<dependency>
  <groupId>io.zipkin.brave</groupId>
  <artifactId>brave-instrumentation-okhttp3</artifactId>
</dependency>

With the above in place, you can use the property brave.version to override dependency versions coherently. This is most commonly to test a new feature or fix.

Note: If you override a version, always double check that your version is valid (equal to or later) than what you are updating. This will avoid class conflicts.