Sponsored Content
The Lounge What is on Your Mind? Status of Badging System - Beta 1 Post 303028620 by Neo on Friday 11th of January 2019 09:28:01 AM
Old 01-11-2019
I have been testing the badging system, and it works really good.

The only hiccup (with I have a work-around for) is that when I add new badges to the grid in the future, which includes enabling the "Reserved" badges, this causes a change in the hash values and also in the arrays, so a "new badge alert" is issued.

I created a work-around which reverses the order of the PHP array_diff_assoc() call and then compares the size of the two arrays (in forward and reverse order), and so when I bring a new badge on line to the grid, there is no alert generated.

So, I may bring all of the badges "online" even though they are now in "reserve" so that all badges will have a default color assigned; and then assigning a new color to a member (assigning the badge a state) will insure a proper alert.

These are small nuances from testing, and actually, could just bring them all on line and turn off alerts for a day or two, and then turn alerts back on, and it would work out as well.

At some point, when we code a new live application, we need to say "it's good enough" and stop trying to make the code perfect, and I'm getting close to that point.

Basically, the badging system and the alerts work fine and I continue to test them for exceptional situations, and basically, not 100% as I would like, but very good Smilie
These 2 Users Gave Thanks to Neo For This Post:
 

6 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

system status report script

hi i m new to this forum as well as UNIX. I've got an assignment but i don't know how can I start it. can anyone please help to tell me how can I start it? I added here few lines from my assignment. In industry, it is common for a single organisation to provide technical support for a... (0 Replies)
Discussion started by: moco
0 Replies

2. Shell Programming and Scripting

System status query script

Hi, I am trying to access and read certain lines from a configuration XML file on multiple servers (within the LAN). Fortunately the file name and path is always the same for all servers. An example extract of the file is as follows: <DUMMY-SMSC>false</DUMMY-SMSC> ... (2 Replies)
Discussion started by: jaz8212
2 Replies

3. Homework & Coursework Questions

Listing Live System Status

1. Edit a script named update.sh that generates status.html in your web directory: ~/public_html/. I need to write specific commands to show each specific item 2. The generated webpage should include information related to: UNIX : kernel version of ed-lab server USER : number of users on the... (13 Replies)
Discussion started by: devinj
13 Replies

4. What is on Your Mind?

New Badging System - Badges Prototype Beta 1 (Badges Only)

Today I mapped out the new badging system using FA icons, Beta 1 in no particular order except a 6 x 8 grid: https://www.unix.com/members/1-albums215-picture991.png The prototype HTML code for this layout: <style> .fa-badge-grid { font-size: 1.5em; } .row { ... (38 Replies)
Discussion started by: Neo
38 Replies

5. Web Development

Notes with Ravinder on Badging System Development Part II

Part II: Current PHP file Beta 73 Not Optimized: <?php $version = 73; $query = "SELECT * FROM " . TABLE_PREFIX . "user WHERE userid='" . $uid . "'"; $usertable = $db->query_read_slave($query); $modaluser = $db->fetch_array($usertable); $modaluser = gmdate("d F Y", $modaluser); $modaluser... (48 Replies)
Discussion started by: Neo
48 Replies

6. What is on Your Mind?

Badging System: UNIX.COM Bug Hunter Badge (New)

I have moved the bug badge out of reserve and into the main stream. Basically, I will assign a color level like the others, based on who has made a good actionable bug report for UNIX.COM. "Good" means screenshots, links, and even details from web dev tools our the HTML source code. So far,... (0 Replies)
Discussion started by: Neo
0 Replies
HOBBITD_ALERT(8)					      System Manager's Manual						  HOBBITD_ALERT(8)

