What if I told you that it took me just under 10 minutes, 8 commands and 6 mouse clicks to create this bar chart informing me — big surprise — that I have too many open tabs in Chrome on my Mac? That might sound like a lot to some readers, but if you’re not a stranger to ELK you’ll know that installing the stack, even for testing and development purposes, usually involves a whole lot more than that. ELK can be installed on almost any system and in any environment.

Cloud is driving the way modern software is being built and deployed. At the forefront of this revolution is AWS, holding a whopping 33% of the cloud services market in Q1 2019. Considering AWS had a seven-year head start before its main competitors, Microsoft and Google, this dominance is not surprising. AWS offers, by far, the widest array of fully evolved cloud services, helping engineers to develop, deploy and run applications at cloud scale.

It all started with monolith architecture; business logic, user interfaces, and data layers were stored in one big program. As tightly coupled applications, a simple update to the program meant recompiling the entire application and redistributing the program to all users. That led to the difficulty of maintaining consistent program versions and distribution across all clients in order to ensure stability and alignment. This made the monolith approach inefficient and cumbersome.

The ELK Stack is the world’s most popular open source log analytics and log management platform. Together, the four main components of the stack — Elasticsearch, Logstash, Kibana and Beats, provide users with a powerful tool for aggregating, storing and analyzing log data. In production environments, the ELK Stack requires an infrastructure flexible and powerful enough to power it.

Responsible for collecting various system and service metrics and forwarding them downstream to a backend storage system, the role metric collectors play in monitoring pipelines is crucial. Despite this fact, they often get left in the shadows cast by the beautiful frontend analysis tools like Kibana or Grafana. In the world of open source monitoring stacks, Metricbeat and Telegraf stand out as the most popular metric collectors. The truth is that they do much more than simply collect metrics.

One of the oldest (but often neglected) security vulnerabilities is SQL injection. One common scenario goes like this: An unsuspecting programmer writes an application that accepts input from the user which serves as a parameter to retrieve or store data from a database (e.g., a web login form). The programmer writes a dynamically populated SQL query inside the app, based on user input like username and password (see Image 1 for reference).

Monitoring an Azure environment can be a challenging task for even the most experienced and skilled team. Applications deployed on Azure are built on top of an architecture that is distributed and extremely dynamic. But all is not doom and gloom. Azure users have a variety of tools they can use to overcome the different challenges involved in monitoring their stack, helping them gain insight into the different components of their apps and troubleshoot issues when they occur.

Unlike traditional SQL databases, NoSQL databases, or “non-SQL” databases, do not store their data in tabular relations. Originally designed for modern web-scale databases, they have found widespread use in present-day big data and real-time web applications. Some of the most commonly used data structures include key-value, wide column, graph, and document stores.

Serverless first came onto the scene in 2014 when AWS Lambda was launched. It offers a dynamic cloud-computing execution model where the server is run by the cloud provider. As with any relatively recent technology, its novelty results in a steep learning curve, and it comes with its own set of benefits and drawbacks.

Last week I was at Monitorama and it was an amazing time! Not only where the talks fantastic, but I also had the opportunity to join Liz Fong-Jones from Honeycomb.io for a podcast with The New Stack to dig a little deeper into some of the topics in monitoring and site reliability engineering.

Pulling in data exposed via API is not one of the most common use cases for ELK Stack users but it is definitely one I’ve come across in the past. Developers wrapping their database services with REST API, for example, might be interested in analyzing this data for business intelligence purposes. Whatever the reason, the ELK Stack offers some easy ways to integrate with this API. One of these methods is the Logstash HTTP poller input plugin.

Kubernetes (K8s) is a prevalent open-source system for automating the deployment, scaling, and management of containerized applications. However, maintaining the service can be difficult and expensive. For that reason, it is easy to find platforms offering Kubernetes as a managed service. In this article, we will analyze three of the most popular services currently available: Google Kubernetes Engine, Azure Kubernetes Service, and Amazon Elastic Container Service for Kubernetes.

The ELK Stack, which traditionally consisted of three main components — Elasticsearch, Logstash and Kibana, has long departed from this composition and can now also be used in conjunction with a fourth element called “Beats” — a family of log shippers for different use cases. It is this departure that has led to the stack being renamed as the Elastic Stack.

As you may very well know, Kibana currently has almost 20 different visualization types to choose from. This gives you a wide array of options to slice and dice your logs and metrics, and yet there are some cases where you might want to go beyond what is provided in these different visualizations and develop your own kind of visualization.

Kibana is the visualization layer of the ELK Stack — the world’s most popular log analysis platform which is comprised of Elasticsearch, Logstash, and Kibana. This tutorial will guide you through some of the basic steps for getting started with Kibana — installing Kibana, defining your first index pattern, and running searches. Examples are provided throughout, as well as tips and best practices.

Distributed tracing has become a de-facto standard for monitoring distributed architectures, helping engineers to pinpoint errors and identify performance bottlenecks. Zipkin is one of the popular open source “tracers” available in the market, and I’m now happy to inform our users that we’ve recently introduced a new integration that allows users to easily ship trace data collected by Zipkin to Logz.io!