[Hinemos Job Feature] Introduction to the command jobs

Hello!
In this article, we will shed light on the Job Feature of Hinemos. In particular, the command job.

We will explain the steps from creating a command job to executing it along with specific examples.
These steps are intended for users who are not familiar with Hinemos and will not include descriptions about detailed settings.
If you are already a Hinemos user familiar with most settings, please read through this article just for simple reference.

 

First, let me explain briefly about the Job Feature.
Hinemos’ Job Feature executes any command, via Hinemos Agent, on a machine registered as a node.
You can automate the execution of the commands by configuring calendar setting(s) to each job.

In Hinemos, a job consists of the following three elements;
・Job unit (framework of a job)
・JobNet (collection of command jobs)
・Command job (the element which executes a command)

The structure of a job is shown in the figure below.

JobNets and command jobs are contained in a framework called a job unit.
Basically, the whole process flows as each command jobs are executed.
You can also configure which job will be executed next depending on the result of the preceding command job (or JobNet).

Before getting started, register the node where you will execute a command in the repository and start Hinemos Agent.

Now, let’s create a job.
First of all, open the Job Setting perspective.
Select Manager on the Job Setting [List] view, and click on the job unit creation icon (the one in a red circle below).

This time, enter only the job ID and job name and click on the OK button to simplify the setting.

This will create a job unit.
Next, select the job unit you created, and click on the command job creation icon (the one in a red circle below).

Open the Command tab, and enter the job ID, job name, scope and start command.
Select “Fixed Value” and click on the “Refer” button to select the node where you wish to execute a command.
Enter the command you wish to execute in the “Start Command” field.

This time, we entered the command which outputs dates to “date_confirm.txt”.

*Place “date_confirm.txt” under “/temp/” in advance.

tmp配下

Click on the “OK” button to create a command job.
Click on the registration icon (the one in a red circle below) to register the job unit.

This will enable execution of “CMD_JOB01”.
Now, let’s try executing it.
Select the “CMD_JOB01” command you created, and click on the execution icon (the one in a red circle below).

Open the Job History perspective to check if the command was executed properly in the Job History [List] view.

Just to make sure, check the contents of “date_confirm.txt” on the machine where the command was executed.

date_confirm確認

You can see the same date and time as job end/pause were output and thus the command job was executed as expected.

Next, let’s try executing a shell script using a command job.
Select the job unit you registered earlier, and click on the edit mode icon (the one in a red circle below).

Click on the command job creation button, enter the job ID and job name as you did earlier, and open the Command tab.
*The respective job IDs of command jobs used within a job unit must be unique. Therefore, the job ID here must be different from the one for the command job you created earlier.
Select the same node that you selected earlier in the Scope field, and enter “/temp/archive_messages.sh” in the Start Command field.

Select the End Status tab (see the figure in the upper right) to check the end status.
There is no problem if the end status is set to become “Normal” when the end value 0 is returned, and “Warning” when the end value 1 is returned.
Follow the same steps that you performed earlier to register.
The script we will execute this time is as follows.

*Place “archive_messages.sh” under “/temp/” in advance.

tmp配下_archive

The script creates an archive of the rotated messages under “/var/log/” into “/root/backup/” and deletes the original files.
It ends after returning the end value 1 if there is no rotated file.

Now, let’s execute the command job.
Check the messages under “/var/log/” before executing the command job for comparison.

varlog配下確認

Follow the same steps that you performed earlier to execute “CMD_JOB02” and check the job history.

You can see the command job was executed properly.
Now, let’s check the messages under “/root/backup/”.

archive_messages確認

You can see an archive has been created and the date and time displayed are the same as those of job end/pause.
Next, let’s check the messages under “/var/log/”.

archive_messages確認2

If comparing them to the messages checked before executing the job, you can see the rotated messages disappeared, and thus the script was executed properly.
Now, let’s execute the command job to execute the script again.
If you check the job history, you can see the end status is Warning this time.

This is because the rotated messages were deleted during the first “CMD_JOB02” execution, and Hinemos returned the end value 1 judging there was no rotated file during the second “CMD_JOB02” execution.
As just described above, you can instantly judge whether an archive has been created or not based on the end status if setting the end status to vary depending on the end value.

We introduced you part of the command job feature today.
Hinemos provides several other setting items for command jobs. You can automate various operations by combining command jobs with schedules.
For example, modify the script we used today a little bit so that an archive of all the rotated messages will be created.
If you create and apply a schedule based on which the modified script will be executed on the first day of every month, Hinemos will compress the rotated files once a month. This will help prevent the data size from getting bloated.

That’s it for the brief introduction of command jobs.
If we get a chance, we will introduce you an example of automation using Job Feature next time.

Thank you for reading.