T
Thierry Ciot
Guest
Corticon.js helps deliver relevant notifications in complex systems and application monitoring.
When monitoring systems and the applications running on them for large deployments, lots of monitoring events get generated. From these events, alerts are generated and notifications need to be sent to interested users. However, very soon too many notifications are sent and the various users responsible for these systems and applications can get overwhelmed.
Users need to receive only the alerts most relevant to them. This can be achieved by letting users define rules to only get what they want. For example, some users may only be responsible for two applications among all applications, and they are responsible for just these within a sub-domain of the overall monitored infrastructure. They should receive notifications via email for non-critical alerts and via text for all critical alerts.
This example is relatively simple, but things can get more complicated quickly. To get a feel for the complexity of the problem domain, let’s look at two additional examples.
First example:
A customer has three load balancers with two applications on each (app-prod1, app-prod2, app-stage1, app-stage2, app-dev1, app-local-dev1).
The alert notifications can be set up like this:
Second example:
A customer has one load balancer with five applications:
The alert notifications could be set up like this:
As you can see from the previous examples, the number of use cases and combinations can grow very quickly. Implementing all of these in code is complex and hard to maintain. A solution, implemented by one of our customers, is to use Corticon.js as a no-code rule engine to process events and alarms and to decide if these need to be sent to specific users.
There are multiple benefits to using a rule system like Corticon.js:
For this customer, using a rule system like Corticon.js has paid large dividends, as they can get to market more quickly confident in their ability to easily maintain and extend the system.
Find out here how Corticon as a no-code/low-code environment can help increase your productivity and deliver your solutions faster.
And you can enroll in a free training for Corticon.js here.
Enroll in a free Corticon Training
Continue reading...
When monitoring systems and the applications running on them for large deployments, lots of monitoring events get generated. From these events, alerts are generated and notifications need to be sent to interested users. However, very soon too many notifications are sent and the various users responsible for these systems and applications can get overwhelmed.
Users need to receive only the alerts most relevant to them. This can be achieved by letting users define rules to only get what they want. For example, some users may only be responsible for two applications among all applications, and they are responsible for just these within a sub-domain of the overall monitored infrastructure. They should receive notifications via email for non-critical alerts and via text for all critical alerts.
It Gets Complicated Quickly
This example is relatively simple, but things can get more complicated quickly. To get a feel for the complexity of the problem domain, let’s look at two additional examples.
First example:
A customer has three load balancers with two applications on each (app-prod1, app-prod2, app-stage1, app-stage2, app-dev1, app-local-dev1).
The alert notifications can be set up like this:
- dev-team1 will only receive notifications related to app-dev1 and app-local-dev1 from 9 to 5, Monday to Friday—all others should be ignored.
- dev-team1 should also be notified of issues happening on app-prod1 and app-prod2 24x7, but only if they are Critical.
- QA Team will receive notifications happening on app-stage 1 and 2.
- Infrastructure team will receive notifications generated by the three load balancers.
Second example:
A customer has one load balancer with five applications:
- MS Exchange mail server
- Apache web server
- Wordpress internal
- Public facing blog
- FTP server
The alert notifications could be set up like this:
- QA Team will receive notifications happening on app-stage 1 and 2.
- Infrastructure team will receive notifications generated by the load balancers.
- Apache web server and Wordpress internal notifications will be sent to to the web dev team and the dev team, but only if the severity is Critical.
- Exchange and Public facing blog notifications will be sent to the person on call channel, but only if the severity is Critical and it is outside working hours.
- FTP server notifications are ignored only if it is outside working hours.
Benefits of Using Corticon.js
As you can see from the previous examples, the number of use cases and combinations can grow very quickly. Implementing all of these in code is complex and hard to maintain. A solution, implemented by one of our customers, is to use Corticon.js as a no-code rule engine to process events and alarms and to decide if these need to be sent to specific users.
There are multiple benefits to using a rule system like Corticon.js:
- Rules are not hardcoded in the main application code. This avoids hard-to-create and maintain code on the backend. More importantly, it results in faster time to market as the rules in Corticon.js were implemented by the business people, freeing up developers' precious time on the main monitoring application.
- The rules can be tested directly in Corticon; this improved productivity as it resulted in a very smooth integration between the rules decision service and the backend.
- Corticon.js is a cloud native solution; the customer was able to integrate the decisioning process very quickly, as it fit into their existing model.
- Improved agility, as it is very easy to maintain and extend rules for additional use cases. For example, the customer is looking into adding additional rules to decide which communication channel (email, text, etc.) to use based on the time and criticality of the events.
- No code maintenance: Changes to the rules and adding additional rules is done entirely in Corticon. They are achieved with a simple deployment of the new decision service, which is fully automated via a CI/CD pipeline. The important point is that new use cases can be implemented with no code changes to the backend.
- It was easy for the customer to run Corticon decision services as micro-services as the support for Node.js, and Serverless functions allowed them to run in containers using the existing customer’s infrastructure and eco-system.
In Conclusion
For this customer, using a rule system like Corticon.js has paid large dividends, as they can get to market more quickly confident in their ability to easily maintain and extend the system.
Find out here how Corticon as a no-code/low-code environment can help increase your productivity and deliver your solutions faster.
And you can enroll in a free training for Corticon.js here.
Enroll in a free Corticon Training
Continue reading...