Getting Started Quickly With PHP Logging

The previous articles in this series covered the basics of logging in C#, Java, Python, Ruby, Node.js, and JavaScript. In this post, I’ll show you how to use logging techniques in yet another very popular language: PHP.

I’ll open with a quick example of manual logging in PHP. Then we’ll revisit the details of why logging matters and what your logs should show. And lastly, I’ll show you how to set up and use the most popular PHP logging framework.

Let’s get started, then!

php_logging_scalyr
Read More

How to Create a Docker Image From a Container

In this article, I’ll provide step-by-step instructions on how to create a Docker container, modify its internal state, and then save the container as an image. This is really handy when you are working out how an image should be constructed, because you can just keep tweaking a running container until it works like you want it to. When you’re done, just save it as an image.

Okay, let’s jump right into it.

create_docker_image_container_scalyr
Read More

Orchestrating Microservices: A Guide for Architects

Well, microservices sure are getting a lot of attention these days. It’s almost uncool to like them, as they are so mainstream. When you have all these separate modules doing their own things, the question inevitably comes up: How do we stitch them together?

The answer? Very carefully. Here are some tips you can use if you find yourself in the position of needing to orchestrate your microservices.

orchestrating_microservices_guide_architects
Read More

Microservices Logging Best Practices

Microservice architecture is an application structure that fosters the use of a loosely coupled system to allow you to develop, test, deploy, and release services independently of each other. These services are part of a unique system, and the idea behind using microservices is to break a big problem in smaller problems. Usually, each service interacts with the others through an HTTP endpoint, hiding the details of its technology stack by exposing only a contract to its consumers. Service A will call Service B, which at the same time calls Service C. Once the request chain is complete, Service A might be able to respond to the end customer that initiated the request.

Microservice architecture offers a lot of great benefits like the ability to use different technology stacks, deploy independently, solve small problems one at a time, and more! But using microservices comes with a high cost in that they are complex…not only in how they communicate but also in how to manage them. And they get even more complicated when one or more services fail. Which service failed? Why, and under what circumstances? All these questions are hard to answer if you don’t have good, meaningful logs.

And let’s be honest, we all hate those “unknown” or “something went wrong” system errors. I myself have struggled with the problems that come from a lousy logging strategy. Let me share a few best practices that have helped me when dealing with microservices.

microservices_logging_best_practices

Read More

Log4j2 Configuration: A Detailed Guide to Getting Started

We covered basic logging for Java applications a while back. In that tutorial, we used log4j version 2, a logging framework from the Apache project. Let’s go one step further with Java application logging and look at log4j2 configuration.

Log4j’s capabilities have made it one of Java’s most popular logging frameworks. It can be configured for multiple logging destinations and a variety of log file formats. Log messages can be filtered and directed at the individual class level, giving developers and operations personnel granular control over application messages.

Let’s examine these mechanisms by configuring log4j with a command line Java application.

log4j2_configuration_guide_scalyr

Read More

Get Started Quickly With Spring Boot Logging

Hot on the heels of the Get Started Quickly With Python Logging and Getting Started Quickly With C++ Logging articles, we’re headed across the coffee shop to look at logging in the context of the Java Spring Boot framework. While we’ve written already on the topic of Java logging in Get Started Quickly With Java Logging, the Spring Boot framework simplifies a lot of the plumbing involved in getting up and running. In this article we’ll learn how to:

  • Create a Spring Boot starter project
  • Use Gradle to build our application
  • Configure the default Spring Boot logger
  • Use Log4j2 with Spring Boot
  • Customize the logging configurations

Grab your Venti red-eye triple espresso with almond milk, and let’s get started!spring_boot_logging_scalyr

Read More

Getting Started With the Rails Logger

Let’s continue our ongoing series on getting starting with loggers for different languages and platforms. Back in March, we covered logging with Ruby; now it’s time to take a look at the platform most often associated with that language, Rails.

We’ll start with a simple application with scaffolding for CRUD operations on a single record. We’ll look at Rails’ default logging configuration and how to use logging in an application. Then we’ll look at how logging can be improved and why you might want to improve it.

This tutorial uses Ruby v2.5.1 and Rails 5.2.0. You’ll need to have them installed to follow along. These instructions will use the command line to create and configure the application and will not rely on a specific IDE or editor. We’ll let Rails use SQLite for the backend database.rails_logger_scalyr

Read More

Getting Started Quickly With C++ Logging

Since publishing my article Get Started Quickly With Python Logging, I’ve been working on a couple of C++ projects where I’ve found a need for more robust logging solutions than a simple time stamp and message written to a file.

Since we also have articles on logging for C# and Java, it made sense to continue the series with an article on C++ logging with Boost.Log. Specifically in this article we are going to:

  • Create a simple Visual Studio 2017 project.
  • Install the Boost libraries using the NuGet package manager.
  • Learn how to configure log output formatting.
  • Add custom attributes to our logger.

This article is a big one, so strap in and let’s get started.

getting_started_quickly_with_c++_logging_scalyr

Read More

How Serverless will Change DevOps

This post on Serverless is from guest author Limor Wainstein, email is limor@agileseo.co.il.

During the past decade, both DevOps and serverless have become quite popular for software development. These not only challenged the way software is being developed but also affected the entire software development lifecycle. First of all, let’s try to understand serverless and DevOps are.

Serverless and DevOps

Serverless is commonly used in conjunction with terms such as architecture, computer, and services. In brief, serverless architecture refers to the solution architecture of software applications built using fully managed third-party services (serverless services) as core dependencies. At its core, serverless computing provides runtimes to execute code, which is also known as function as a service (FaaS) platforms.

DevOps is a collection of practices and tools that increase the ability to deliver (build, test and deploy) applications and services more efficiently. DevOps requires more automation and eliminating overhead in setting up the infrastructure as well as in the build and deployment of code. DevOps does not only affect the technology; DevOps is also targeted at people and team structures.

Continuous Integration (CI) and Continuous Delivery (CD) tools are used to build, test and deploy code and are often done using build automation  Tools that provide fast resolution of errors and bugs are equally crucial.

In addition to using FaaS, fully-managed Docker containers as a service are also evolving. For example, technologies such as AWS Fargate allow to run these Docker containers and scale them without needing to provision and manage any underlying infrastructure. This is useful for DevOps since the containers can also be used to build, test and deploy applications.

Fully Managed DevOps Services

Fully managed DevOps services are beginning to emerge for CI and CD where these services are offered in software as a service (SaaS) models, or hosted services like Travis, Circle CI where the respective third-party service providers manage the underlying infrastructure and services. These services could range from semi-managed to fully managed serverless services that are used for the core of DevOps.

Docker containers underly many of these managed services, and these containers are used to allow isolated and customized build environments. Some services such as AWS Code Build enable defining the Docker image together with the required libraries and tools. This allows direct execution of the build job without needing to reinstall for each build. Various orchestration tools are used by these managed services, such as Kubernetes, Docker Swarm, AWS ECS, to control the fleets of containers.

DevOps Tools with Serverless.

There is also a tendency towards implementing DevOps using serverless architectures. The ability to implement unique and efficient CI/CD tailored to the application requirements, consumption-based cost models, supportive services (e.g., AWS Code Build, AWS Code Pipeline, etc.) create attraction towards this approach. By using serverless services, it is possible to implement an entire build, test and deploy pipeline by writing the glue code using serverless services, without using any hosted solutions.

Open Source and Serverless

Over the past few years, many open source DevOps tools started emerging. One of the most popular open source DevOps tools is the Serverless Framework.

The Serverless Framework allows simplification by:

  • Declaring the microservices infrastructure, endpoints and mapping it with execution logic (for example, with a Lambda function).
  • Building artifacts, archiving and deploying to infrastructure.
  • Extending DevOps capabilities using plugins.

Cloud providers are also beginning to develop similar tools. For example, AWS recently introduced its AWS Serverless Application Model (SAM) which could potentially replace the Serverless Framework functionality when it comes to declaring the serverless APIs. Contributions by the open source community do keep the Serverless Framework supporting newly-introduced AWS services as they appear.

In addition, open source security is becoming a challenge when using third-party libraries. On the other hand, vulnerability scanning is also becoming a commodity, especially with the introduction of the NPM scanning process. This has helped to reduce the development risks in building applications.

Infrastructure as Code

With the adoption of serverless architectures, infrastructure provisioning has become a significant part of the deployment process. Applications are using different serverless services as building blocks, so it is crucial to be sure that these services are correctly configured and connected. One of the best practices is to define the infrastructure in the code using declarative tools and languages like Terraform. This enables versioning of the infrastructure along with the code thus reducing the manual work on the DevOps process.

Immutable Infrastructure

Another effect of serverless for software application development is how we look at the serverless services modifications. It is often possible to provision new instances of serverless services while keeping the existing instances running. This means you can deploy new instances of serverless services and switch to the more recent version upon success. Serverless has made Blue-Green and Canary deployments both more practical and affordable for various applications.

Distributed DevOps

Using serverless technologies for application development means that DevOps has to deal with distributed systems. While it’s possible to use different serverless services from different providers, configuring a CI/CD pipeline involves coordinating these operations. This adds further complexity to the DevOps processes. It is important to implement more visibility into each serverless service with detailed monitoring when these services are provisioned once a change had been made.

Summary

Overall, we’ve outlined a few ways in which serverless is changing DevOps practices used for software development. To wrap up, let’s look at several best practices for serverless and DevOps.

  • Implement automation for CI/CD.
  • When implementing tests such as code style, unit tests, integration tests, UI tests, make them a part of development routine checks.
  • Upon committing the code, try to run the code style checking using git lifecycle hooks if possible.
  • Automate as needed to support building the artifacts, running all the test cases and send the results back to Pull Request using a CI tool.
  • Rerun the tests before deployments, preferably through an appropriate deployment trigger.
  • Include the infrastructure in the code.
  • Use managed services for CI/CD whenever possible to reduce the overhead of infrastructure management.
  • Design an application for rollback support for both previous versions and database migrations.
  • If it’s a database change, create scripts that can both apply and revert the changes.
  • Create version and store deployments in a durable place.
  • Allow deploying specific versions of application deployment.
  • Choose tools that help streamline the debug and monitoring cycle.

Separating the deployment cycles of serverless projects allows teams to make changes without redeploying the entire application. It remains vital to learn and understand the changes introduced by DevOps and serverless process and technologies and to adapt accordingly so that the DevOps processes are aligned to support serverless applications.

Bio:
Limor is a technical writer and editor at Agile SEO, a boutique digital marketing agency focused on technology and SaaS markets. She has over 10 years’ experience writing technical articles and documentation for various audiences, including technical on-site content, software documentation, and dev guides. She specializes in big data analytics, computer/network security, middleware, software development and APIs.
Twitter: @LimiMaayan

The 10 Commandments of Logging

When you search for things on the internet, sometimes you find treasures like this post on logging, e.g. creating meaningful logs.

This post, from a few years back, is authored by Brice Figureau (found on Twitter as @_masterzen_). His blog clearly shows he understand the multiple aspects of DevOps and is worth a visit.

In recent discussions with Brice, he stated that he believes the rules are still quite valid with some tweaks needed for containers and Kubernetes and that in today’s world of GDPR, logging sensitive data is a non -starter. But these rules are informative and worth consideration.

Our thanks to Brice for letting us repost his blog under Creative Commons CC-BY.

Guest author Brice Figureau

2 stone tablets with Roman numerals from 1 to 10
Copyright: moises / 123RF Stock Photo

After writing an answer to a thread regarding monitoring and log monitoring on the Paris DevOps mailing list, I thought back about a blog post project I had in mind for a long time.

I wrote this blog post while wearing my Ops hat and this is mostly addressed to developers.

Knowing how and what to log is, to me, one of the hardest tasks a software engineer will have to solve. Mostly because this task is akin to divination. It’s very hard to know what information you’ll need during troubleshooting… That’s the reason I hope those 10 commandments will help you enhance your application logging for the great benefits of the ops engineers 🙂

1. Thou shalt not write log by yourself

Read More