TORRUS_ACTION_NOTIFY(7)

πŸ“¦
version 3.00 Β· 3 versions
, in debian bookworm, debian trixie, ubuntu noble, ubuntu questing

πŸ’Œ TORRUS_ACTION_NOTIFY(7) β€” the torrus girlies' guide to action_notify πŸ’Œ

okay bestie, sit down, grab a boba, because we're talking about action_notify, the generic notification handler for Torrus monitor. this is the little icon that goes "hey. something's up. let me tell someone." ✨


✨ NAME ✨

action_notify β€” generic notification handler for Torrus monitor. that's it, that's the girl. πŸ’…


🌸 SYNOPSIS 🌸

 <action name="notify">
   <param name="action-type" value="exec" />
   <param name="command">
     $TORRUS_BIN/action_notify
   </param>
   <param name="launch-when" value="set" />
 </action>

πŸŽ€ DESCRIPTION πŸŽ€

okay so here's the vibe: this program was literally designed to be used from a monitor action only. it does not want to be run by just anyone, she has a very specific job. πŸ™ˆ

it takes its arguments from environment variables, exactly like it says under action-type exec in the Torrus XML Configuration Guide. no argv for her, only vibes (env vars).

and then β€” the main character move β€” the handler reads its configuration from <notify-siteconfig.pl>, which is a small Perl file. and what does that file do? it defines the notification paths for all the various conditions. it's giving matchmaker. it's giving "you, specifically you, get this alert." 🫢

Example, because examples ate:

 %Torrus::Notify::programs =
   (
    'mailto' => '$TORRUS_BIN/action_printemail | /usr/bin/mail $ARG1',
    'page' => '/usr/bin/echo $TORRUS_NODEPATH:$TORRUS_MONITOR ' .
    '>> /tmp/monitor.$ARG1.log'
    );

 %Torrus::Notify::policies =
   (
    'CUST_A' => {
        'match' => sub { $ENV{'TORRUS_P_notify_policy'} eq 'A' },
        'severity' => {
            '3' => [ 'mailto:aaa@domain.com',
                     'mailto:bbb@domain.com' ],
            '5' => [ 'page:1234', 'mailto:boss@domain.com' ] } } );

so like. in this example we define two message handlers: an e-mail sender, and a dummy replacement for a pager program (yes, a fake pager, she's cosplaying πŸ“Ÿβœ¨). then we define the notification policies.

for customer A, we define the policy so that the parameter "notify-policy" should match the name "A". that parameter lives in the datasource tree and marks only those leaves that belong to this customer. so it's like tagging your friends in the group chat. no, not that friend. THIS friend. 🎯

then, depending on the monitor severity, different notification paths are defined. for severity values higher or equal 3, aaa@domain.com and bbb@domain.com will receive the email notifications. and for severity higher than or equal 5, all recipients will receive the notification. escalating the drama, as she should. πŸ”₯

and the "match" argument? it's a Perl subroutine, so it can depend on various parameters, such as the time of day or the day of the week, the tree name, and so on. so specific. so powerful. no cap. πŸ’–


πŸ“ FILES πŸ“

  • /etc/torrus/conf/notify-siteconfig.pl β€” the notification policies configuration. this is where the girlies live. 🏠

πŸ‘€ SEE ALSO πŸ‘€

  • torrus(8) β€” go read her too, she's iconic

πŸ“ NOTES πŸ“

see more documentation at the Torrus home page: http://torrus.org 🌈


πŸ‘‘ AUTHOR πŸ‘‘

Stanislav Sinyagin <ssinyagin@k-open.com> β€” thank you for your service, king πŸ«‘πŸ’œ


and that's the whole page bestie!! this was torrus version 3.00, dated 2023-05-02, filed under TORRUS_ACTION_NOTIFY(7). mwah, go notify someone you love them. πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from