I'm want to send out an SMS alert when a client fails a keep alive check. I have no desire to reconfigure any clients keep alive settings, just simply use the defaults and send the alert.
You can configure this VERY easily on just the server. Your keepalives should use your default handler. You can set up your default handler to send the SMS (I just use the email handler but send it to mynumber#verizonwireless.com) if you are using the default handler for other things it is easeir to change your other checks to use a different handler than to reconfigure each client...
Ps as a side note (if you have more than a few servers that are being monitored by sensu) You should look into some configuration management tools. We use chef and it is wonderful. If I needed to change a handler for a check or even all of them I simply modify the recipe and then tell the machines to re converge and it the process is done in just a few minutes.
The keepalive check is just like any other check, and can take handlers.
http://sensuapp.org/docs/latest/keepalives
If you are using puppet, you can set the keepalive settings like this:
class { 'sensu':
...
client_keepalive => {
handlers => [ 'sms' ],
}
}
https://github.com/sensu/sensu-puppet/blob/a37c512b29daed9dee7359cac3f3086c0ab3e809/manifests/init.pp#L148
Related
My problem is related to SIM800 connection messages.
I use the module with STM32 developlment board. Sometimes module is reporting SMS Ready and Call Ready messages respectively. When I start to send AT commands to the module, it may send these messages (it doesn't happens all the times).
However, the commands I previously sent are apparently unrelated (for example HTTP commands), and SMS Ready / Call Ready messages is coming while they are not expected.
Because of this reason, Keil is reporting "Can not access" message in the debug session. Is it possible that disabling these messages when the connection is established? Or it means that module has an unexpected reset?
According to SIM800x modules AT commands guide, SMS ready and Call ready are URCs (unsolicited result codes) sent at startup as soon as the capabilities to deal with SMS and to perform calls respectively are correctly initialized and available.
So this is the first bad news for you: if you see them it probably means that your device reset due to a bug or as a consequence of one of the commands you previously provided.
The second bad news is that on the AT command guide linked above there's no mention of the capability to disable SMS Ready URC.
There's fortunately at least a good news: Call ready can be disabled by means of AT+CIURC command:
AT+CIURC (Enable or Disable Initial URC Presentation)
Syntax: AT+CIURC=<mode>
<mode> : 0 Disable URC presentation - 1 Enable URC presentation
Note: When module is powered on and initialization procedure is over URC "Call Ready" will be presented if is 1.
The guide also mentions the fact that this setting is saved in the profile area. So, in order to make sure it is persistent to reboot, after issuing the command store active profile:
AT&W
OK
For me, receiving a lot of messagens Call and SMS ready was a problem on current not enough to keep the module working.
(You can check it too watching the led blinking, if it blinks 6/7 times and stop for a while and restart over again, you have the same problem)
Just to SIM800 keep working is necessary at least 700mA.
Ps.: You can connect directly to your battery 18650 (3.7V-4.2V).
If you are using TP4056 module, you must remember there is 1A max current. try to connect in parallel more than 1 TP4056.
I am wondering if there is a way to trigger message box on server side.
My case is that I have some logic on server side of the scout application. In the middle of the process some decision need to be made. It this case I would like to trigger message box with YES, NO, CANCEL options.
The way my logic works it really hard to split it into two functions and call one first, ask question and call another with on answer. So this is out of the way for me.
If it is not possible to triggered message box on scout service, is there a way to "mimic" it. So call service method, in the middle pause it, go to client side, present messsage box, return to same service method and continue it.
Why do I need this:
I have dependencies graph (between fields) implemented on scout server side.
After one field has been changed, the whole dependencies graph will be resolved.
One node of the graph has some logic that need user interaction. Problem is that I don't know if this method will be called (dependent on a graph), and if after this method other nods will be called.
You have asked a very similar question few months ago:
Scout Eclipse present optional message on server side
MessageBox is a client concept (package is: org.eclipse.scout.rt.client.ui.messagebox).
You need to transfert the data you need from the server to the client and intercept this information client-side to display the message box you want.
As Jmini already said, MessageBox is a client concept. What you can do is sending back a status (from server to client), checking it on client side and show an appropriate message (box). But then you interrupt your service method and cannot go on where it stopped (alternatively you can throw a VetoException, but this interrupts your service method aswell, so same problem). In my opinion, it is also not a good design to 'request' a user interaction from server side, because in this case, the server side has to wait for the user to respond.
I suggest, if possible, to split your logic into different parts. At first, you execute the first part until you reach the point where you need the user interaction. Then you could save the current state of execution, return to client and show the message. After the user has responded, you should start the 'second' execution, depending on the user's input. This second execution should be started by calling another (new) service, which at first should load or restore the state of the execution saved before requesting the user input.
I have implemented a Notify/Listen mechanism, so when a special request is sent to the web server, using notify I can notify the workers (in Python) that there's a pending request waiting to be processed.
The implementation works fine, but the problem is that if the workers server is restarting, the notification gets lost, since at that particular time there's no listener.
I can implement a service like MQRabbit or similar, but my needs are so simple that implement such a monster is too much.
Is there any way, a configuration variable perhaps, that can give some persistence to the notification mechanism?
Thanks in advance
I don't think there is a way to persist notification channels, but you can simply store the pending requests to a table, and have the worker check for any missed work on startup.
Either a timestamp or a pending/completed flag would work, depending on what kind of work it's doing.
For consistency, you can have the NOTIFY fire from an INSERT trigger on the queue table, and have the worker always check for any remaining work (not just a specific request) when notified.
I am running asterisk on a elastix 2.2 distro. I have a Queue with EXT 9000 where 3 softphone (c#) extensions belong to this round robin queue.
I know that I could trigger a AGI or AMI event from the dialplan and let in some way a webservice know about the length of the queue and then forward this information to the softphones.
Is there any way that the softphones could get this information directly from asterisk. Either something AsteriskBuiltIn or ElastixBuiltIn.
a last resort (baaaaaad) idea was to open a line, call an encoded number like (555*1) and receive back a dtmf. it is a Bad Way but it would work.
Open for any suggestions
Queue drop events into ami.
Also queue log all actions into /var/log/asterisk/queue_log, which is posible put to mysql(see this)
There are no way say how your softphone can catch that event. But for sure you can get that info from mysql and rewrite your softphones to show that info.
Also elastix call center edition have web panel for call center. As option you can check fop2 project for panel.
I just got asked to reduce the traffic made by my GWT app. There is one method that checks for status.
This method is an asynchronous call wrapped in a Timer. I know web apps are stateless and all that, but I do wonder if there is some other way to do this, or if everyone has a Timer wrapped around a call when they need this kind of behaviour.
You can check out gwteventservice. It claims to have a way to push server events and notify the client.
I have a feeling they might be implemented as long running (hanging) client to server RPC calls which time out after an interval (say 20sec), and then are re-made. The server returns the callback if an event happens in the meanwhile.
I haven't used it personally but know of people using it to push events to the client. Have a look at the docs . If my assumption is correct, the idea is to send an RPC call to the server which does not return (hangs). If an event happens on the server, the server responds and that RPC call returns with the event. If there is no event, the call will time out in 20 seconds. Then a new call is made to the server which hangs in the same way until there is an event.
What this achieves is that it reduces the number of calls to the server to either one for each event (if there is one), or a call once every 20 seconds (if there isn't one). It looks like the 20 sec interval can be configured.
I imagine that if there is no event the amount of data sent back will be minimal - it might be possible to cancel the callback entirely, or have it fail without data transfer, but I don't really know.
Here is another resource on ServerPush - which is likely what's implemented by gwteventservice.
Running on Google app engine you could use they Channel technology
http://code.google.com/intl/en-US/appengine/docs/java/channel/overview.html
If you need the client to get the status from the server, then you pretty much have to make a call to the server to get it's status.
You could look at reducing the size of some of your messages
You could wind back the timer so the status call goes out less often
You could "optimise" so that the timer gets reset when some other client/server IO happens (i.e. if the server replies you know it is ok, so you don't need to send the next status request).