One question that customers often ask is “why does the LogDNA agent need to run as root?” With IT departments and DevSecOps teams pushing to secure systems against cyberattacks, running a cloud-based logging agent as root sounds like a huge risk. While it’s true that you should avoid running applications as root, there are several reasons why our agent runs as root out of the box and several ways that we reduce your risk of attack.

Now that you have your brand new Graylog instance up and collecting your organization’s logs, all the data is quickly searchable and available for troubleshooting any issues as they arise. Just as easy as it is for you to use, an attacker with access to the logs now has a much simpler job of understanding your environment and seeing all of your data. You need to make sure you are doing all the due diligence you can to protect the data.

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.

Sometimes developers are hesitant to include logging due to performance concerns, but is this justified? And how much does library choice affect performance? The team at SolarWinds® Loggly® and myself decided to find out. We ran a series of performance tests on some of the most popular Node.js libraries. These tests are designed to show how quickly each library processed logging and the impact on the overall application. Let’s see how they did!

Serverless architectures such as AWS Lambda have created new challenges in debugging code. Without a solid logging framework in place, you could waste hours, or even days, tracking down simple defects in your functions. A strategic logging framework can be a powerful way to track down and resolve bugs. Let’s walk through how to get the most out of logging Lambda functions.

On February 3, 2019, the Sumo Logic platform experienced its biggest ever spike in incoming data and analytics usage in the company’s history. On this day, close to everybody in the U.S., and many more people across the world, experienced a massive sports event: Super Bowl LIII. The spike was caused by viewers across the world tuning into the football game using online streaming video.

Logstash is the “L” in the ELK Stack — the world’s most popular log analysis platform and is responsible for aggregating data from different sources, processing it, and sending it down the pipeline, usually to be directly indexed in Elasticsearch. Logstash can pull from almost any data source using input plugins, apply a wide variety of data transformations and enhancements using filter plugins, and ship the data to a large number of destinations using output plugins.

Logs are unpredictable. Following a production incident, and precisely when you need them the most, logs can suddenly surge and overwhelm your logging infrastructure. To protect Logstash and Elasticsearch against such data bursts, users deploy buffering mechanisms to act as message brokers. Apache Kafka is the most common broker solution deployed together the ELK Stack.

If you have had any exposure to cloud computing or app development in recent years, you likely have heard the term “cloud native” thrown around. But you might be wondering what exactly that term means, and how it differs from concepts such as “cloud ready” or “cloud enabled.” As a cloud-native service provider, Sumo Logic understands the architecture underpinning this development model. Let’s take a closer look at the cloud-native concept and what it means.