Skip to content

Latest commit

 

History

History
135 lines (98 loc) · 5.85 KB

2018-11-23-distributed-tracing-microservices.adoc

File metadata and controls

135 lines (98 loc) · 5.85 KB
Raw
layout title categories author_picture author_github seo-title seo-description blog_description
post
Enhancements to distributed tracing in microservices with MicroProfile 2.1 (and more)
blog
Enhancements to distributed tracing in microservices - OpenLiberty.io.
A quick roundup of some things you can try in the current Open Liberty development builds. Options to skip tracing of JAX-RS requests and using alternative formats of span names in MicroProfile OpenTracing 1.2. Also, try out writing simpler Dockerfiles by packaging your server as a TAR file, and try the support for sharding in Java 11 with JDBC 4.3.
A quick roundup of some things you can try in the current Open Liberty development builds. Options to skip tracing of JAX-RS requests and using alternative formats of span names in MicroProfile OpenTracing 1.2. Also, try out writing simpler Dockerfiles by packaging your server as a TAR file, and try the support for sharding in Java 11 with JDBC 4.3.

Enhancements to distributed tracing in microservices with MicroProfile 2.1 (and more)

Enhancements to distributed tracing (MicroProfile OpenTracing 1.2)

Distributed tracing enables users to see the flow of requests between microservices, including seeing which microservices have high latency and seeing the hierarchy of calls between applications and their dependent microservices.

In MicroProfile OpenTracing 1.2, you can now also:

  • Skip tracing of JAX-RS requests by specifying a regular expression that matches UriInfo.getPath()

  • Use an alternative format for span names. The new format is <http method>:/@Path value of endpoint’s class>/<@Path value of endpoint’s method>. For example, GET:/inventory/list

Enable the two new functions by defining two keys using MicroProfile Config (e.g. in server.xml or bootstrap.properties):

  • mp.opentracing.server.skip-pattern

  • mp.opentracing.server.operation-name-provider

See also:

Package server TAR files for simpler Dockerfiles

Liberty’s server package tool now supports packaging to .tar and .tar.gz files. The package tool has long supported generating to .zip and .jar files (and on z/OS .pax) but, until now, the most common packaging format on Linux hasn’t been an option.

So why now? It all relates to making Liberty work better with Docker. Docker’s ADD command has built-in support for extracting .tar files. Adding a server package to your Dockerfile is now really simple.

Instead of doing this:

   FROM open-liberty
   COPY defaultServer.zip /tmp/defaultServer.zip
   EXEC apt-get update && apt-get install unzip && unzip /tmp/defaultServer.zip /opt/ol/ && apt-get remove -y unzip && rm -rf /var/lib/apt/lists/*

you can now simply write:

   FROM open-liberty
   ADD defaultServer.tar.gz /opt/ol/

Support for sharding in Java 11 (JDBC 4.3)

We’re currently working on Java 11 support for Open Liberty and it mostly works but isn’t complete yet.

If your JDBC driver supports the 4.3 specification level, the JDBC 4.3 feature enables you to take advantage of new capabilities in JDBC 4.3, including requesting connections and support for sharding. This feature requires Java 11.

It is now possible to request connections for a specific sharding key and optionally, super sharding key, if your database supports sharding and provides a JDBC 4.3 compliant driver.

Enable the feature in your server configuration (server.xml):

<featureManager>
  <feature>jdbc-4.3</feature>
  <feature>jndi-1.0</feature>
  ...
</featureManager>

Configure one or more data sources in the server.xml as you would with the prior version JDBC features. For example:

<dataSource jndiName="jdbc/43datasource">
  <properties databaseName="sampledb" serverName="host1.rchland.ibm.com" portNumber="1234"/>
  <containerAuthData user="user1" password="pwd1"/>
</dataSource>

Use the data source from your application in your app:

@Resource(lookup = "jdbc/43datasource")
DataSource datasource;
// Always cache sharding keys to ensure that matching of pooled connections can be successful.
// The JDBC spec does not require an .equals implementation.
ShardingKey key1, key2;
...
public void init(ServletConfig config) throws ServletException {
    try {
        key1 = datasource.createShardingKeyBuilder().subkey("key1", JDBCType.VARCHAR).build();
        key2 = datasource.createShardingKeyBuilder().subkey("key2", JDBCType.VARCHAR).build();
    } catch (SQLException x) {
        throw new ServletException(x);
    }
}
...
try (Connection con = datasource.createConnectionBuilder().shardingKey(key1).build()) {
    // use connection
}

See also:

Try it now in development builds of Open Liberty

Take a look at the latest Open Liberty development builds.