Operations | Monitoring | ITSM | DevOps | Cloud

Amazon S3 is an object storage service widely used for storing many different types of data in the cloud. While it’s inexpensive and easy to set up and maintain S3 buckets, it’s also very easy to overlook S3 security aspects and expose them to malicious attacks. A typical example is accidentally allowing public access to S3 files. Several recent high-profile data breaches were caused by lax S3 security.

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.

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.