Today, it’s perfectly normal for businesses to continuously monitor software applications and IT infrastructure to ensure uninterrupted customer service. Active and passive monitoring are the two popular methods enterprises use for infrastructure and application performance monitoring (APM). As the names indicate, these two approaches to monitoring are very different.

The Splunk Add-on for OpenTelemetry Collector is a variation of the Splunk Distribution of the OpenTelemetry Collector that simplifies metrics and traces data collection, configuration and management. Since it is an add-on, users can deploy it alongside Universal Forwarders using tools like Deployment Server to start collecting high-fidelity metrics and traces from 1000s of their hosts easily. We’re happy to announce that the Add-On is now generally available in Splunkbase.

Technical teams use various metrics and indicators to track performance and success. For DevOps teams, among the most important metrics is deployment frequency. Deployment frequency can help you evaluate the software delivery performance of teams that develop software and apps. In this article, I’ll look at using this metric to calculate deployment rate, the importance and best practices for improving your deployment rate and setting your DevOps team up for success.

IT infrastructure must meet enterprise needs for effective service delivery while also providing value for money. This is a critical undertaking. Massive data growth, increased complexity of hybrid cloud environments, and emphasis on digital-first strategies are just some of the challenges. This requires an advanced approach to how infrastructure is configured and controlled — infrastructure management.

Perhaps the most defining trends of the 2020s so far have been abrupt change and mixed signals. IT spending is no different. A mere 3 years ago, COVID-19 swept the globe and thought leaders were calling for the start of a “new normal” and predicted that life on Earth would never be the same – and a major component of that change would be a move to remote-first and digital-everything.

How many software pipelines are required to keep your business running? How many of those build, test, release, or deploy code? The most likely answer here is “I don’t know…” followed by a set of mental gymnastics to try and determine a rough number that is most likely incorrect.

Getting to the root cause of a problem in cloud-native environments requires engineers to navigate through immense complexity within a distributed system. Oftentimes, you didn’t write the code and you lack the background and context to quickly understand what’s going on when a problem occurs. The stakes are even higher when a problem is reported - meaning it’s already started to impact the business and the executives and your customers are not pleased.

Simply defined, multicloud (or multi-cloud) describes a computing environment that relies on multiple SaaS or cloud services for different workloads within a single architecture. In a multicloud approach, organizations may use public cloud providers such as Amazon Web Services (AWS) for infrastructure, Microsoft Azure for platform, and Google Cloud Platform for development.

The Internet of Medical Things (IoMT), a subset of Internet of Things (IoT) technologies, comprises inter-networked devices and applications used in medical and healthcare information technology applications. IoMT devices connect patients, doctors and medical devices — including hospital equipment, diagnostic gear, and wearable technology — by transmitting information over a secure network.

When all your IT systems, your apps and software, and your people are spread out, you need a way to see what’s happening in all these minute and separate interactions. That’s exactly what distributed tracing does. Distributed tracing is a way to tracking requests in applications and how those requests move from users and frontend devices through to backend services and databases.