If you manage a network, every network device generates a large volume of logs. These logs are extremely important and narrate a story about both events and the sequencing of those events within your network. This capability is critical for any network monitoring software, helping you easily understand network activities, user actions, security breaches, and much more.
The waiting can be intensely stressful. You are mid-way through a critical production upgrade during the weekend. The schedule is tight. Suddenly there is an unexpected problem you aren’t able to resolve. You need help. So, you call in a support ticket. And that’s when the waiting starts. While you’re waiting for the support team to review and get back to you, questions race through your mind: How quickly will they respond to the ticket?
Cloud deployments have overtaken that of on-premises in the enterprise application software market since 2020, and Gartner expects they will be double the size of on-premises by 2025. These changes reflect the fast evolution in IT infrastructure due to new technology, business models, and market demands. The movement toward cloud, mobility, and IoT continues to surge forward.
In my prior blog, Continuous Test Data Management for Microservices, Part 1, we offered an introduction to the key approaches for applying continuous test data management (TDM) to microservices. The continuous TDM process for microservices applications is similar to that for general continuous TDM (see figure below), but tailored to the nuances of the architecture. In this post, I’ll outline the key steps for applying TDM across the lifecycle.
In my previous blog posts on test data management (TDM), I have discussed principles for continuous TDM and outlined how TDM for microservices-based applications differs from traditional applications. In this blog post, the first in a two-part series, I will combine both of these concepts to discuss key approaches for applying continuous TDM to microservices. In my second post, I’ll detail the key steps for applying continuous TDM in various phases of the delivery lifecycle.
For-Each is a new feature added to the DX Unified Infrastructure Management’s (DX UIM) Monitoring Configuration Service (MCS) that uses the device attributes with one or multiple values. MCS will loop through each value and create a profile for each one. If that attribute does not exist for a device, no profile will be created. Similarly, if a new value is added or removed from a device, MCS will revaluate and add or remove profiles.
Human operators utilizing traditional network monitoring software with methods like SNMP, ping, or flow tracking are still limited to diagnosis and triage issues within the four walls of the on-premise data center. But with increased adoption of cloud, SD-WAN and “work from anywhere,” application workloads are getting more distributed and creating network monitoring visibility gaps.
The increasing adoption of modern and cloud-native architectures is enabling enterprises with IT infrastructure that is more dynamic and ephemeral, and thus more resilient. This trend drives infrastructure monitoring tools to transition from simply “keeping the lights on” to providing advanced insights such as predictive analytics for infrastructure workload optimization. Infrastructure monitoring that was once art has become science.
Making IT operations simpler – which AIOps does by helping teams to make smarter, more informed decisions about complex monitoring and APM problems – is great. But what would be even greater is eliminating the need for IT teams to make decisions at all – a prospect known as NoOps. By automating application management to the point that human involvement is no longer necessary, NoOps offers tantalizing possibilities for the IT operations teams of the future.
To date, AIOps has been a solution first and foremost for IT operations teams. In other words, AIOps has been used primarily to help IT teams manage what happens in the post-deployment part of a CI/CD pipeline, when they need to detect and remediate issues in production environments. That doesn’t mean, however, that AIOps leaves developers out of the picture. Although the conversation surrounding AIOps hasn’t paid a lot of heed to developers so far, it’s perhaps time to change that.
