You can have a monitor assigned to the pool. You can also have monitors assigned directly to a member. If a pool member has a member-specific monitor it will not use any pool monitors.
In the example below, 1.1.1.1:80 will be monitored using only the http_1.1_monitor. All other pool members without a member specific monitor will inherit the monitor(s) associated with the pool. So 1.1.1.2:80 will be monitored by the default http monitor. You can have more than one monitor associated with both the pool and/or the specific pool members.
pool my_pool {
members {
1.1.1.1:80 {
monitor http_1.1_monitor
session monitor-enabled
}
1.1.1.2:80 {
session monitor-enabled
}
}
monitor http
}
For both pool monitors and pool member-specific monitors, you can separately specify a minimum number of monitors which need to succeed:
pool my_pool {
monitor all min 2 of http tcp http_1.1_monitor
members {
1.1.1.1:80 {
monitor min 1 of http_1.1_monitor gateway_icmp
}
1.1.1.2:80 {}
1.1.1.3:80 {}
}
}
In this second example, 1.1.1.1 will be checked using http_1.1_monitor and gateway_icmp. As the Availability Requirement (min X of ...) is set to 1 1.1.1:80 will be marked up if either the http_1.1_monitor or gateway_icmp monitors succeed.
1.1.1.2:80 and 1.1.1.3:80 will both be checked by the pool monitors http, tcp and http_1.1_monitor. As the Availability Requirement is set for 2 the pool members will be marked up if two or more of the monitors succeed.
So why would you want to do this? Your web servers might require the host header being set with a server-specific value. If that were the case, you could create one custom HTTP monitor for each and assign each to the corresponding pool member instead of on the pool. Other than that, I haven't seen many customers use member-specific monitors.
Aaron