Page History
...
The first thing you'll likely notice here is that the Monitor has set it's Status to OK , which is the default state for a service monitor that's run successfully, as long as none of it's threshold comparisons are triggered. The 'message' line shows use that the process returned a valid status , which is then followed by the output from the plugin monitor. ie. 'custom1 uptime_core is stopped MON Role'.
You may wonder where the 'custom1' string is coming from as it's not in the example output of the agent side script above. This is inserted by the rcs.php and used to mark that the output from the agent script should link up with the 'custom1' variable from the XML. Which you can see on the next line 'Output' where 'custom1' has been replaced with that variable's Short-Description also form the xml. The next line is an example of Uptime Infrastructure Monitor attempting parse the second line of output from our agent script into a variable called 'MON' but because this isn't defined in our xml file, it won't be available for comparisons within the GUI. The final line here is the Response time value, which is special timer mentioned above.
...
The best way to understand how Uptime Infrastructure Monitor plugins are packaged is to take a look at the zip file for a plugin itself. We'll use the same 'C ustom Custom Remote Monitor' from above as our example again. The actual zip file that is used when installing the plugin is located within this repo's 'dist' folder, along with some .upk files (The legacy plugin format used by older versions of Uptime Infrastructure Monitor).
You can easily download the 'monitor-custom-remote.zip' yourself, and look at the contents directly, but the contents of that archive are just a zipped up version of the repo's 'pkg' directory, which you can easily view in on GitHub 's web interface here.
The contents of the zip/pkg folder are made up of the xml file that we've already discussed in detail above, and a mix of one or more 'files' folders. These folders contain the actual scripts that will be extracted into place on the Uptime Infrastructure Monitor monitoring station. The reason for the files-win & files- posix folders are that plugins may require different files or scripts depending which OS (ie. Windows or Linux) the Uptime Infrastructure Monitor monitoring station is running. As such the contents of the 'files-win' folder will only be extracted on Windows monitoring station, and the 'files-posix' folder will only be extracted on a Linux monitoring station.
Info |
---|
As mentioned before, most of the plugins created by Uptime Infrastructure Monitor are intended for cross platform use. This is why is most of them they have all three of these 'files' folders. When creating your own plugin monitor, you can focus just on the OS platform of your Uptime Infrastructure Monitor monitoring station, and simplify the packaging of your plugin by placing all the scripts within the 'files' folder. |
The mechanism for how these 3 folders are extracted during the plugin's installation are the same general process whether the monitoring station is running Windows or Linux. Which is that each of the 'files' folders will be extracted into the directory where Uptime Infrastructure Monitor is installed on the monitoring station. Any sub-folders within the plguin's 'files' folders will be created along the way if they don't already exist. Though in most cases, you'll want to place all your plugin's scripts/files within it's own sub-folder in uptime_dir/plugins/scripts/ .
Info |
---|
Another thing you may notice with some of the plugins created by uptime is that they have scripts that go in both the uptime_dir/plugins |
...
/scripts/ and uptime_dir/scripts/ folders. This is because the 'scripts' folder was the legacy location for storing plugin related files |
...
/scripts on older versions of Uptime Infrastructure Monitor. |
...
When creating your own plugins, you should be placing all your scripts/files within your own folder in uptime_dir/plugins/scripts/. |
So in the case of the Custom Remote Monitor's 'files' folder, you'll notice it contains some sub folders (ie. plugins/scripts/monitor-custom-remote ) which eventually contain a single rcs.php file.
When installed on a Linux monitoring station those files will end up in a location similar to below. (In this example, Uptime Infrastructure Monitor was installed in the default /usr/local/uptime location). The 'monitor-custom-remote.sh' file comes from a similar sub-folder within the 'files-posix' folder.
Similarly on a Windows monitoring station that file would end up in the location similar to below. (In this example Uptime Infrastructure Monitor was installed into the default C:\Program Files\uptime software\up.time\ location for Windows). The 'monitor-custom-remote.bat' file comes from a similar sub- folder within the plugin's 'files-win' folder.
Extension.json
Now that we've seen how a plugin monitor is packaged into it's own zip file, the last piece we need to look at the extension.json file that the monitoring station uses to know which plugins are available for install and where to get the associated zip files. By default Uptime Infrastructure Monitor will attempt to get these details from this location: http://the-grid.uptimesoftware.com/extension.json on our website.
...
If your not aware, there's a variety of different copyright licensing models available for open source software that outlines what changes someone can make to your code and how can they share it among others. At Uptime Infrastructure Monitor we recommend using one of the 'Creative Commons' Licenses as they provide easy to understand descriptions of what the license covers. Details about these licenses are available at: https https://creativecommons
.org/licenses/
Of the licenses listed on the Creative Commons website, we recommend using the Attributionthe Attribution-ShareAlike with plugins as it provides the best fit for how plugins are typically created and expanded upon. Once you've chosen the appropriate license for your plugin, you'll need to mention it somewhere within the plugin itself, typically either as part of the readme itself or by adding a license.txt file to your plugin repo. See this page on GitHub for some common ways people handle this.
...
If you haven't been using git or some other version control tool while creating your plugin then it's time to create a repository for it on GitHub, as that's the easiest way to share your creation with us and make it available for download via the Extension Manager. Here's some documentation on GitHub.com that covers the basics of howto create your own repository and a general introduction for working with git.
Once your plugin is available on GitHub it's time to contact uptimecontact uptime-support@idera.com and let us know about your creation. From there we'll take a look at what your plugin does, and how it works, and do some of the remaining tasks involved in making it available for download via Uptime Infrastructure Monitor's extension manager.