Chris Steffen is a research director for information security at Enterprise Management Associates. EMA is a leading analyst and consulting firm that prides itself on going beyond the surface to provide deep insights about the IT industry. I'm Liesse from LogDNA. Before we dive in, I just wanted to take a moment to thank all of you for tuning in to season one of DevOps State of Mind.

Legacy logging solutions simply couldn’t keep up with the complex, hyperconverged regional infrastructure at Civo, a Kubernetes service provider that enables users to launch k8s clusters within 90 seconds. “With our infrastructure and application deployment getting more complex and more distributed, we needed our logging solution and our entire observability stack to scale up with our needs,” said Anaïs Urlichs, Site Reliability Engineer at Civo.

As organisations face outages and various security threats, monitoring an entire application platform is critical in order to determine the source of the threat or the location of the outage, as well as to verify events, logs, and traces in order to understand system behaviour at the time and take proactive and corrective actions.

LogDNA is always looking forward and constantly developing new and innovative solutions to the problems developers and enterprises face as they manage their logs and data. Here’s a recap of our latest product releases and info on how you can get your hands on them.

Compute functions that run on Amazon’s Elastic Container Service (ECS) require regular monitoring to ensure proper running and managing of containerized functions on AWS – in short, ECS monitoring is a must. ECS can manage containers with either EC2 or Fargate compute functions. While EC2 and Fargate are compute services, EC2 allows users to configure virtually every functional aspect. Fargate is more limited in its available settings but is simpler to set up.

You have probably heard of Log4Shell, the security vulnerability that has ‘earned’ itself an NIST rank of 10: In this post I will show a really basic example of how this vulnerability actually works. I will walk you through some basic usage of the Log4J library and then show how some fairly basic inputs into this library can cause truly unexpected, and potentially disastrous, outcomes.

Amazon Elastic Compute Cloud (a.k.a., EC2), is no doubt the core current computing infrastructure. It sits at the heart of AWS, the main kind of structure for housing virtual machines and containers for development and operations. Applying standards of observability with EC2 logs and obviously EC2 metrics (or any kind of AWS metrics for that matter) will inform you on if you have the right sorts of instances in place (and the appropriate size of those instances).

This year, we were excited to deliver the easiest version of Grafana Loki to use yet. With Loki 2.4, the Loki team introduced a simple, scalable deployment, and over the past 12 months, we added lots of great new features. Not to mention, we launched Grafana Enterprise Logs, a new addition to the Grafana Enterprise Stack that’s powered by Loki. But none of this would have been possible without our active community: In 2021, Loki had 166 contributors and 823 PRs in GItHub.

The Log4J library is one of the most widely-used logging libraries for Java code. On the 24th of November 2021, Alibaba’s Cloud Security Team found a vulnerability in the Log4J, also known as log4shell, framework that provides attackers with a simple way to run arbitrary code on any machine that uses a vulnerable version of the Log4J. This vulnerability was publicly disclosed on the 9th of December 2021.

Life is all about perspective, and the way we look at things often defines us as individuals, professionals, business entities, and products. How you understand the world is influenced by many details, or in the case of your application – many data sources. At Coralogix, we not only preach comprehensive data analysis but strive to enable it by continuously adding new ways to collect data.