Hecklers in Development
Code, coffee, & camaraderie. Collection, unordered. ;)
As you begin to divide conglomerate functionality into discrete, decoupled microservices, you introduce a number of opportunities and challenges into your system(s). The opportunities are often well-known, including (and especially!) development velocity, fidelity/fit (functionality matches requirements), scalability, and a host of other “ilities”.

 

Challenges also exist of course, including the question of how to gain visibility into end-to-end interactions involving multiple microservices across process and network boundaries. Spring Cloud Sleuth provides a lightweight, configurable, and easy way to begin capturing trace information within your distributed system.

 

Distributed tracing: a (very) high-level overview

 

In 2010, Google published their seminal paper titled Dapper, a Large-Scale Distributed Systems Tracing Infrastructure.

 

In 2012, Twitter created Zipkin during their first Hack Week, based upon the Dapper paper.

 

Briefly, an entire end-to-end interaction that completes a request cycle (regardless of transport/mechanism) is referred to as a “trace”, and each trace consists of multiple “spans” connecting the endpoints of each hop. From the Spring Cloud Sleuth project page:

A Span is the basic unit of work. For example, sending an RPC is a new span, as is sending a response to an RPC. Span’s are identified by a unique 64-bit ID for the span and another 64-bit ID for the trace the span is a part of. Spans also have other data, such as descriptions, key-value annotations, the ID of the span that caused them, and process ID’s (normally IP address). Spans are started and stopped, and they keep track of their timing information. Once you create a span, you must stop it at some point in the future. A set of spans forming a tree-like structure called a Trace. For example, if you are running a distributed big-data store, a trace might be formed by a put request.

Sometimes within the Spring space, you hear about Sleuth and Zipkin within the same discussion, often within the same breath…which understandably can result in a bit of confusion on the listener’s part. Without diving too far down the rabbit hole, Sleuth provides the means to instrument your Spring Boot/Spring Cloud applications; Zipkin can take that data and provide a means to monitor and evaluate it. Zipkin provides numerous integrations, but of course, you can also use other log monitoring & management tools to collect and analyze that vital data.

 

Minimum Viable Product

 

This post focuses upon Sleuth and provides a quick on-ramp to getting started capturing basic information for each span. To do that, I’ve created these two projects that allow us to quickly add trace & span (& more) information to our interactions and verify it in our logs.

 

Creating a provider service

Starting at the Spring Initializr, I added the following dependencies to a project and named the artifact sz-provider-service:

(click/tap to enlarge)

 

After generating the project and downloading, extracting, and opening it in our IDE, we see the selected dependencies in our Maven pom:

 

 

Or if using Gradle, build.gradle:

 

 

To provide better context within our logs for our tracing data, we’ll add the following entry to our application.properties file:
spring.application.name=sz-provider-service

 

For this example, we’ll create a very simple RestController so we have something in our provider microservice to contact from a consumer service. Here is the entirety of the relevant code:

 

 

The only thing of particular note is the @Log statement. Lombok provides this capability to reduce the usual boilerplate code required to get a logger via LogFactory.

 

Creating a consumer service

For the purpose of this introduction, little changes between provider and consumer project configuration & code. Here are the exceptions:
  • Revisiting the Spring Initializr, we change the artifact name to sz-consumer-service, keeping the same dependencies
  • We add the following entries to our consumer microservice’s application.properties file:
spring.application.name=sz-consumer-service
server.port=8081

 

NOTE: We’re running the provider on port 8080 (Tomcat’s default port), so we change our consumer service’s port to 8081 to avoid conflict.

 

  • This is the code for our consumer:

 

 

The same note about Lombok’s @Log applies here as well, of course.

 

The results

 

Running the two applications, we can now access the consumer’s endpoint from httpie, cURL, or a browser:

 

 

Doing so results in the following log entries from our consumer service:

 

 

And our provider service:

 

 

Examining our log entries for both services (above), we see that Spring Cloud Sleuth has placed our spring.application.name (as designated in each service’s application.properties), the appropriate trace id, and the span id specific to this hop within the logged information.

 

Summary

 

Of course, Sleuth captures much more data and allows for extensive customization (including enabling additional elements you specify to be captured, adjusting sampling rates, & more), and Zipkin remains a topic for another day. But this post should have provided a quick springboard (!) into using Spring Cloud Sleuth for better insight into your microservices-based system of systems.

 

Happy Sleuthing!

 

Like this post? Follow me on Twitter for more! And be sure to check out the Related Posts below.

 

Additional information

 

Share

Related Posts:


Tags: , , , , , , , , , , ,
Many of us use JSON almost exclusively now, which is generally a good thing. But what happens when you need to “speak XML” with your Spring Boot REST endpoints?

 

