If you ever watched Stargate, then you have some understanding of how application programming interfaces (APIs) work. While APIs don’t give you the ability to traverse the galaxy using an alien wormhole, they do act as digital portals that allow data to travel between applications. However, as sensitive data moves from one application to another, each API becomes a potential access point that threat actors can exploit.

So you have been adding more and more logs to your Graylog instance, gathering up your server, network, application logs, and throwing in anything else you can think of. This is exactly what Graylog is designed for, to collect all the logs and have them ready for you to search through in one place. Unfortunately, during your administration of Graylog, you go to the System -> Overview screen and see the big bad red box, saying you are having indexing failures.

Hey there, data detectives and server sleuths! Ever find yourself staring at a screen full of numbers and graphs, only to have one data point wave at you like a tourist lost in Times Square? Yup, you’ve stumbled upon the cheeky world of Anomaly Detection—where data points act more mysterious than your cat when it suddenly decides to sprint around the house at 2 AM. So buckle up!

When Dolly Parton sang about “Workin’ 9-5”, she almost seemed to understand the very specific pain of sitting at an IT help desk and getting one last call at 4:59 in the afternoon. When you pick up that last call of the day, the last thing you want is to begin a long, arduous investigation.

If you’re new to logging, you might be tempted to collect all the data you possibly can. More information means more insights; at least, those NBC “the more you know” public services announcements told you it would help. Unfortunately, you can create new problems if you do too much logging. To streamline your log collection, you can apply some filtering of messages directly from the log source. However, to parse the data, you may need to use a Grok pattern.

One of the most important events you should be monitoring on your network is failed and successful logon events. What comes to most people’s minds when they think of authentication auditing is OS level login events, but you should be logging all authentication events regardless of application or platform. Not only should we monitor these events across our network, but we should also normalize this data so that we can correlate events between these platforms.

If you work with large amounts of log data, you know how challenging it can be to analyze that data and extract meaningful insights. One way to make log analysis easier is to normalize your log messages. In this post, we’ll explain why log message normalization is important and how to do it in Graylog.

Picture a simple E-commerce platform with the following components, each generating logs and metrics. Imagine now the on-call Engineer responsible for this platform, feet up on a Sunday morning watching The Lord of The Rings with a coffee, when suddenly the on-call phone starts to ring! Oh no! It’s a customer phoning, and they report that sometimes, maybe a tenth of the time, the web front end is returning a generic error as they try to complete a workflow.

As the affordable choice for cloud computing, Google Cloud Platform (GCP) is catching up to its competitors, like AWS and Microsoft Azure. As a business, you need the speed and scalability that the cloud provides, but you want to limit your costs to ensure you hit revenue targets. With GCP, you found a digital services business partner to help you meet your business objectives, a technology that gives you the service availability you want at the speed you need.

We are excited to announce the release of Graylog 5.1! A follow-up to our 5.0 release, Graylog 5.1 brings updates across our entire product line, including changes to infrastructure, Security, Operations, and our Open offerings.