Why should you care?

If you’re someone like me who spends most of their day working on the command line interface (CLI) rather than the graphical user interface (GUI), you understand how easy it can be to overlook the root cause of an incident because you missed an error, a warning, and even important IP addresses, particularly when scrolling through debugging logs, syslog messages, interface lists, routing tables, and so forth. I found myself in that type of situation so often, especially during troubleshooting calls, that I realized I needed to take action. This led me to the customization of iTerm2.

Why iTerm2 ?

Do not mistake the pointing finger for the moon.

— Wei Wu Wei

I imagine many wondering why iTerm2 and why not something else? However, that’s not the focus here, as most (if not all) of what we’ll showcase can also be achieved with other terminals. Additionally, being a fan of Mac, I personally believe iTerm2 is the best terminal available. The objective isn’t to provide an introduction to iTerm2 or guide on its installation (plenty of resources are available online for that). Rather, the aim is to delve into methods for reducing the chances of overlooking important details while working on the command line interface of various systems, particularly network systems.

It is all about Triggers!

Simply put, a trigger is a response to an action. In iTerm2, triggers are actions programmed into the terminal using ICU regular expressions to catch well defined text pattern and react on them following a certain number of prescribed behaviors.

Where do I find the Triggers?

1- Start iTerm2 application,
2- Open Settings (⌘+,)
3- Go to Profiles
4- Choose the profile you want to customize (In this case it is the default profile).
5- Click on the Advanced advanced tab.
6- Then Click on Edit button in Triggers section.

The objective here is to achieve a triggers window resembling the one depicted in the screenshot below. This will be the focus of the next section of this document, where we’ll elaborate on the process.

Color System

I consider the primary challenge to be devising a color system. In this regard, having too many colors can be just as problematic for engineers as having none at all. They tend to divert attention rather than focusing it on crucial details that should not be overlooked. Simply put, using fewer colors yields better results.
My design of the color system is inspired by Cisco message logging architecture and is depicted in the capture below:

Filtering syslog messages

(?i:,*(EMERGENCY|ALERT|CRITICAL).*)
(?i:,*(ERROR|FATAL|FAILED|FAIL|INCOMPLETE|disabled|suspnd).*)
(?i:,*(warning|warn|notconnec).*) 
(?i:,*(notification).*)

 

Filtering IP Addresses

IPv4 addresses

(?i:,*([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3}))

IPv6 addresses

(?i:,*(\b[0-9a-fA-F]{4}:.*[0-9a-fA-F](?!:)\b).*)
(?i:,*(::[0-9a-fA-F].*[0-9a-fA-F](?!:)\b).*)
(?i:,*([0-9a-fA-F]{4}::(?![0-9a-fA-F]).*)    

Filtering Mac Addresses

([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2})
([0-9A-Fa-f]{4}[.-]){2}([0-9A-Fa-f]{4})

Detect a possible incident in the ARP table

(?i:,*(ERROR|FATAL|FAILED|FAIL|INCOMPLETE|disabled|suspnd).*)

Tips

Regarding iTerm2, it offers the flexibility of creating multiple profiles based on the nature of tasks or devices you’re dealing with. For instance:

• A profile tailored for servers (Linux).
• Another for networking tasks involving Cisco, Juniper, or Arista devices.
• And yet another for automation purposes, involving Python, Ansible, and GIT.

The objective here is to maintain a neat Triggers customization table and refrain from overusing colors.

Conclusion

Diagnosing issues can be a laborious endeavor, yet with the aid of finely-tuned tools, it can become less arduous and occasionally even enjoyable. This document serves as a portal into the potentials inherent in the terminals we routinely employ. When optimized, they can empower us to accomplish more. Personally, I prefer to implement two types of customizations: those for the long term and those for the short term. Long-term customizations are seldom altered and are applicable across various vendors, whereas short-term customizations are tailored to individual devices or specific scenarios, such as a troubleshooting session.