The simplest informer on Automator

In my first post on this resource, I would like to describe the simplest example of creating an informer, with the help of the tremendously convenient utility Automator bundled with Mac Os X.

Just the other day, with a radical decrease in the street temperature in Moscow, I suddenly had a task: to visually monitor the temperature in the server room (or rather, in the rack), at a certain interval, since the room air conditioner refused to operate at T <-15 ºC.
')

To begin with, I will immediately explain that the very matter of controlling the temperature of the server room, the rack, each server in it, and also a couple of hundred other parameters I have fully resolved by installing the Zabbix monitoring system. And I must say, she copes with it perfectly, not only carefully collecting all this data and storing the logs of all changes in these parameters, but also performing informing in case of reaching control or critical points (triggers). However, not always, receiving e-mail messages or SMS is convenient, especially of the same type, as in my case, containing a specific value that varies slightly with time - in this case, the room temperature. And so I decided to visualize this information for myself, since the process takes 5 minutes and a dozen clicks, and as a result we get conveniently appearing notifications with the necessary parameter, and the interval of their appearance is configured, and the history is conveniently stored in the Mac Os X notification center message lists .

As a source of information, I chose the Ambient Sensor of one of the rack servers. This is a Supermicro IPMI server.
To begin, open the program interface:

We select the creation of a new process, and then, in the “Actions” section of the library, select the utility subsection - in fact, we will use only them.

Actually, the program interface is quite simple, on the left we have a library of actions or variables that we can use when creating step-by-step processes, and on the right a field of forming the process body, into which we drag and drop actions and variables from the library in the chronological order in which they should take place within the framework of the process being formed.

So, the main request, as I indicated earlier, will return to us the temperature of one of the sensors in the server in the rack. The command that returns it in my case is as follows:

ipmitool -H xxx.xxx.xxx.xxx -U LOGIN -P PASSOWRD sensor get 'Sensor Name' |grep 'Sensor Reading' |grep -o '[0-9][0-9]'

where xxx.xxx.xxx.xxx is the IPMI interface IP address
LOGIN and PASSWORD are the login and password for access to the interface.
Sensor Name is the name of the sensor from which data is supposed to be read. In my case, it was System Temp.
The grep utility in this context is used to return a readable two-digit digital temperature value of the sensor.

To make a process execute this command in the shell, drag the corresponding action from the library to the process field:



Note - in the upper right corner there is a flag that allows you to either put the result of the script execution into stdin, or return it as an argument for further actions. Since we plan to use the result in the future - then we choose to return "as an argument."
And since we want to use the obtained value in other operations, it makes sense to create a variable, to which the value obtained above will be assigned, for this we select the action “Set variable value”:


Clicking on the “new variable” field you can give it a conveniently readable name, for example, “Temperature”. Notice also that between the two actions there are arrows indicating the direction of the sequence of actions.



Well, then it's quite simple, now we need to display a notification in the notification panel with the value of the new variable. We drag the corresponding action from the library, and we drag and drop our variable from the bottom pane with a list of certain variables to the places necessary for substitution.

Also, for convenience, I recommend adding additional variables from the library, I took the exact time from there. In general, there is a lot of things ...
The tab of the library of system variables is located to the right of the “Actions” tab:


Well, then it remains to fill out the message body itself.

In addition, we have a task to loop this process, so that the request is carried out with a certain interval. To do this, from the action library, it makes sense to drag the “pause” action, in which you can specify the time of the process suspension. I note (and this is important) that I initially tried to set 1800 seconds instead of 30 minutes, but the process worked incorrectly, in fact, therefore, in action, you can set the delay dimension in seconds, minutes or hours. As I understand the manual, the counter is limited to 1000 units.

And finally, the action we need is a cycle, because we need to loop the process. To do this, we put the “Loop” action at the end of the process.
In this action there are several configurable parameters, namely: a mandatory user request to continue the action, which can be replaced with a fully automatic cycle (we actually need it). The second parameter is the loop return point, we need to return to the very beginning of the process, therefore we select “Use initial input”. Well, the third, rather important parameter - “stop after”. This parameter determines when the loop action ends. There are two options here, either after a certain time interval, or after a certain number of cycles. Unfortunately, it is impossible to make an infinite loop, setting this parameter to “zero” for both minutes and “one” does not lead to this (the cycle will be executed only once), so it’s easier to choose what you like. The maximum value of the counter is also 1000 units. For myself, I personally chose 1000 times, this is 1000 cycles. I note that if this is not enough, put the next loop immediately after the first one, this will execute the loop in a loop, and this is 1 million iterations, etc.

As a result, the final version of the process looks like this:



And the issued messages, first of all, are conveniently visualized on the desktop - jumping out with the necessary frequency, while you can always see their history, which looks like this:


Now it only remains to start the process. And it will start being executed by an automator, and so that it does not interfere in the Dock - right-click on the Automator icon in the Dock and then Hide.

The main task of this post is to tell you that using such a wonderful tool as Automator you can automate not only very complex tasks that require repeated repetition of routine actions, but also perform periodic tasks with fairly convenient visualization of query data.