This time, I had a plan to add a feature of automatic copying the script to Linux machines when needed, regardless of manual works.
My intention were follows:
1) Check the existence the script.
2) If not, Copy the script to desired location.
3) After copy, It gives privilege to the script.
My intention was to checking if the file was existed. I thought I would make the rule for the first time, but I changed to make a monitor. It should be a monitor because this has feature to check something periodically. The second one was that I found that It enabled to transfer file via SFTP (SSH File Transfer Protocol). The first and third, they were able to invoke through WSMan. In addition, If file was already been there, the second and third were ignored.
Of course, I had to set some properties to achieve this goal throughout MP.
I used SCOM Authoring console.
First step, Make a data source for Monitor type
I made an user-defined data source: A scheduler and an Invoke were added to the data source named
CloudPortal.Linux.Monitoring.DataSource.ShellCommand.Monitoring. This will be going to be used to define a Monitor type.
Second step, Make a monitor Type
Create a monitor type. Go to Type Library -> Monitor Type -> New.Define Monitor state. In my case, I intended that I was mapping success ID to find the script, on the other hand, was mapping warning ID when it didn't find.
Define at least one more member modules. I defined three modules. First module, DS(Data source), was to invoke Linux command. And the rests are Condition Detections, Found was for when script file would be found and NotFound was for when file didn't find.
In terms of DS, this came from a type name CloudPortal.Linux.Monitoring.DataSource.ShellCommand.Monitoring.
Let's look at DS module closely, Linux command that I'd like to invoke is
ls /MGR/network_usage.py | wc -l
This returns 1 when it finds "network_usage.py" and 0 when it doesn't.
And then this capture is Find module, set 1 as its value which means the script file exists. The way to get the output of DS execution is through //*[local-name()="StdOut"]
On the contrary, the value set as 0 in NotFound module.
The next was mapping states to the modules. Previously, I defined two states (Success and Warning). Here, One or more specific modules have to belong to a specific state and the order.
In the case of Success, it included DS and Found, Found was followed by DS.
Third step, Make a unit monitor
Once the monitor type has successfully been made, It only remains to define unit monitor.
Go to Health monitor -> Monitors -> New.
It doesn't need to make a class in advance to create monitor ( There is example of creating a class for its monitor on the first reference site), just needed to define target.
I defined Microsoft.Linux.Computer as target and System.Health.AvailabilityState as parent monitor.
Then, clicked "Browser for a type" in Configuration tab and chose the monitor type that I defined earlier.
The last, defined recovery tasks in diagnostic and recovery tab.
I created three tasks when health status appear warning.
As knowing easily the meaning from their names, these are about making directory (/MGR), copying file and give privilege to the file.
After upload this MP to SCOM console, I removed folder for the purpose of test on a Linux Machine. The waning was produced well as the below picture and recovery tasks as well.
----------------------------------------------------------------
Changed the recovery setting, updated on 01 of June
Changed the recovery setting, updated on 01 of June
In addition to this, I created three recovery tasks at first as you can see the above picture, and got an issue to address. This monitor didn't guarantee the order of these tasks. In order words, I intended to start from MakeDir to FilePrevilege, but there were not started as this order.
So, I tried to create a Write action this time.
Go Type library-> Module types -> Write actions.
The advantage of using this, I was able to make them in good order: I can set next module.
When I added to recovery, It was appeared from the list.
This was the final version of my unit monitor. The different from the previous was that the number of tasks decreased to only one.
----------------------------------------------------------------
About File transfer, updated on 03 of June
This is information of my write action called SFTP.
Let's only focus on file transfer among three steps (Invoke, SFTP and Invoke2).
After you add a write action named Microsoft.Unix.SFTPTransfer.WriteAction, you need to fill its properties of Host, UserName, Password, SourceFile, TargetFile. The point is that the file is transfered from Windows to Linux via SFTP.
I think that values of Host, Username and password are the the same with the above image.
- Host: $Target/Property[Type="Unix!Microsoft.Unix.Computer"]/PrincipalName$
- UserName: $RunAs[Name="Unix!Microsoft.Unix.ActionAccount"]/UserName$
- Password: $RunAs[Name="Unix!Microsoft.Unix.ActionAccount"]/Password$
However, Sourcefile and Targetfile may be difference with your cases.
SourceFile should be a file located in SCOM management server.
In my case, I created a folder named LinuxScripts on C: drive on SCOM management server and then I located my file(network_usage.py) into the folder. And the last property, TargetFile is the linux directory which you want to copy to.
-----------------------------------------------------------------------------------------------------------
1. This is second to none site, this is good guide about authoring MP: http://operatingquadrant.com/2011/03/23/operations-manager-extending-unixlinux-monitoring-with-mp-authoring-part-i/
2. The contents of this site includes lots of XML tags, but it gives you analytical way of which part of your MP is wrong when the monitor doesn't work: http://technet.microsoft.com/en-us/library/dd789006.aspx
Dear Yeonki,
답글삭제Could you please post more info about the recovery? I don't know how to pass the script's filename to the recovery task.
Thanks in advance
Hi, Aguerrero.
답글삭제I hope this will help you.
I added file transfer to end of the post.
Thank you.
Great Yeonki! Thank you again for your fast reply.
답글삭제Dear Yeonki,
답글삭제The procedure described in your post works perfectly, but do you know if is possible to set as a parameter for the recovery task the source and target file names? I will explain with more details what I want to do: Using only one monitortype, I would like to create monitors that receive as input (config) the script file name to run. If the file is not found in the machine, a recovery task should be launched to copy the mentioned file name to the machine.
My problem is that I don't find the way to pass from the monitor output the file name to the recovery task.
Thanks again for your help.
Andrés
Hi, Andrés.
답글삭제Do you intend that you would create many monitors from one monitor type?
For example, Monitor 1 is monitoring "xxx" script and Monitor 2 is monitoring "yyy" script. Those monitors come from the same monitor type.
If I am right, it is able to make one monitor type and then can create many monitors from the monitor type by using Configuration in SCOM authoring console. Source/target files path must determined when you create a Monitor.
I posted new blog about this matter based on this assumption. Please refer to my latest blog.
Thank you.