icall triggered handler
3 TopicsGenerate qkview or ucs on failover
Problem this snippet solves: This iCall script collects a qkview and a UCS after a failover event. It is hardcoded for traffic-group-1. How to use this snippet: Implementation Details This iCall script requires v11.4 or higher. The script can be loaded via: load sys config merge file /var/tmp/handle-failover.conf Code : sys icall script detect-failover { app-service none definition { # prime the iApp to assume it's standby so that it doesn't generate # a qkview+ucs on the initial run (which wouldn't be a state # transition) set old_status standby while { 1 } { # this will block until another event is present. As we only # subscribe to HA events, that means that whenever an event is # raised it represents a new message from SOD EVENT::get_next set new_status $EVENT::context(/Common/traffic-group-1) # detect if we just went standby if { $new_status eq "standby" && $old_status ne "standby" } { puts "failover detected - i am standby now!" set date [clock format [clock seconds] -format "%Y%m%d%H%M%S"] set settings [tmsh::get_config sys global-settings] set host [tmsh::get_field_value [lindex $settings 0] hostname] puts "generating qkview /var/tmp/$host-$date.qkview" exec /usr/bin/qkview -f /var/tmp/$host-$date.qkview 2> /dev/null & puts "generating UCS /var/local/ucs/$host-$date.ucs" tmsh::save sys ucs /var/local/ucs/$host-$date.ucs } # save the state set old_status $new_status } } description none events none } sys icall handler perpetual handle-failover { script detect-failover subscriptions { failover { event-name FAILOVER_STATE } } }512Views0likes2CommentsRun tcpdump on event
Problem this snippet solves: This example shows how to trigger an iCall script using a log message as the trigger. In particular, it shows how to watch for messages about pool members failing their monitors, and then running tcpdump to capture some packets sent to that pool member in order to help troubleshoot later. How to use this snippet: Implementation Details This iCall script requires v11.4 or higher. Code : 1. create the following iCall script: modify script tcpdump { app-service none definition { set date [clock format [clock seconds] -format "%Y%m%d%H%M%S"] foreach var { ip port count vlan } { set $var $EVENT::context($var) } exec tcpdump -ni $vlan -s0 -w /var/tmp/${ip}_${port}-${date}.pcap -c $count host $ip and port $port } description none events none } 2. create an event handler for it that looks like the following: sys icall handler triggered tcpdump { script tcpdump subscriptions { tcpdump { event-name tcpdump } } } 3. modify /config/user_alert.conf to contain entries that looks like the following: alert local-http-10-2-80-1-80-DOWN "Pool /Common/my_pool member /Common/10.2.80.1:80 monitor status down" { exec command="tmsh generate sys icall event tcpdump context { { name ip value 10.2.80.1 } { name port value 80 } { name vlan value internal } { name count value 20 } }" } You will need one of these stanzas for each pool member that you want to monitor in this method - or to modify the example to act on different events and different objects.997Views1like0CommentsMark Server Down on Excessive Errors
Problem this snippet solves: This is an iApp template that allows a user to create a virtual+pool and to specify a type of error (400 or 500) to watch for and some threshold information to meet before disabling a pool member that is responding with those errors. It uses an iRule to create per-pool member iStats, custom stats to calculate rates over them, iStat triggers to monitor for error conditions, a triggered event handler to catch it, and a script that resubmits the iApp in order to disable the pool member. Note: It's pretty easy to get web servers to generate 400 errors, so take care that you don't DoS your applications with this. How to use this snippet: Implementation Details This iCall script requires v11.4 or higher.401Views0likes0Comments