Operations | Monitoring | ITSM | DevOps | Cloud

Log management software operates on the basis of receiving, storing, and analyzing different types of log format files. There are several of these standardized log formats that are most commonly generated by a wide assortment of different devices and systems. As such, it is important to understand how they operate and differ from one another so that you can use them the right way, as well as avoid some common mistakes.

It’s the start of a new year and the time is right to assess what we’ve accomplished and where we’re going. First, I think we should celebrate the incredible year LogDNA just completed. I’m so proud of what our LogDNA team accomplished. Not only because it’s quite impressive, which it is, but also because it lays the groundwork for what’s to come in 2020.

SRE and Security teams rely heavily on alerts to know whether their systems are experiencing issues and to prevent any future outages. At LogDNA, customers can set alerts that trigger when specific logs match (presence alerts) or set an alert to go off if there are expected lines that haven’t come through (absence alerts). These alerts can be set up with various channels so you can be alerted in the product of your choice (Slack, Email, PagerDuty, etc).

If you have or plan to collect data from Google Cloud Platform (GCP), you will have noticed that your option of ingesting data has been by using Splunk’s Google Cloud Platform Add-On. However, many customers are adopting “serverless” cloud services to deliver their cloud solutions. There are many reasons for this, but mainly it provides solutions that do not require any overheads of server or container management, that scale and is delivered as a part of their cloud platform.

Being a CIO is not easy these days. The industry is buzzing about data-driven business transformation, and every executive and manager wants to make data-driven decisions. For the CIO, finding the right solution – and getting the maximum benefit from it – can be overwhelming. Most customers have a minimum expectation, but beyond that it can be difficult to envision what’s possible. It’s hard to see what else data can make possible.

Yesterday, Jan. 14, 2020, on the first “patch tuesday” of the year, Microsoft released patches for critical vulnerabilities in Microsoft Windows client and server operating systems.

Working with Java applications has a lot of benefits. Especially when compared to languages like C/C++. In the majority of cases, you get interoperability between operating systems and various environments. You can move your applications from server to server, from operating system to operating system, without major effort or in rare cases with minor changes.

2020 is here and it looks like it’ll be a truly exciting and impactful year for the DevOps community. As you know, the landscape is changing rapidly, and as a result, new technologies and methodologies are emerging to solve challenges you’re experiencing on the job. Observability is one such concept–and achieving it is a huge challenge for software engineers across the globe.

Recently, our good friends at Amazon Web Services (AWS) launched an awesome new product, VPC Traffic Mirroring. Here at Splunk, we are excited about this new capability as it allows our Splunk Stream platform to ingest this data, and send it on to any Splunk instance, in the cloud or on premises. Leveraging this capability allows Splunk users to collect specific network data from their AWS environment, and use it to fulfill security, IT Ops, or business-focused use cases.

In this tutorial, we will talk about how different Java Garbage Collectors work and what you can expect from them. This will give us the necessary background to start tuning the garbage collection algorithm of your choice. Before going into Java Garbage Collection tuning we need to understand two things. First of all, how garbage collection works in theory and how it works in the system we are going to tune.