Operations | Monitoring | ITSM | DevOps | Cloud

Kubernetes is the de facto industry standard for container management and orchestration. Not surprisingly, it has also become common to use Kubernetes in tandem with compatible Continuous Integration (CI) and Continuous Deployment (CD) tools. As a container orchestrator, Kubernetes expects deployments to spin up software throughout a cluster. Those deployments are created using files or command lines that can be generated manually or using properly configured CI/CD software.

Over the past few years, and coupled with the growing adoption of microservices, distributed tracing has emerged as one of the most commonly used monitoring and troubleshooting methodologies. New tracing tools and frameworks are increasingly being introduced, driving adoption even further. One of these tools is Jaeger, a popular open source tracing tool. This article explores the integration of Jaeger with the ELK Stack for analysis and visualization of traces.

Apache Tomcat is the most popular application server for serving Java applications. Widely-used, mature and well documented, Tomcat can probably be defined as the de-facto industry standard. Some sources put Tomcat’s market share at over 60%! Tomcat is particularly popular for serving smaller applications since it doesn’t require the full Java EE platform. It consumes a relatively small amount of resources and provides users with simpler admin features.

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).