Thursday, November 2, 2023

Fact-Gathering with Event-Driven Ansible for Microsoft Windows ITSM

The use of Event-Driven Ansible to enable fact gathering from events is considered a “Getting Started” type of use case, but it can be extremely powerful. This use case is simple and it is what we consider a “Read Only” type of action, meaning that we are not making any changes, but we are using the event to trigger a fact gathering process which we can later publish to the IT Service Management system. 

The benefit with this is we are able to provide consistent automated troubleshooting and fact gathering which is used to enrich the ticketing systems, so when our engineers have a look at the incident, they have all the information they need to decide on the next steps to resolve the issue or situation. This can potentially save many hours of toil and ultimately save an organization money from reduced down time and faster resolutions. But, we are assuming that our technical teams will know what to do with this event data.

What if we could assist with filling the gap when an incident takes place, and we could receive information or even options on how to resolve the issues? This is where we could use Event-Driven Ansible with the power of AI to enhance our team's approach to an incident. 

 

Event - Condition - Action! 

My environment is simple: I have a few Windows systems, an Event-Driven Ansible controller listening to events from these Windows systems and an automation controller. Windows has a verbose event logging system and this is beneficial for this type of use case. Working with Active Directory, a common task is to create and remove users or manage users in general. In my first example of fact gathering, I create a new user on the Active Directory and the event payload I receive in my Event-Driven Ansible controller looks like this: (Formatted Json)

The payload provides a wealth of information, and for a task like adding a user account to the Active Directory, this event-id can be used in a condition since I already know what the course of action should be when new users are added in my organization. I want to gather the information and post the account data into a ServiceNow ticket. 

The rulebook below references the specific event-id 4722 and triggers the appropriate job template to create a ServiceNow ticket with the account details. Now, remember what the payload looks like, any key could potentially be used as a condition, but the event-id is most accurate for this event with new user creation. 

--- - name: Events from Windows AD hosts: all sources: - ansible.eda.kafka: host: 192.168.89.155 port: 9092 topic: logs rules: - name: AD Account Change condition: event.body.winlog.event_id == "4722" action: run_job_template: organization: "Default" name: "AD Event Fact Gathering" 

We now have a ticket that gets created in ServiceNow when a new user is added to Active Directory. The ticket contains data from the event itself:

…output_omitted… short_description: "" Details:  Event-ID:  Event-Outcome:  “ tasks: - name: Send API request to ChatGPT uri: url: "" method: POST headers: Content-Type: application/json Authorization: Bearer  body_format: json body: model: "" prompt: "" max_tokens: 100 # Adjust the max_tokens as needed register: api_response 

Once I query ChatGPT with the specific event-id, I filter the response for the actual content I would like:

…output_omitted… - name: Extract text from API response set_fact: response_text: "" 

And then continue to create my ServiceNow ticket with the relevant information that I want to provide my technical team:

…output_omitted… - name: Create Enhanced incident Ticket servicenow.itsm.incident: instance: host: "" username: "" password: "" state: new short_description: "" description: |- Details:  AI Generated Description:  

My team can now login and look at the incident, which will provide them with details from the event log out of Windows but also an explanation from AI around that type of event and what that specific event-id actually means. If you wanted to, you could use another query and ask for the top 5 recommended solutions for the specific event.

This is a simple example of how we can not only use Event-Driven Ansible to fact gather and create tickets using the event payload, but it also shows us that using technologies like AI in conjunction with Event-Driven Ansible could be extremely beneficial by using event data to generate suggestions and descriptions of issues for our teams which might not have the experience or skills to resolve. 

To see these examples in action please click on the demo below!

 

Additional resources and next steps

Want to learn more about Event-Driven Ansible ? 



from Ansible Blog https://bit.ly/3MoIgfC
via IFTTT

No comments:

Post a Comment