XML support in Spring Boot’s REST endpoints is not enabled by default, but adding it isn’t difficult at all. Simply add the following dependency to your POM (or similar entry to your Gradle build file, if that’s the way you roll) and rebuild:

 

 

Now, to test our results. To do so, I’m using the excellent httpie, with its shortcut that allows the omission of the hostname for localhost.

 

JSON

 

XML

 

 

Note that no changes are required to your code, as Spring Boot assesses your classpath and adds XML support via auto-configuration. Simple and painless! 🙂

 

Thanks for reading, be sure to follow me on Twitter for future tips!

 

Keep coding,
Mark
Share

Related Posts:


Tags: , , , , , , , , , ,

Just a quick tip for the Spring fans out there…

 

I was leading a workshop yesterday and this question arose: Is it possible to filter requests by header content using Spring’s various request mapping (@RequestMapping, @GetMapping, @PostMapping, et al) annotations?

 

Not only is it possible, it’s easy, and the implementation is concise & clean! Let’s take a look.

 

The code

Here is a simple example that filters based upon the content-type of the header:

 

 

To test this, simply visit the Spring Initializr, create a simple Spring Boot app with a single dependency (Web), download & unzip it, and add the code above using your favorite IDE. Then build & run it (of course)! 😉

 

The output

Using httpie (which is quickly becoming my favorite CLI HTTP client), we can verify our results:

 

Request content type of text/plain

 

Request content type of application/json

 

NOTE: The above examples use httpie “shorthand”, which assumes localhost when the base URL is omitted.

 

That’s all for now, but stay tuned (or follow me on Twitter) for more quick (or more lengthy) Spring tips!

 

Cheers,
Mark

 

Click here for additional information

 

Share

Related Posts:


Tags: , , , , , , , ,

Just a quick tip for the Spring fans out there…

 

If you’ve decided to try out Spring Boot Actuator – and if you haven’t you really should! – you may have run into one of two interesting hitches that are easily resolved:

 

  1. You are unable to access any of the various Actuator endpoints (/beans, /env, et al)
  2. You can access those endpoints and yet are unable to access /actuator, the primary (navigable) Actuator endpoint

 

Unable to access any Actuator endpoints

 

In the case of point #1 above, you may see this in your logs:

 

s.b.a.e.m.MvcEndpointSecurityInterceptor : Full authentication is required to access actuator endpoints. Consider adding Spring Security or set ‘management.security.enabled’ to false.

 

For testing, it’s adequate and acceptable to simply add the suggested entry to your app’s application.properties file:

 

management.security.enabled=false

 

This is far less likely to be a suitable solution for production apps, though. 🙂  Enabling Spring Security properly to secure access to your application is a far more production-ready option.

 

Unable to access /actuator

 

If you can load successfully the various Spring Boot Actuator endpoints but get a 404 error on /actuator, the primary (navigable) Actuator endpoint, you are hitting a different (yet also easily resolved) snag. The hint is in how I phrased the difficulty: the primary (navigable) Actuator endpoint.

 

In order to access /actuator, which uses hypermedia to provide a navigable structure of links to Actuator endpoints, you must include HATEOAS (spring-boot-starter-hateoas) on your classpath. Adding this to your POM will fix that nicely:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-hateoas</artifactId>
</dependency>

That’s all for now, but stay tuned (or follow me on Twitter) for more quick or lengthy Spring tips!

 

Cheers,
Mark

 

Click here for more information about Spring Boot Actuator.

Share

Related Posts:


Tags: , , , , , , , ,

Or “How to build a portable self-powered, self-licking ice cream cone.”  😀

 

Portable IoT Demo

 

Several years ago, I started building what I referred to affectionately as a self-licking ice cream cone: a Renewable Energy (RE) system that powered the same IoT system that monitored it. I’ve given several talks about this system, both its hardware and its software stack, and there are so many useful (and scalable) lessons I’ve learned that I really enjoy sharing. Still learning those lessons too, btw.

 

Recently, Stephen Chin asked me if I could put together a portable RE IoT system to demo in the MakerZone at JavaOne this year. If a picture is worth a thousand words, a fully-built and on-premises demo must be worth at least a million, right? The idea intrigued me. Could I create a 100% fully-capable representation of a (my) real working system that would be small enough to transport to conferences and meaningful for attendees to see? Yes…yes, I thought I could.  🙂

 

It has been a lot of work fun!

 

There is much to tell, but we’ll stick to the high points for this post. More to follow.

 

Hardware List and Related Observations

 

For the portable configuration, here is the hardware I used:

  • One (1) 50W, 12V photovoltaic (PV) panel, bought via ebay
  • One (1) Cyber 250 wind turbine
  • One (1) 18Ah 12V deep cycle battery for energy storage and IoT system power
  • One (1) sheet of Lexan cut to size and edged, courtesy of Regal Plastics in St. Louis
  • One (1) Raspberry Pi, case, SD card, & wifi plug adapter – this serves as the IoT gateway device
  • One (1) 5V DC voltage regulator, allowing me to step down the 12V battery output to the 5V required by the Pi
  • One (1) Arduino Uno R3, solderless breadboard, combined mounting board – this represents an IoT endpoint
  • One (1) Adafruit INA219 high-side DC current sensor breakout
  • One (1) Virtuabotix DHT11 temperature & humidity sensor
  • One (1) 4 channel DC 5V relay to control physical devices
  • One (1) LED case cooling fan
  • One (1) interior/dome light to represent building interior lighting
  • Two (2) running lights to serve as loads for two RE inputs/charge controllers
  • Two (2) solar charge controllers**
  • One (1) 12 position terminal strip/wiring block
  • Numerous (?) solder joints, wires, and cables

** I was able to use solar charge controllers for both solar/PV and wind inputs because the wind turbine I selected produces 12V DC power (vs. the AC power output of many turbines) and has a blocking diode to prevent overspeeding, and thus turbine damage. These charge controllers also have load connectors, to which I attached lamps to maintain loads on the inputs, further reducing potential for overspeeding.

 

This configuration closely follows my permanent installation at my house, albeit at a much smaller scale. For transportability, I’m using only a single 18Ah 12V deep cycle battery instead of several larger-capacity 12V deep cycle batteries wired in parallel to form an energy storage array. And input sensors have been reduced from a full weather station providing temperature, humidity, rainfall, wind speed & direction, ambient lighting, and atmospheric pressure readings to (for the demo system) temperature and humidity. Power readings are comparable for both systems, although I’m using a separate INA219 sensor on the demo system vs. integrated power sensors in the permanent system’s weather circuitry. And my portable system has no actuators to open windows in my power-generation building like my permanent system does. Since the demo system is fully visible to viewers, there was no need to configure a camera for visual observation/checks as I did at home. In actuality, there are few substantive differences between my 24/7/365 production system and this portable demo. 🙂

 

One nice feature of this portable rig: as configured, it produces far more energy than it consumes, even with a fan providing the “wind” and venue lighting providing the “sun”. Power won’t be a problem.

 

Software and Related Observations

 

The software stack for the demo system is nearly identical to that of the production system, with minor changes being made to accommodate the minor differences in attached sensors and physical devices.

 

I developed software for the Arduino microcontroller to run in Autonomous Mode using sensible defaults, turning on heat when ambient temperature inside the power-generation building is too low, turning on a cooling fan when it’s too hot, and opening windows on opposite sides of the building when temps climb and no rain is present (no windows in the demo config, of course). The Arduino represents an IoT endpoint that regularly (1x/second) polls attached sensors, assembles their readings, and sends them “upstream” to the IoT gateway. It also processes any inputs received from the gateway and acts accordingly; if it receives a command to switch to Manual Override, the software then accepts and processes any subsequent (validated) commands from the gateway until directed to resume with Autonomous Mode.

 

For the IoT gateway, I used Linux and Java SE Embedded to create a secure and standards-based stack. Raspbian Linux allows me to use utilities like ssh and vnc and to set up startup scripts for the demo config…and since it ships with Java SE Embedded, I have easy access to developer tool support and libraries for everything from RESTful web services to Websocket, which I use for system/cloud communication. I used the JSSC (Java Simple Serial Connector) library to create a wired connection from gateway to endpoint, Pi to Arduino, establishing a reliable comm link within the remote IoT system.

 

IoT systems are great! But without a way to communicate with, control, and harvest meaningful data from those systems, their usefulness is severely constrained. To unleash the full value of an IoT system, you need the cloud. I used Java SE, Spring Boot, and Spring Cloud OSS to do the heavy lifting with an HTML5/JS user interface, all running on Pivotal Cloud Foundry. I’m still tweaking and expanding it (in my copious spare time 😉 ), but it’s effectively feature-complete…and with only minor differences (to accommodate the sensor/device differences) between the permanent and demo systems.

 

And…action!

 

 

More to Come

 

Come see me at JavaOne! This will be up and running in the MakerZone all week, so stop by to see it and chat with the crew there. If you have any questions, comments, or feedback of any kind, please ping me on Twitter at @MkHeck or leave a comment below. Hope to see you there!

 

Keep coding,
Mark

 

Share

Related Posts:


Tags: , , , , , , , , , ,

Powered by Wordpress
Theme © 2005 - 2009 FrederikM.de, heavily modified by Mark Heckler
BlueMod is a modification of the blueblog_DE Theme by Oliver Wunder