vidlec / monitor

Running

Development:

npm run vendor which creates vendor.js then npm run dev which build's everything else and serves it through Browsersync with hot reload.

Production

npm run prod build's everything and applies heavy compressions

#Monitor

Premise: Highly scalable monitoring aggregation service. Main focus is are micro-services. Each micro-service should be connected to RabbitMQ message queue. User should be able to turn them on and off independently.

User is provided with variety of gateways for receiving data from the network (SNMP, TCP, EIF, JMX etc…).

User has ability (is required) to write ::rules:: for certain situations. Using rules, it is possible to normalise data and store it in database in proper form for it to be displayed and manipulated upon. Rules are written in nodejs compliant ::JavaScript:: User can use selected array of nodejs API methods like fetch and others.

::TODO - Client, databases::

---

Main server

• Read Config
• Read Rules
• Connected to MQ _ Listen for Workers connection and store info about them (name, status etc..) _ Provide rules on demand _ Ability to send new rules to workers _ ??? Ability to start workers (would require some workers manager to handle start/stop of workers) ::Nice to have::
• Provide REST/GQL api for client apps. This should implement various endpoints including CRUD for Users, Alerts, Monitoring, Management, Authentication, etc…
• Should run special DB tasks like deleting old alerts etc… (using database worker)

---

Gateways

• Should listen on unique port

• Read config || get config from the server. Prefer having config for each gateway separated localy.

• Connected to MQ (sending rules and db tasks)

• ??? Add node ::cluster mode:: to share one port between multiple children ::Nice to have::

• Should have mechanism for filtering incoming data and apply proper rules based on that data. Example: If data contains some key name or request came from some specific IP dress use specific rules Possible by using filter function supplied by user and executed for every incoming request - ::possible bottleneck::

• After recieving processed rules, GW should be able to call database worker to perform operations upon database. These operations should be part of a database worker API and its up to gateway to implement whatever it wants. Generally gateway would want only to implement couple of methods like saveAlert, deleteAlert

• ??? ::Use GW instead if integrated endpoint on server:: this GW would need to implement many database worker methods, which would need to be added on the latter as well. This would then provide flexibility for the client and server management UI. Allowing it to be used with many different databases granted respective db connector exists for them. ::Nice to have::

---

Workers

Workers are isolated micro-services. They all connect to MQ and register with main server. This way its possible to keep track of them in one place and possibly control them remotely.

Rules

Rules worker is responsible for executing rules on incoming data and returns the result.

• Upon successful registration, worker should receive raw rules. These rules needs to be compiled in advance in order to speed up their execution.
• ::Each rule should be a function accepting incoming data:: and returning object to be sent to the database.
• When rules are compiled into functions, worker awaits rules execution tasks.

Database

Database worker is responsible for connecting to database and manipulating data in it.

• It should be able to use variety of databases and connectors to them.
• Database ::type, name, address:: and ::connector name:: are received upon successful registration.
• Worker then connects to the proper database and awaits tasks.
• When task is received worker uses proper connector to manipulate database

monitor's Issues

Add .nvmrc

What

I suggest to add .nvmrc to the root of the application.

Why

This will allow to ensure that the exact version of node is used on the project.

Suggestions

Hey, I decided I may try to give you some suggestions from personal experience. Maybe not everything will be relevant, but I hope I will be able to help.

1. eslintrc - no need to have a global __webpack_public_path__ unless you define public path on runtime. In case you are not sure if you do, that means you don't, so it's safe to remove this.
2. I don't know if you are using any custom fonts, but I encourage you to consider getting rid of them. Using system fonts is both beautiful and performant. In case of electron app, however, you can load a font as a static resource, which will deprive you from the performance limitations that web fonts have.
3. app.js Why would you ever want to import a client-side instance of store directly?
4. websockets.js Why not to have the same functionality embedded into a React component? The one you can subscribe to the store without passing the actual store around. The only difference is where it gets rendered, but I may be wrong.
5. id.js It's the same as writing (assuming you use babel-plugins-transform-export-extensions:

export createId from './id'

1. Header.jsx Highly opinionated, but I found it most reliable to use React.Component, React.PureComponent, etc., referenced from under React namespace. Why? Because it makes it easier to find where you use React classes, as opposed to just doing search for Component which can return you a lot of irrelevant namespaces, since it's quite a generic word.
2. Consider styled-components for css-in-js, it's amazing.
3. store.index.js I can recommend you to use Redux Devtools as a package, instead of relying on browser extension.
4. config This looks like it should be outside the client directory, as it controls server and other things.
5. What is your reasoning for having client/src and server/src instead of src/client and src/server?

Let me know if there are unclear points.

Allow binding between rules group and incoming requests

What

I propose to add an explicit binding between rules group and incoming requests.

Why

1. To minimize the filtering of rules in each worker.
2. To establish a basis for spawning group-specific workers.

How

1. Accept an optional rule group name in the incoming request.
2. Generate a unique id and set it to ruleGroupId property on the request sent to query.
3. Check for the group id presence, simplify the filtering once found.