NimbostratusThe GTM Pool APIs work similar to the LTM Pool APIs with regards to monitors. You must first create the Pool, which it seems you have done, and then set any associated attributes - including monitors.
For GTM, you can do this at the pool level with the set_monitor_rule() or at an individual member level with the set_member_monitor_rule() call.
Both of these APIs take in a MonitorRule structure which defines the behavior of how the monitor results are interpreted. It takes in a Type which indicates what triggers an action (one monitor failing, and AND condition for all monitors, or a "M of N" test). The quorum parameter is uses for the "M of N" Type. And lastly is an array of Monitor templates to apply for that rule. This is where you would pass in the template name for the monitor you wish to add.
I've written a few samples on Monitor instances in the past. This one comes to mind for LTM, but applying the monitor uses the same process as the GTM pool.
If you don't have a monitor created, you can use the GlobalLB.Monitor interface and associated methods.
For the last question on whether it would be easier to do it all in one shot. The answer is likely yes, but we designed it this way to allow us to be able to make our APIs more flexible and not so brittle to compatibility issues. What happens if the product changes for some reason and needs to add an additional field for a monitor associated with a Pool. Then we have to create a new .create() method. Eventually you will end up with an API with a bunch of different create methods over time leading to confusion. In this case, it likely won't be the issue but there were others where it has absolutely been the case. Sorry this seems a bit convoluted, but once you get a solution, it will continue working for you.
Hope this helps...
