Handling alarms in the monitoring system

Question

Erlang

Good day. I am working on a monitoring system focused on working in the global network, with a large number of clients ... The client is in c, the server is erlang. Since erlang is weak in arithmetic, but it works very well with the network, and most hosting sites provide anlim traffic, the CPU / memory is the pricing factor for them, the idea arose to move the code responsible for analyzing monitoring data directly in the client, where there are superfluous problems no computing power. A small delay in the formation of an alarm is not critical. As I see it. Let's say there are five client programs, there is a value calculated as the sum of parameters with the same name, or not, from these clients. So, when the server receives fresh data from one of the clients, it simply relays them to the other four. When receiving an alarm, a flag is set on the server and alarm messages from other clients are simply ignored, for a while. I would like to hear your opinion on such a scheme.
PS If constructive criticism does not kill the flight of this thought, then I plan to supplement the client with p2p functionality, that is, I want to ensure that the server exclusively coordinates the work of clients, receives alarms, and they exchange messages directly with each other.

Answer 1

It is not clear why the client receives information from another client.
In general, I think that this is wrong. The agent should be small and not interfere with the server's work. His job is to collect the current data and spit it out to the server. And the server must count - because it contains all the data about the client.
Hang the logic on the base - count everything in it. Or make an application server that will count for you if erlang can't handle it.

Answer 2

pavelsh, but in this case, it turns out that the client just plays the role of that component, the application server, which is responsible for intensive calculations. Only it will not be a separate process on the same server, but will work over the network, besides providing redundancy and the possibility of a painless update.
As for the size of the agent, the code responsible for processing data and generating alarms - + 500 kb to the size of the binary - the maximum. And if you talked about the extra load that it creates on the processor, then this is not even a subject for conversation, given the power of modern computers. In addition, having implemented a similar approach to calculations, absolutely nothing prevents you from starting separate nodes specifically for alarms, written even in assembler. Hanging logic on the database - I think it's bad manners.
To be honest, I didn’t see in the comments what I expected, alas.