NAME
hobbitd_alert - hobbitd worker module for sending out alerts SYNOPSIS
hobbitd_channel --channel=page hobbitd_alert [options] DESCRIPTION
hobbitd_alert is a worker module for hobbitd, and as such it is normally run via the hobbitd_channel(8) program. It receives hobbitd page- and ack-messages from the "page" channel via stdin, and uses these to send out alerts about failed and recovered hosts and services. The operation of this module is controlled by the hobbit-alerts.cfg(5) file. This file holds the definition of rules and recipients, that determine who gets alerts, how often, for what servers etc. OPTIONS
--config=FILENAME Sets the filename for the hobbit-alerts.cfg file. The default value is "etc/hobbit-alerts.cfg" below the Xymon server directory. --dump-config Dumps the configuration after parsing it. May be useful to track down problems with configuration file errors. --checkpoint-file=FILENAME File where the current state of the hobbitd_alert module is saved. When starting up, hobbitd_alert will also read this file to restore the previous state. --checkpoint-interval=N Defines how often (in seconds) the checkpoint-file is saved. --cfid If this option is present, alert messages will include a line with "cfid:N" where N is the linenumber in the hobbit-alerts.cfg file that caused this message to be sent. This can be useful to track down problems with duplicate alerts. --test HOST SERVICE [options] Shows which alert rules matches the given HOST/SERVICE combination. Useful to debug configuration problems, and see what rules are used for an alert. The possible options are: --color=COLORNAME The COLORNAME parameter is the color of the alert: red, yellow or purple. --duration=SECONDS The SECONDS parameter is the duration of the alert in seconds. --group=GROUPNAME The GROUPNAME paramater is a groupid string from the hobbit-clients.cfg file. --time=TIMESTRING The TIMESTRING parameter is the time-of-day for the alert, expressed as an absolute time in the epoch format (sec- onds since Jan 1 1970). This is easily obtained with the GNU date utility using the "+%s" output format. --debug Enable debugging output. HOW HOBBIT DECIDES WHEN TO SEND ALERTS
The hobbitd_alert module is responsible for sending out all alerts. When a status first goes to one of the ALERTCOLORS, hobbitd_alert is notified of this change. It notes that the status is now in an alert state, and records the timestamp when this event started, and adds the alert to the list statuses that may potentially trigger one or more alert messages. This list is then matched against the hobbit-alerts.cfg configuration. This happens at least once a minute, but may happen more often. E.g. when status first goes into an alert state, this will always trigger the matching to happen. When scanning the configuration, hobbitd_alert looks at all of the configuration rules. It also checks the DURATION setting against how long time has elapsed since the event started - i.e. against the timestamp logged when hobbitd_alert first heard of this event. When an alert recipient is found, the alert is sent and it is recorded when this recipient is due for his next alert message, based on the REPEAT setting defined for this recipient. The next time hobbitd_alert scans the configuration for what alerts to send, it will still find this recipient because all of the configuration rules are fulfilled, but an alert message will not be generated until the repeat interval has elapsed. It can happen that a status first goes yellow and triggers an alert, and later it goes red - e.g. a disk filling up. In that case, hob- bitd_alert clears the internal timer for when the next (repeat) alert is due for all recipients. You generally want to be told when some- thing that has been in a warning state becomes critical, so in that case the REPEAT setting is ignored and the alert is sent. This only happens the first time such a change occurs - if the status switches between yellow and red multiple times, only the first transition from yellow->red causes this override. When an status recovers, a recovery message may be sent - depending on the configuration - and then hobbitd_alert forgets everything about this status. So the next time it goes into an alert state, the entire process starts all over again. ENVIRONMENT
MAIL The first part of a command line used to send out an e-mail with a subject, typically set to "/usr/bin/mail -s" . hobbitd_alert will add the subject and the mail recipients to form the command line used for sending out email alerts. MAILC The first part of a command line used to send out an e-mail without a subject. Typically this will be "/usr/bin/mail". hobbitd_alert will add the mail recipients to form the command line used for sending out email alerts. FILES
~xymon/server/etc/hobbit-alerts.cfg SEE ALSO
hobbit-alerts.cfg(5), hobbitd(8), hobbitd_channel(8), xymon(7) Xymon Version 4.2.3: 4 Feb 2009 HOBBITD_ALERT(8)
All times are GMT -4. The time now is 09:20 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy