Write up the Icinga section in the workshop guide

[mrmrcoleman]

Hey @davekempe here's the first bit where we'd like to look at Icinga to get them used to it: https://github.com/mrmrcoleman/autocon2_workshop/blob/5ff71a3ca625ced8e89a3ad2f9e8cdad87b3d818/README.md?plain=1#L149

We still need to discuss the monitoring use case. Currently I'm assuming we can detect a lack of traffic between the ethernet1/1 interfaces on each device, but I might need to revisit that as I'm still an Icinga noob.

Here's the other part I had in mind: https://github.com/mrmrcoleman/autocon2_workshop/blob/5ff71a3ca625ced8e89a3ad2f9e8cdad87b3d818/README.md?plain=1#L212

[sol1-matt]

from a monitoring standpoint @mrmrcoleman my go to line is

"If you can run a command and get the result you want we can turn that into a check"

In all likelihood we won't need to do that and will be able to use built in checks like ping.

But I'd be very interested in where we get interface status or interface bandwidth from, we may need to build checks for those which isn't hard if we know what commands/api calls can be made to get the data.

[sol1-matt]

I can see a bunch of commands in that read me

I'm going to make some assumptions here layout what I think will be needed to make a monitoring check for the demo

• we can't install the icinga agent and even if we can't we probably don't want to
• we can probably setup ssh keys
• setup ssh keys so the icinga user can login to the devices
• setup by ssh based check that contains ssh admin@<host> show interface
• parse the results
• setup check command in icinga
• setup service apply rule in icinga
• setup automation for importing data
• add host to netbox
• update host in netbox with interfaces that match the data from show interface (slurpit?)

and here is where we get a working check

[sol1-matt]

~worth noting here if slurpit can't give us the interfaces we can whip something up that parses that data into Netbox quickly~

~If this happens that opens up the possibility that you can use Icinga to run a discovery and update job, as opposed to something else scheduling it like cron.~

~A couple of advantages to this for the demo~ ~- One of Icinga's strengths is it is distributed. As long as it can see back to Netbox (get out), it can scan closed networks (that Netbox or SlurpIT) can't get into~ ~- The discover and update job can return a success failure result that is now tied into the monitoring so it can be put on a dashboard, trigger notifications, be run on demand from a gui, etc....~

I saw the other ticket, #2, SlurpIT can get the data ok

[mrmrcoleman]

Hey @sol1-matt thanks for this! Slurpit is already pulling the interface data into NetBox, but not constantly yet.

To avoid overlap I thought perhaps we could deploy a demo app in the lab that requires the connectivity between the two devices and monitor that instead.

It would probably be best to jump on a call and whiteboard this a bit.