I want to monitor IPMI System Event Log(SEL) in real time. What I want that is that whenever a event is generated in SEL , automatically a mail alert should be generated .
One way for me to achieve this is that I can write a script and schedule it in cron. The script will run 3 or 4 times a day so whenever a new event is generated , a mail alert will be send to me.
I want the monitoring to be active. Like whenever a event is generated , a mail should be sent to me instead of checking at regular intervals.
The SEL Log format is as follows:
server-001% sudo ipmitool sel list
b4 | 05/27/2009 | 13:38:32 | Fan #0x37 | Upper Critical going high
c8 | 05/27/2009 | 13:38:35 | Fan #0x37 | Upper Critical going high
dc | 08/15/2009 | 07:07:50 | Fan #0x37 | Upper Critical going high
So , for the above case whenever a new event is generated , automatically a mail alert should be send to me with the event.
How can I achieve this with a bash script . Any pointers will be highly appreciated.
I believe some vendors have special extensions in their firmware for exactly what you are describing (i.e. you just configure an e-mail address in the service processor), but I can't speak to each vendor's support. You'll have to look for your motherboard's documentation for that.
In terms of a standard mechanism, you are probably looking for IPMI PET (platform event trap) support. With PET, when certain SEL events are generated, it will generate a SNMP trap. The SNMP trap, once received by an SNMP daemon can do whatever you want, such as send an e-mail out.
A user of FreeIPMI wrote up his experiences in a doc and posted his scripts, which you can find here:
http://www.gnu.org/software/freeipmi/download.html
(Disclaimer: I maintain FreeIPMI so I know FreeIPMI better, unsure of support in other IPMI software.)
As an FYI, several IPMI SEL logging daemons (FreeIPMI's ipmiseld and ipmitool's ipmievtd are two I know) poll the SEL based on a configurable number of seconds and log the SEL information to syslog. A mail alert could also be configured in syslog to send out an e-mail when an event occurs. These daemons are still polling based instead of real-time, but the daemons will probably handle many IPMI corner cases that your cron script may not be aware of.
Monitoring of IPMI SEL events can be achieved using ipmievd tool . It is a part of ipmitool package.
# rpm -qf /usr/sbin/ipmievd
ipmitool-1.8.11-12.el6.x86_64
To send SEL events to syslog , execute the following command.
ipmievd sel daemon
Now , to simulate generation of SEL events , we will execute the following command.
ipmitool event 2
This will generate the following event
` Voltage Threshold - Lower Critical - Going Low`
To get the list of SEL events that can be generated are , try
# ipmitool event
usage: event <num>
Send generic test events
1 : Temperature - Upper Critical - Going High
2 : Voltage Threshold - Lower Critical - Going Low
3 : Memory - Correctable ECC
The event will be notified to /var/log/messages. Following message was generated in log file.
Oct 21 15:12:32 mgthost ipmievd: Voltage sensor - Lower Critical going low
Just in case it helps anyone else...
I created a shell script to record data in this format, and I parse it with php and use google's chart api to make a nice line graph.
2016-05-25 13:33:15, 20 degrees C, 23 degrees C
2016-05-25 13:53:06, 21.50 degrees C, 24 degrees C
2016-05-25 14:34:39, 19 degrees C, 22.50 degrees C
#!/bin/sh
DATE=`date '+%Y-%m-%d %H:%M:%S'`
temp0=$(ipmitool sdr type Temperature | grep "CPU0 Diode" | cut -f5 -d"|")
temp1=$(ipmitool sdr type Temperature | grep "CPU1 Diode" | cut -f5 -d"|")
echo "$DATE,$temp0,$temp1" >> /events/temps.dat
The problem I'm having now is getting the cron job to access the data properly, even though it's set in the root crontab.
Related
I set up an AMQP 1.0 link with just the path and a filter using the Apache Qpid Electron Go wrapper for Qpid Proton like this:
amqpConnection.Receiver(
// the path containing the consumer group
// and the partition Id
electron.Source("<EVENTHUB_PATH>"),
// the filter map contains some annotations filters
// for the Event Hub offset
electron.Filter(filterMap),
)
I followed this doc to setup the AMQP link options: https://godoc.org/qpid.apache.org/electron#LinkOption
However while running the Go app I've realised it was very slow in fetching messages, so I've added 2 more link options like this:
amqpConnection.Receiver(
electron.Source("<EVENTHUB_PATH>"),
electron.Capacity(100),
electron.Prefetch(true),
electron.Filter(filterMap),
)
but after adding the capacity and the prefetch link options I don't see any improvement in the performance.
I keep receiving approximately 10 messages every ~5 seconds from 4 parallel links (one link per partition).
I've tried to run the app with the environment variable PN_TRACE_RAW=true for the verbose output from Qpid Proton (cf. this: https://qpid.apache.org/releases/qpid-proton-0.18.0/proton/c/api/group__transport.html), but I am not sure
on what should I look for to troubleshoot this issue.
I don't think there is any issue with the Qpid settings, but anyway this is what I see on the terminal:
[0x9fd490]:0 -> #attach(18) [name="<MY_CUSTOM_NAME>",
handle=1, role=true, snd-settle-mode=0, rcv-settle-mode=0, source=#source(40) [address="<MY_CUSTOM_PATH>",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, filter={:string=#:"apache.org:selector-filter:string"
"amqp.annotation.x-opt-offset > '<MY_CUSTOM_OFFSET>'"}], target=#target(41) [address="",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]
[0x9fd490]:0 -> #flow(19) [next-incoming-id=1, incoming-window=2147483647, next-outgoing-id=1,
outgoing-window=0, handle=1, delivery-count=0, link-credit=100, drain=false]
I also tried to run the Go app in a Azure VM in the same Azure Location as the Event Hub, but no improvement in the performance.
How could I fetch many messages at the same time in the same "round trip"?
I need to process thousands of messages per seconds.
You are correct that you need a prefetch window but the electron client can do a LOT better than that.
I did a quick test with the electron examples from https://github.com/apache/qpid-proton/tree/master/examples/go/electron
I get 3000 msg/sec even without prefetch, and nearly 10000 msgs/sec with.
$ ./broker -qsize 100000 &
Listening on [::]:5672
$ ./send -count 10000 /x ; time ./receive -count 10000 /x
Received all 10000 acknowledgements
Listening on 1 connections
Received 10000 messages
real 0m2.612s
user 0m1.611s
sys 0m0.510s
$ ./send -count 10000 /x ; time ./receive -count 10000 -prefetch 1000 /x
Received all 10000 acknowledgements
Listening on 1 connections
Received 10000 messages
real 0m1.053s
user 0m1.272s
sys 0m0.277s
There is clearly something funny going on - I'd like to help you get to the bottom of it.
PN_TRACE_RAW is a bit too verbose to be helpful, try PN_TRACE_FRM=1 which will give you a more readable summary.
I'm happy to continue the conversation either here or on users#qpid.apache.org if it turns into more of a support case than a question/answer.
I have a TellstickDuo, a small device capable of sending signals to my lamps at home to turn them on or off based on a schedule. This device sends around 3-5 "on-signals" and "off-signals" every time i press the remote control button (to make sure at least one signal is sent correctly i guess!?). I also have a Raspberry Pi that listens for these signals and starts a script when a specific signal is found (based on the lamp-devices id´s).
The problem is that everytime when it sends 3-5 signals my script runs the same amount of times but i only want it to run once. Is there any way to capture these signals and with bash (.sh) ignore everyone but one ?
Code sent from device:
...RUNNING /usr/bin/php /var/www/autosys/python_to_raw.php "class:command;protocol:arctech;model:selflearning;house:13741542;unit:10;group:0;method:turnon;"
...RUNNING /usr/bin/php /var/www/autosys/python_to_raw.php "class:command;protocol:arctech;model:selflearning;house:13741542;unit:10;group:0;method:turnon;"
...RUNNING /usr/bin/php /var/www/autosys/python_to_raw.php "class:command;protocol:arctech;model:selflearning;house:13741542;unit:10;group:0;method:turnon;"
...RUNNING /usr/bin/php /var/www/autosys/python_to_raw.php "class:command;protocol:arctech;model:selflearning;house:13741542;unit:10;group:0;method:turnon;"
and my script is:
#!/bin/bash
if [[ ( "${RAWDATA}" == *13741542* ) && ( "${RAWDATA}" == *turnon* ) ]]; then
# Something will be done here, like turn on a lamp, send an email or something else
fi
(Some explanation to the RAWDATA code can be found here: http://developer.telldus.com/blog/2012/11/new-ways-to-script-execution-from-signals)
If i set my bash-script to send an email i get 4 emails, if i set it to update a counter at my local webpage it updates it 4 times.
There is no way to controll how many signals the device will send, but can i only capture it once somehow? Maybe some way to "run script on first signal and drop everything else for 5 seconds"
In order to set up a self-monitoring of a linux OS (CentOS) in order to send traps if a condition occurs i have configured the lines
com2sec notConfigUser default Public0
group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser
view systemview included .1
access notConfigGroup "" any noauth exact systemview systemview none
for disk query
disk / 100000000
trap2sink 10.10.64.132
authorization for self monitoring
rouser admin
iquerySecName admin
define message to send OID to monitor threshold values
monitor -r 10 DiskAlmostFull dskPercent < 90
monitor -r 10 machineTooBusy hrProcessorLoad < 90
But the traps are generated only when i restart the snmpd deamon.
I have tried to troubleshoot this issue without success.
Any held will be helpful.
Thanks in advance
Having had the same problem, I discovered the following explanation in "man snmpd.conf".
Section "monitor [OPTIONS] NAME EXPRESSION" states:
"Note that the event will only be triggered once, when the expression first matches. This monitor entry will not fire again until the monitored condition first becomes false, and then matches again."
You may not like the answer, but the monitor command behaves as advertised.
I've recently read the article CQRS à la Greg Young and am still trying to get my head around CQRS.
I'm not sure about where input validation should happen, and if it possibly has to happen in two separate locations (thereby violating the Don't Repeat Yourself rule and possibly also Separation of Concerns).
Given the following application architecture:
# +--------------------+ ||
# | event store | ||
# +--------------------+ ||
# ^ | ||
# | events | ||
# | v
# +--------------------+ events +--------------------+
# | domain/ | ---------------------> | (denormalized) |
# | business objects | | query repository |
# +--------------------+ || +--------------------+
# ^ ^ ^ ^ ^ || |
# | | | | | || |
# +--------------------+ || |
# | command bus | || |
# +--------------------+ || |
# ^ |
# | +------------------+ |
# +------------ | user interface | <-----------+
# commands +------------------+ UI form data
The domain is hidden from the UI behind a command bus. That is, the UI can only send commands to the domain, but never gets to the domain objects directly.
Validation must not happen when an aggregate root is reacting to an event, but earlier.
Commands are turned into events in the domain (by the aggregate roots). This is one place where validation could happen: If a command cannot be executed, it isn't turned into a corresponding event; instead, (for example) an exception is thrown that bubbles up through the command bus, back to the UI, where it gets caught.
Problem:
If a command won't be able to execute, I would like to disable the corresponding button or menu item in the UI. But how do I know whether a command can execute before sending it off on its way? The query side won't help me here, as it doesn't contain any business logic whatsoever; and all I can do on the command side is send commands.
Possible solutions:
For any command DoX, introduce a corresponding dummy command CanDoX that won't actually do anything, but lets the domain give feedback whether command X could execute without error.
Duplicate some validation logic (that really belongs in the domain) in the UI.
Obviously the second solution isn't favorable (due to lacking separation of concerns). But is the first one really better?
I think my question has just been solved by another article, Clarified CQRS by Udi Dahan. The section "Commands and Validation" starts as follows:
Commands and Validation
In thinking through what could make a command fail, one topic that comes up is validation. Validation is
different from business rules in that it states a context-independent fact about a command. Either a
command is valid, or it isn't. Business rules on the other hand are context dependent.
[…] Even though a command may be valid, there still may be reasons to reject it.
As such, validation can be performed on the client, checking that all fields required for that command
are there, number and date ranges are OK, that kind of thing. The server would still validate all
commands that arrive, not trusting clients to do the validation.
I take this to mean that — given that I have a task-based UI, as is often suggested for CQRS to work well (commands as domain verbs) — I would only ever gray out (disable) buttons or menu items if a command cannot yet be sent off because some data required by the command is still missing, or invalid; ie. the UI reacts to the command's validness itself, and not to the command's future effect on the domain objects.
Therefore, no CanDoX commands are required, and no domain validation logic needs to be leaked into the UI. What the UI will have, however, is some logic for command validation.
Client-side validation is basically limited to format validation, because the client side cannot know the state of the data model on the server. What is valid now, may be invalid 1/2 second from now.
So, the client side should check only whether all required fields are filled in and whether they are of the correct form (an email address field must contain a valid email address, for instance of the form (.+)#(.+).(.+) or the like).
All those validations, along with business rule validations, are then performed on the domain model in the Command service. Therefore, data that was validated on the client may still result in invalidated Commands on the server. In that case, some feedback should be able to make it back to the client application... but that's another story.
I am new to NTP protocol. I read the RFC1305 and have some questions about NTP.
My questions are related to NTP working modes.
According to RFC1305 there are 8 modes
| 0 | reserved
| 1 | symmetric active
| 2 | symmetric passive
| 3 | client
| 4 | server
| 5 | broadcast
| 6 | NTP control message
| 7 | reserved for private use
My questions:
1- What are the differences between the symmetric passive device and symmetric active one?
2- Two symmetric active device can sync each other and Two passive active device can sync each other too ,but Can a symmetric passive device been synced by a symmetric active one and vice versa?
3- When a Symmetric passive device is connected to symmetric active one which one sends the NTP packet first?
4- What happens in broadcasting mode? Does the client send any NTP packet or only the broadcaster does that?
5- ”in order to sync some clients who have CLASS D IP ‘s , the server fills the 3 time stamp fields(receive time stamp is null) and set the mode to 5 and send the packet to 224.0.1.1 and clients get that packet and they send nothing in this procedure” Is this true?
6- Who sends the NTP control message? Client or broadcaster? What’s it for? What’s the appropriate answer for it?is it always 12 bytes long?
7- “A stratum 1 NTP server (GPS connected) acts like this: answer mode 1 requests with mode 2, mode 3 with mode 4 and mode 6 with 7” Is this true?
can only reply to a few questions:
-4. only the server (broadcaster) is allowed to send any ntp-packet in this mode
clients only listen to the interface, parse the received packet and set their clock accordingly - there is no reply being send.
but clients may send a ntp-request too, the server should then not reply to this one.
-5. right. there is no answer supposed to be send by this clients.
Mode 6 is used by the ntpq program. It can for example query "a list of the peers known to the server as well as a summary of their state" (from the man page).
This has recently be exploited to do DDOS reflection attacks, because it can be triggered with spoofed IP address, and the reply is larger than the query. 1
For this reason mode 6 and 7 queries should be blocked from outside sources.