Is Zabbix capable of forwarding messages to another Monitoring Platform like Icinga2 (Manager of Manager MOM Configuration) - nagios

I have worked with HP Openview/OMi in the past and I am new to the Nagios/Zabbix/Icinga2 frameworks. I was wondering if Zabbix is capable of forwarding messages to another monitoring system such as Icinga2 in the same manner as a manager of manager (MOM) or competency center configuration.

Zabbix gathers data and fires up triggers of various levels according to the defined expressions (ie: ping loss too high, cpu usage too high, service X unreachable).
You can configure Zabbix to react to triggers with actions: you can send a mail to a team, send notifications through telegram or sms, call a webhook or call a specific script to do actually anything you need.

Related

battery efficient publishing to iot-core

I have an app that, when activated, uploads location data. Currently it sends the data to the server via REST, however I would like to save on server costs and send the data via iot-core.
Previously, I would queue location updates, and only send them about once every few minutes, this way the phone would only turn on its data broadcasting once every few minutes and not keep it constantly, and save on battery life.
Is there a way to enable similar battery saving when uploading to AWS iot-core? I haven't run tests, but I assume that constantly sending messages via mqtt, websockets, or http is just as battery draining as regular rest messages.
This is somewhat related to Aws IoT Message Delivery.

How commands in fiware work correctly? Can we use IoT Agent instead of Orion Context Broker as user?

We are following the theory that as users we must issue a command to the Context Broker to change the state of a device: Image 1
In our case, this command already works if we do it from the IoT Agent, but however, if we execute it from the Context Broker through a PATCH, it does not reach the IoT Agent.
Do you know why this could be happening?
Our Context Broker request is the following: Image 2
And finally, the request we make from the IoT Agent, which is the one that works, is this: Image 3
Another doubt that arises is, if the IoT Agent updates all the information in the Context Broker, why not execute the request from there instead of from the Contex Broker?
Your request to Context Broker seems to be ok. Sometimes, the lack of ?type in the request causes problems (see for instance this post) but it doesn't seem to be your case.
I'd suggest to check registrations at Orion. Registration is the mechanism in which the request forwarding from Orion to IOTAgent is based (more info in Orion documentation. IOTAgent should create and manage them, but something could be failing. You can get existing registrations in Orion with the GET /v2/registrations operation.
With regards:
Another doubt that arises is, if the IoT Agent updates all the information in the Context Broker, why not execute the request from there instead of from the Contex Broker?
The FIWARE data management model is context-centric. Thus, the Context Broker is the central piece of the architecture, to intermediate between context producer and context consumer. Commands are a kind of "context production", so it makes sense that Context Broker deals with commands. Note that the client issuing the command maybe doesn't even are able to access to the IOTAgent directly (they use to be "close" to the physical devices they manage and not typically open to direct client requests).

Is this system an optimal solution to sync an app with a server in real time efficiently?

