Automation has been a bit of a buzzword in the IT community in the last few years. Companies around the world are looking for ways to scale and automate routine tasks so they can focus on more strategic initiatives. But “automation” is a word that can cover a lot of workflows and can mean something different to every team.
What do we mean when we talk about automation here at LogicMonitor?
Generally, I like to divide LogicMonitor’s automation capabilities into a few different buckets: we use it for provisioning, workflow orchestration, and event-driven automation. In this blog, we’ll take a look at what tools we have available at LogicMonitor to support each category and where you can start introducing automation into your environment.
Resource provisioning with Hashicorp Terraform
The first step in any automation journey is automating infrastructure creation. Usually this is done by adopting a practice known as Infrastructure as Code (IaC). IaC has been around for years. It is a methodology that essentially creates something like a recipe for your infrastructure. IaC helps you set the definitions as a file for whatever you are trying to deploy, making it repeatable, version-able, and shareable. It establishes the file and avoids human error by creating infrastructure exactly the way you want it, when you want it. It is fast, low risk (because it can be peer reviewed), and allows teams to focus on other, more interesting tasks.
LogicMonitor has native support for two IaC tools out of the box: Redhat Ansible and Hashicorp Terraform. Both of these collections were initially created by our internal team for monitoring our own environment. But now it is, and will continue to be, an open source offering from LogicMonitor at no extra cost to our customers. These collections are now maintained, fully supported, and will continue to be updated by our teams. First, let’s discuss Hashicorp Terraform.
Hashicorp Terraform
LogicMonitor’s Terraform collection is intended to be used during resource provisioning. As folks use Terraform to create their infrastructure, we want to make it easy to add the new resources to LogicMonitor so they are monitored from the beginning. We wanted the experience to be repeatable. For example, if you are a MSP onboarding a new customer, why not use Terraform to replicate the onboarding experience for all of your customers? For enterprises, as teams grow and as your business scales, using Terraform will save you time and money and simplify your team’s ability to monitor resources in LogicMonitor.
Our Terraform Provider has a strong emphasis on resource and device provisioning, and we are constantly updating it. Last year, we added AWS account onboarding, and we recently started adding support for Azure cloud account onboarding.
Managing resources with Redhat Ansible
Now that the resources are provisioned, how are you going to manage them? Routine maintenance is a large part of our IT lives, from keeping things up to date at a scheduled maintenance pace, to troubleshooting on the fly to help diagnose common problems.
We use Ansible here at LogicMonitor for a lot of our workflow orchestration work. As maintenance or upgrades happen, why not communicate to your monitoring platform that work is being done? Schedule downtime with LogicMonitor as part of your Ansible playbook using our LogicMonitor Module. Maybe as part of your remediation playbooks you want to modify a collector group or get information from any of your monitored objects. That is all possible with our certified collection.
Onboarding new customers or setting up a new section of your LogicMonitor environment? We make all of that easy with our Ansible modules, allowing you to create alert rules, escalation chains, and device groups. If you use Ansible in your environment to deploy new infrastructure, our Ansible collection will also give you the opportunity to add these new devices to LogicMonitor for day-one monitoring.
We are always updating and enhancing these collections. If there is something that you would like to see added to these collections, please reach out and file a feedback ticket. We want to understand how you are using our collections today and how you want to use them in the future!
Event-driven automation with Stackstorm
This is the most exciting frontier of our automation journey here at LogicMonitor. This type of automation has a few names that you may have heard of: event-driven or alert-driven automation, “if this, then that” (IFTT) automation, or a self-healing enterprise. The fundamental idea behind this type of automation is that an automated action is taken based off of an event that has occurred. In the case of LogicMonitor, it would mean an alert is generated, triggering another action. The alert details are processed following a set of rules, and an automation is triggered to remediate the cause of the alert.
Imagine the following scenario: You have a windows server that is running out of disk space, and you’re getting alerts about an almost full disk. Traditionally, a tech would see the alert in LogicMonitor (or it would be routed via one of our integrations to a ticketing system), the tech would examine the alert and gather the appropriate information from LogicMonitor (what device is having the issue), VPN into the internal network, and open a remote session with the server. Maybe the tech has a playbook they call to clear common temp files, maybe it is a script, or maybe the tech has to manually do it. The tech finds the files and deletes them, logs out of the system, updating the ticket or worklog, and confirms the alert. In its entirety, this process, though a relatively simple task, takes significant time and resources.
Now imagine the above scenario happened at 1 A.M., routing to an on-call engineer, waking them up. Time is precious, so why not automate these simpler tasks and allow the tech to focus on things that they find interesting or challenging (or let them sleep as low effort, on-call alerts are resolved on their own)?
With event-driven automation, when simple alerts occur, an automation tool processes the alert payload and matches it against a set of rules and triggers that playbook to clear those temp files and resolve the alert.
Our primary offering into event-driven automation is with Stackstorm, an open source event-driven automation tool that is sponsored by the Linux Foundation. The Stackstorm Exchange allows a level of plug-and-play within your environment to not only receive or act within LogicMonitor but to take action in any other environments you may have. Stackstorm has a very robust engine and can handle any type of workflow, whether a simple task or a complicated upgrade plan.
Looking ahead with Event-Driven Ansible
Our Ansible and Terraform collections have a lot of overlap to support teams who may prefer one over the other (or teams that use both), and the same is true with event-driven automation. An exciting development in the market is the entrance of a new offering from Red Hat Ansible called Event-Driven Ansible.
The LogicMonitor team has been working with and experimenting with Event-Driven Ansible when it was released into developer preview late last year. As a Red Hat partner, we are working diligently on building a community source that will plug into Event-Driven Ansible to make it easier for our customers to start experimenting with it. To learn more about Event-Driven Ansible check out https://www.ansible.com/use-cases/event-driven-automation.
If you would like to learn more about our future work with Event-Driven Ansible or are interested in participating in a beta with us before release, please fill out a form to get started!