Getting Started Quickly With Go Logging

It’s time to talk about how to get started with logging again. The languages we’ve covered so far are C#, Java, Python, Ruby, Node.js, and JavaScript. Today, we’re going to be talking about the Go programming language, also known as Golang.

Go is a statically compiled, open-source programming language created by Google in 2009. It runs on Windows, Linux, and Mac and has been increasingly adopted in the last couple of years because of its simplicity and concurrency mechanisms. And in case you didn’t know, Docker and Kubernetes were written in Go.

Go is quite an interesting language when we talk about logging. Why? For one thing, it includes a really simple native library for logging. But the most interesting thing is that in Go there are no exceptions—only errors. That means when you want to log application errors, things get interesting. We’ll cover that later in this post.

But let’s start by taking a look at how easily you can get started logging in Go.

Go Beaver With Scalyr Colors

Read More

Log Analyzer: What It Is and How It Can Help You

A log analyzer allows you to quickly search a specific set of data in a haystack of records. Think of it like bookkeeping. Accounting books tell a story for each transaction made in a period of time. To search through those transactions, you need criteria like the date and amount paid. You find the transaction log and it has more information: payment method, recipient, plus other details.

That’s what a log analyzer does: it helps you find events in a collection so you can study them and fix problems. Here’s an ideal case:

  1. An incident report provides data for log analysis.
  2. Someone reproduces this issue based on your log data.
  3. Your development team proposes a solution in a new fixed app.
  4. Someone reproduces the incident again, this time using your new app.
  5. Log analysis and testing show whether this fix was effective or not.

In this article, I’ll share insights from my experience with log analysis. Read on, draw parallels with your organization, and infer your own conclusions.

Graph with a magnifying glass over it

Read More

Five To-Dos When Monitoring Your Kubernetes Environment

If you’re on the DevOps front line, Kubernetes is fast becoming an essential element of your production cloud environment. Since container orchestration is critical to deploying, scaling, and managing your containerized applications, monitoring Kubernetes needs to be a big part of your monitoring strategy.

Container environments don’t operate like traditional ones. So, if you are monitoring your applications and infrastructure, you need to be thoughtful about how you monitor your container environment in which they are running. Here are five best practices to inform your strategy:

  1. Centralize your logs and metrics. Orchestrating your containerized services and workloads through Kubernetes brings order to the chaos, but remember that your environment is still decentralized. You will give yourself a fighting chance if you centralize your logs and metrics.
  2. Account for ephemeral containers. The beauty of container orchestration is it’s easy to start, stop, kill, and clean up your containers in short order. However, monitoring them may not be so easy. You still need to debug problems and monitor cluster activity, even when services are coming and going. The trick is to grab the logs and metrics before they’re gone. If you don’t, your metrics will look more like the graph on the left than the one on the right.
    log files examples for transient containers
  3. Simplify, simplify, simplify. With all of the moving pieces in your container environment (services, APIs, containers, orchestration tool), you need to monitor without introducing unneeded complexity. Rather than bloating your container with various monitoring agents, each requiring updates on unique schedules, abstract your monitoring and management tools from what you’re monitoring and managing. This will also help your engineers focus on building and delivering software, not operating the delivery platform.
  4. Monitor each layer explicitly. You will need to collect logs and monitor for errors, failures, and performance issues at each layer – the pod, the container, and the controller manager – of your environment. For example, you’ll need to be able to troubleshoot pod issues, ensure the container is working, and collect runtime metrics in the controller manager.
  5. Ensure data consistency across layers. For fast, accurate debugging, you need to ensure data consistency across all the layers in your container environment. Things like accurate timestamps, consistent units of measurement (such as milliseconds vs. seconds), and collecting a common set of metrics and logs across applications and components will help you troubleshoot and debug quickly and accurately across all of your layers.

One best practice for accomplishing these to-dos in a simple, straightforward manner is to monitor the containers in your Kubernetes environment without touching your application containers. Do this by introducing a DaemonSet, or alternatively a sidecar, into your Kubernetes environment(s) that sits alongside your containerized services and includes your logging and metrics collection agent. Deploying in this method will ensure consistent data collection, minimize the changes required to your application containers, and most importantly, eliminate the possibility of selective blindness in your production environment.