Problem
I have an Android and iOS app, looking like a classic social network. I need to update UI in real time. Currently, I use a classic system of a client polling each second to a php script by HTTP. The php script bother the database every second for every client and responds, most of the time that there is no new update. If there is a new update, the php script process it and send it back to the client app.
There are 3 problems in this approach : (1) slow user experience (1 second delay each time) + high battery and data usage, (2) apache machines bothered each second by incoming HTTP request, (3) database machine bothered each second by the apaches machines (requesting if they are new stored updates in the main database).
I feel that this system could be substentially improved. For problem (1), I know a TCP connection can be "piped" to the app, but there is still problem (3) because the thread behind the socket still polls the database each second to know if they are new stored updates for their member ID.
Solution ?
I thought of a system to get rid of any activity (client, apaches and database) if there are no new updates. There would be : N apaches server on N machines, a load balancer exposed to the Internet. Behind, these apache server, connected only to local network, 1 "central" database and one "update" database, dedicated for the update system. The "update" database would store 2 tables :
1 table for the mapping between user tokens (and their member ID), and the thread ID and name of current apache machine holding the thread. One user ID may have several connection tokens, but one connection token is associated to only one unique couple (PID - machine name). Each time a user connects to the app, it would create a TCP con held by one thread (in one apache machine), and the [thread ID - machine name] would be stored in that table.
1 table to store the updates themselves. They contain all the informations needed to get up-to-date data (either in raw primitive form like string or int, or in "reference" form, telling the recipient TCP threads it needs to compute "at sending time" some params, for more complex data structures)
The system would be the following :
(1) A user wants to send a message to another user. The app client of the sender sends an HTTP request to the app API endpoint; the load balancer forwards the request to one of the apache machines.
(2) The apache server requests the main database to insert the "user message" row.
(3) The apache server requests the "update" database to know if the recipient has any currently connected device.
(4) if there is at least one connected device, insert an "update" row in the "update" database with all the informations needed, and wake up all thread associated to the recipient user ID (maybe using C signals ?).
(5) All the thread(s) associated to the recipient user ID wake up, they look in the "update" database for new updates associated with their user ID, they process their parameters (especially if there are references params to be computed), they send them back to the recipient devices via TCP.
So my final question is : is such a system feasible, reliable and if so, do you think it can be optimal in term of database and apache machines performence ?
I'm more a front-end programmer and I'm not used to implement complex server architecture, so I wanted to have some opinions before diving into the code, especially if I missed something in my approach (storing PIDs is reliable ? Is it possible for one machine to wake up a thread in another machine through local network ? ...)
PS : I already tried Firebase cloud messaging, but the problem is that they authorize only a one dimension array to be sent with update params. When dealing with complex data structure (like a "user message"), when I receive a signal from FCM in my client app, I still need to make an extra HTTP call to my server to retrieve the new "user message" JSON payload. So, good for my apaches and databases machines (they are not bothered when there is no new updates), bad for the client app that has to send additional HTTP requests. Once again, tell me if I missed something here :)
Thanks for reading

Nagios3 configuration for sending simple text message on some port

I am developing an application and decided Nagios3 for performing monitoring stuff. But I am stuck at two points. I am using check_http plug-in for monitoring load on my service api. Now I want to perform below tasks.
I need to set a threshold in check_http for performing some task after crossing that threshold. I tried below command
'check_command check_nrpe_1arg!check_service_api'
but it only tells me the load, not any threshold is set. while below one doesn't work.
'check_command check_service_api!100!200'
I need to send simple text message on some port(my application).
I am new to Nagios, so please help me figuring out the solution except email notification stuff.
There is a check command that you can download called "notify_sms" that integrates with an API server hosted by a company called Esendex. They charge for their service but it works well.

Any reason why latency in updating timelineitem to my glass device?

i see latency issue - when i send a timelineitem from my glassware app, it takes a long time to appear on glass device.
I see the item in developer playground (https://developers.google.com/glass/playground)
Is it isolated issue on my WiFi (unlikely)? or some optimization done at Mirror server which queues timelineitems and sending in a specific interval to glass device?
Thanks
After doing some more investigation (In my case, i have setup private network inside enterprise network), i found out that some of the ports are blocked by firewall settings for incoming traffic from outside network, so glass device was not getting notifications from the Mirror Server.
It is possible either Channel API or XMPP is used in receiving notification messages from Mirror server to Glass. Those ports might have blocked by my firewall settings. I ran wireshark, still it is not clear which protocol or port is used in receiving notifications.
Also it is possible that glass device could get (HTTP GET) newly available cards from the mirror server by polling on specific time interval or other cases(changing WIFI network, etc).
I called Glass help, i could not get any feedback.
I would really appreciate if someone (from Google) could shed some light (port and protocol details) on how Glass gets notification from mirror server when new timeline card is available.
This is a known issue:
https://code.google.com/p/google-glass-api/issues/detail?id=185
Issue has been fixed by updating to XE10.

Resources