Alert Rules in Azure are a tool to let you know when some condition of your choice has occurred within any given component of your Azure infrastructure. In other words, they alert you to potential problems so you can remedy them before anything serious goes wrong.
Have you ever had the tedious task of creating multiple alerts for all of the resources in your subscription? Let me tell you, it is really time consuming to create them from scratch one by one.
I have a PowerShell Script that can Target and Create specific metric alerts for the resources you define inside of the script, making it much simpler to create a large amount of alerts at one time.
Skip down to the script if you’re familiar with Alerts already. If you aren’t here’s an overview on how they work.
One key concept to master when dealing with cloud, containerized, or otherwise software-defined infrastructure is Infrastructure as Code. This may seem strange at first. After all, your code runs on top of infrastructure, right?
Infrastructure as code (IaC) works in practice by managing your computing resources — virtual machines, storage, networking, and all the associated policies for security and such — in the same manner as you treat your code. This packages everything necessary for your application, from the code and assets to the underlying infrastructure itself, together into what works functionally as a single deployment.
Just as DevOps combined development and operations into one entity, IaC combines code and infrastructure as one.
Using a PowerShell validation during any of the Beekeeper Execution Job phases, you can write information to the Windows Application Log. This helps enable discovery for SCOM. The Event Log Validation Pack is a collection of PowerShell validations that you can customize in your environment.
Learn how to implement this, including downloadable Validation Pack and code snippets, in this blog post. For more information about Beekeeper patching automation software, view the product page.
Kubernetes has been kicking around since Google made it open source in 2014. Like many technologies it has taken some time to go mainstream, but with the rapid adoption of containers by many enterprise organizations, Kubernetes (or k8s) has become extremely popular as a method to manage, scale, and deploy containers across host platforms.
If you aren’t very familiar with Kubernetes, here’s why you might be interested in the platform and why it has proven essential to large scale containerized IT applications.
Many customers frequently ask the question whether or not it is possible to fetch a report of up-time of a service being monitored with SCOM. Usually, the answer is – not out of the box. However, you can achieve this using a simple workaround.
One way of doing it is to author your own service monitor, but that involves considerable amount of knowledge and experience of management packs and the underlying coding. It usually takes a lot of time as well. Not everyone has the right knowledge or the time to spend on this so I thought I’d share a quick trick I do to measure uptime of a service and also be able to present it to the concerned parties in the form of a report.