A few ways to implement this include:

  • Introduce a DaemonSet with the Fluentd logging agent (this will give you logging but not metrics). If you already have an ELK cluster configured, this is probably the option for you. Learn more here.
  • Introduce a DaemonSet or sidecar with the Prometheus metrics agent (CoreOS has done an excellent job of integrating Prometheus and Kubernetes). Running Prometheus on your Kubernetes cluster will give you metrics instrumentation, querying, and alerting. Learn more here.
  • A variety of metrics and performance monitoring tools, including Heapster, DataDog, cAdvisor, New Relic, Weave/VMware, and several others also offer a DaemonSet or sidecar options for Kubernetes monitoring.
  • Scalyr, log management for the DevOps front line, has a preconfigured DaemonSet containing the open source Scalyr agent available for download and use. The Scalyr DaemonSet natively supports both Kubernetes logging and metrics. You can download the YAML file for deploying the containerized Scalyr agent from GitHub here. Note that you also can download the full open-source Scalyr agent from GitHub here.

 

Network Traffic Monitoring: The 7 Best Tools Available To You

Sales, pre-sales, human resources, the company cafeteria: they’re all online. If the network is down, employees are angry and customers have gone elsewhere. That’s why network traffic monitoring is a critical part of maintaining a healthy enterprise.

Fixing network problems when they happen isn’t good enough. IT managers have to proactively watch systems and head off potential issues before they occur. This means observing network traffic and measuring utilization, availability, and performance.

A useful monitoring tool offers these features:

  • real-time network monitoring
  • an ability to detect outages in real time
  • a mechanism for sending alerts
  • integrations for network hardware, such as SNMP and NetFlow monitoring

This is a list of the best tools available for monitoring your network traffic. Several of them are sold as SaaS, others for running on-premises, and a couple are open-source with optional commercial versions. All of these tools offer more than just network monitoring. They also offer varying degrees of application, system, and web monitoring too.

Icons of tools

Read More

Get Started Quickly With JavaScript Logging

Let’s continue our series on getting started with logging. We’ve already covered C#, Java, Python, Ruby, and Node.js. This time, we’re going to look at JavaScript logging. If you’re wondering how this differs from the Node.js article, this one will look at pure client-side JavaScript logging. Once again, we’ll get into

  • Logging in a very basic way
  • What to log
  • Why you should log at the client-side
  • How to log using a client-side JavaScript logging framework

JavaScript Shield with Scalyr Colors

Read More

The Build vs Buy Decision Tree

Chocolate or vanilla? Pancakes or waffles? Coke or Pepsi? We decide between similar choices every day. Some of us have preferences, and other times it’s just a feeling in the moment. A common decision in the IT world is the “build vs buy” decision. Sometimes this decision is not so cut and dry.

Can the decision to build or buy paralyze us with fear? Certainly. Do some have preferences? Definitely. However, all is not lost. There can be a logical system to decide whether to build or buy when it comes to software.

 

The Build vs Buy Decision Tree

 

Read More

Understanding the Apache Error Log in Detail

Today features another post about the nuts and bolts of logging.  This time, I’ll be talking about the Apache error log in some detail.

Originally, I had a different plan and outline for this post.  But then I started googling for good reference material.  And what I found were way more questions than answers about the topic, many on various Stack Exchange sites.  It seems that information about the Apache error log is so scarce that people can’t agree on where to ask questions, let alone get answers to them.

So let’s change that.  I’m going to phrase this as a Q&A-based outline, hopefully answering all of the questions you might have come looking for—if you googled the term—while also providing a broad narrative for regular readers.

Apache Feather

Read More

DevOps Security Means Moving Fast, Securely

In this world of lightning-fast development cycles, MVPs, and DevOps, it may intuitively feel like security gets left behind. You might be thinking, “Aren’t the security guys the ones who want to stop everything and look at our code to tell us how broken it is right before we try to deliver it?” Many feel that DevOps security is a pipe dream.

Is it possible to be fast and secure? Lately, I’ve been drooling over a sports car—namely, the Alfa Romeo Giulia Quadrifoglio. Long name, fast car. It holds some impressive racing records and sports 505 horsepower but also is a Motor Trend Car of the Year and an IIHS Top Safety Pick. These awards are due to automatic braking technology, forward-collision warning, lane-keeping assistance, blind-spot monitoring, and rear cross-traffic alert. It is possible to be fast and safe.

The key to DevOps security is to move forward with development. Security teams need to understand why DevOps practices are so effective and learn to adopt them.

Man Running Fast with Scalyr Colors

Read More

Verbose Logging: Your Magnifying Glass for Bad Application Behavior

You probably don’t think of verbose logging as the stuff that hackathons and startups are made of.  Nor would most programmers consider it an especially advanced technique.  But it is important, and enough people ask about it that it’s worth covering.

Part of the reason that so many people inquire about the subject of verbose logging is that it’s kind of general in the same way that searching for “logging” is general.  So let’s start by at least getting more specific with a definition.

Chat bubbles with Scalyr colors

Read More