When developing and running apps inside Microsoft Azure you have to deal with the topics like monitoring and logging. Azure provides a central solution for that questions which is Application Insights. AppInsights (for short) is the central hub to get metrics and log data from our applications and let you access these data within the azure portal in an easy and convenient way. While the metric aspect is well documented, how to connect your favorite application logger to AppInsights it is not.
In this blog post we will show you how to enhance your typical Spring-Boot application to have all the logging data send to Azure AppInsights automatically. In a followup post we will show the same for a typical nodejs based application.
Deploying a Docker container on Azure ‘Web App for Containers’ can be done fairly easy. In this blog post, I will provide a step by step guide to get you started. Some basic knowledge of Azure and Docker definitely helps. But why should you care in the first place? You will get:
- a managed runtime (for a single image)
- scaling to multiple instances
- a simple deployment model
- easy integration with App Insights (Azure’s Monitoring system for Web Apps)
- use any Azure SaaS like CosmosDB, MSSQL, …
We have been using successfully Jenkins for a long time, but our Jenkins environment was very outdated. The master and its slaves were still running on JDK1.6 with Jenkins version 1.456. So it was “very” old. Even the installation of new plugins was impossible because these were usually based on Java7. Overall we have 20 Jenkins slaves for 27 projects and 200 jobs. The projects are in several states: just started, ongoing, release or maintanence. The normal project work should not be disturbed by this upgrade.
Therefore we decided not to update the existing installation but to use a completely new Jenkins and update the JDK too.
In this post we will describe what is needed to get started with managing your EAP 6 logs with ElasticSearch, Logstash and Kibana. There are several reasons why you would want to collect your logging output in a central place.
- Aggregate (output from multiple applications / hosts)
- Correlate events in different systems
- Analyze (more than grep)
- Integrate into monitoring
- Gather statistics
A common solution that supports all this use cases is provided by the ELK stack. It consists of ElasticSearch (ES), Logstash and Kibana. ElasticSearch provides persistence and analytics, Logstash provides the pipeline that brings your Logs into ES and Kibana provides a GUI for querying and dashboards.
This article describes how to turn the subfolders in a git repository into new git repositories, keeping the history.
In our case we have a big git repository (2GB) with slides for a lot of courses. Every course was a subdirectory in the repository. So even if you hold just one course, you have to clone everything. That’s why we decided to put every course into a separate repository. We use SCM-Manager for our repository and could therefore use its REST api in the script.
Just in time for the holidays here is the new Technology Radar 2013 🙂
Have a look: http://radar.spree.de/results
This year the radar provides an overview of the trends for technologies, methods and tools in software development for 2013/2014. It is separated into 6 categories:
- Platforms & Middleware
- Frameworks & Libraries
Have a look for trends in 2014 and technologies to build on. You can download the radar: Technology Radar 2013 Print Version
Happy Holidays and a Happy New Year
The number of release process executions is steadily increasing. Concepts like Continuous Delivery and Deployment emphasize releasing as often and as automated as possible. While developers and customers enjoy the bright side of the improving software development processes, operations has to deal with the flip side. More releases mean more storage usage. Increasing process quality requirements like archiving every delivered release (or at least, every release which is deployed on a production system) in a structured, easily accessible manner somewhere means more storage. But resources like storage are limited. So you have to collect the garbage sooner or later – and if you have a lot of releases, you desperately want to automate this cleanup process.
So, if you use Sonatype Nexus as intensively as we do and you sooner or later face storage limitations: this blog post might be a solution for you. Continue reading
While maintaining our development infrastructure, we regularly have to deal with a plethora of feature and plugin wishes. Because balancing all these different wishes, requirements and purposes is so time-consuming, we considered how we might increase our performance in this area. We designed and tested a method for this in the context of a Jenkins upgrade. We then invested some more time to create a sample HTML5 presentation that you may like to use yourself to try out threshold voting workshops in action.