Building services using Spring Boot gives a development team a jump start on many production concerns, including logging. But unlike a standard deployment where logging to a local file is where the developer’s responsibility typically ends, with Docker we must think about how to log to a public space outside our ephemeral container space.
The Docker logging drivers capture all the output from a container’s stdout/stderr, and can send a container’s logs directly to most major logging solutions (syslog, Logstash, gelf, fluentd).
As an added benefit, by making the logging implementation a runtime choice for the container, it provides flexibility to use a simpler implementation during development but a highly-available, scalable logging solution in production.
Continue reading “Docker: Sending Spring Boot logging to syslog”
The Spring framework provides a proven and well documented model for the development of custom projects and services. The Spring Boot project takes an opinionated view of building production Spring applications, which favors convention over configuration.
In this article we will explore how to configure a Spring Boot project to use the Simple Logging Facade for Java (SLF4J) with a Logback backend to send log events to the console, filesystem, and syslog.
Continue reading “Spring: Spring Boot with SLF4J/Logback sending to syslog”
Especially in enterprise application development, there can be 3rd party dependencies that are not available in public Maven repositories. These may be internal, business specific libraries or licensed libraries that have limitations on usage.
When this is the case, you can either publish to a private Maven repository that controls authorization or you can put them into your local cached maven repository.
Continue reading “Maven: Installing a 3rd party jar to a local or remote repository”
An essential part of the standard build process for Java applications is having a set of repositories where project artifacts are stored.
Artifact curation provides the ability to manage dependencies, quickly rollback releases, support compatibility of downstream projects, do QA promotion from test to production, support a continuous build pipeline, and provides auditability.
JFrog puts out an open-source Maven server called Artifactory that is perfect for setting up a private Maven repository for internal applications.
Continue reading “Maven: Installing a private Maven repository on Ubuntu using Artifactory”
Selenium is an open-source solution for automating the browser allowing you to run continuous integration tests, validate performance and scalability, and perform regression testing of web applications.
This kind of automated testing is useful not only from desktop systems, but also from server machines where you may want to monitor availability or correctness of returned pages. For example, web site response monitoring or as part of a Jenkins validation pipeline.
The first method we can use to accomplish this is to use a headless driver such as the HtmlUnit or PhantomJS driver – these are tiny browser implementations that load and execute web pages but do not actually draw the results to a screen.
The second method is specific to Linux based systems, where you use the actual Chrome browser. The trick is to use Xvfb as a virtualized display.
Continue reading “Selenium: Running headless automated tests on Ubuntu”
As an exploration of AppDynamics’ APM functionality, you may find it useful to deploy a sample application that can quickly return back useful data. The Java Spring PetClinic connecting back to a MySQL database provides a simple code base that exercises both database and application monitoring.
We’ll deploy the Java Spring PetClinic unto Tomcat running on Ubuntu 14.04. MySQL will be the backing persistence engine for the web application. The AppDynamics Java agent will be loaded into the JVM running Tomcat, and the AppDynamics Database Agent will connect to MySQL for metrics gathering.
Continue reading “AppDynamics: Java Spring PetClinic and MySQL configured for monitoring”
Decompiling Java classes is sometimes associated with dubious behavior around proprietary and licensed software, but in reality there are many valid reasons why one may find it necessary to dig into Java class files and jar/war archives. It can be as simple as your development team no longer having the 2 year old version of the code deployed in production.
We’ll go over a couple of ways to decompile Java classes on an Ubuntu desktop.
Continue reading “Ubuntu: Decompiling Java classes on Ubuntu using Eclipse and JD-GUI”
SLF4J, the Simple Logging Facade for Java, is a popular front for various logging backends, one of the being Logback. With the advent of containerization, using syslog to send data to remote logging infrastructure has become a popular transport method.
Enable Syslog Input
The first step is to enable the receipt of syslog messages. This could be any server listening for syslog messages. You can follow my previous article on configuring an Ubuntu server to receive RFC5424 compatible messages or you can configure a syslog input in Logstash.
Continue reading “Syslog: Sending Java SLF4J/Logback to Syslog”
Logging has always been a critical part of application development. But the rise of OS virtualization, applications containers, and cloud-scale logging solutions has turned logging into something bigger that managing local debug files.
Modern applications and services are now expected to feed log aggregation and analysis stacks (ELK, Graylog, Loggly, Splunk, etc). This can be done a multitude of ways, in this post I want to focus on modifying log4j2 so that it sends directly to an rsyslog server.
Even though we focus on sending to an Ubuntu ryslog server in this post, this could be any entity listening for syslog traffic, such as Logstash.
Continue reading “Syslog: Sending Java log4j2 to rsyslog on Ubuntu”
In the world of microservices and containers, it is often desirable to keep settings such as those found in dfc.properties outside of the jar or war so that the deployment binary is the same no matter which environment it is deployed into.
The settings in dfc.properties can be externalized by specifying the location of dfc.properties in a JVM system property such as: