When migrating to Kubernetes and re-architecting your applications into containers, logging is a critical piece to consider. The twelve-factor app methodology has a section dedicated to logging and outlines the importance of not worrying about routing and storage of your logs. As a best practice, applications running in containers should rely 100% on standard output (STDOUT). Unfortunately, getting logs from applications that do not write to STDOUT is non-trivial and has many things to consider.

Link analysis, which is a data analysis approach used to discover relationships and connections between data elements and entities, has many use cases including cybersecurity, fraud analytics, crime investigations, and finance. In my last post, "Advanced Link Analysis: Part 1 - Solving the Challenge of Information Density," I covered how advanced link analysis can be used to solve the challenge of information density.

Nowadays, most applications we build are composed of microservices and distributed in nature. In such a setup, communication between these microservices is crucial, but can, unfortunately, cause some headaches. The first thing I check when I’m troubleshooting a bug in production is inter-service communication. Having a reliable tool at your disposal to take care of this can reduce a lot of stress. RabbitMQ, a hybrid messaging broker, is one such tool.

Today, we’ll cover some of the ways you might find quite useful in your everyday work. We’ll go through some of the logging best practices in AWS Lambda, and we will explain how and why these ways will simplify your AWS Lambda logging. For more information about similar topics, be sure to visit our blog. Let’s start with the basics (and if you have the basics covered, feel free to skip ahead): How does logging work with AWS Lambda?

With more people working from home, the threat landscape continues to change. Things change daily, and cybersecurity staff needs to change with them to protect information. Threat hunting techniques for an evolving landscape need to tie risk together with log data. Within your environment, there are a few things that you can do to prepare for effective threat hunting. Although none of these is a silver bullet, they can get you better prepared to investigate an alert.

In my first post in the Kubernetes Logging Simplified blog series, I touched on some of the ‘need to know’ concepts and architectures to effectively manage your application logs in Kubernetes – providing steps on how to implement a Cluster-level logging solution to debug and analyze your application workloads. In my second post, I’m going to touch on another signal to keep an eye on: Kubernetes events.

The cold season is hopefully coming to an end, and Spring is here! And just like the changes in the seasons, we have a new SDK release, updated developer docs, and other signs of new growth! It’s a great time to update your apps using the latest SDKs for the latest Splunk Cloud and Splunk Enterprise releases. Plant your session proposal in the .conf21 Call For Speakers! It's also time to prune away some older jQuery and Python versions support. Read on for the latest news.

For our first specialist interview on the Logit.io blog, we’ve welcomed Scott Steinburg to share his thoughts on the current state of cybersecurity as well as the reasons behind writing his new book Cybersecurity: The Expert Guide. Scott is the creator of the popular Business Expert’s Guidebook series, host of video show Business Expert: Small Business Hints, Tips and Advice and CEO of high-tech consulting firm TechSavvy Global.

If your business is among the more than one million organizations that use Amazon Web Services (AWS) to host applications and data, there is a good chance that you struggle to monitor AWS. After all, although AWS makes it easy to deploy cloud services, collecting and analyzing data about those services in an efficient, centralized way can be a real challenge.