The central alert system which captures events generated by any system or user triggered, and raise an alert according to alert configuration
- problem statement is present under Alert Monitor
make local ## for local setup (db)
make all ## to start the server
docker logs alert-monitor -f ## for logs
- postman collection is present under
/docs/postman
- check logs through the cmd
docker logs alert-monitor -f
At a high level, the service operates as follows:
- Whenever a new event is received, the service evaluates the alert configuration associated with that event.
- If an alert condition is met, the service dispatches notifications to the relevant dispatchers asynchronously. This approach leverages goroutines, which are lightweight and efficient, allowing the system to handle a high volume of dispatches concurrently.
- For improved scalability, integrating a messaging queue is recommended. This setup allows the service to handle high burst loads by queuing incoming events.
- Additionally, using an OLAP database like ClickHouse can enhance performance. Unlike traditional relational databases, OLAP systems are optimized for high-speed aggregation queries, making them more suitable for quickly retrieving event counts and performing complex analyses and there isn't any usecase to maintain relational among the data
- To meet the project's requirements and constraints within a short timeframe, the current implementation uses a RESTful API with PostgreSQL. While this approach is straightforward and effective for the task at hand, future improvements could include adopting a messaging queue and OLAP database to handle larger scales and more complex scenarios efficiently.
Note: Here
internal_ext
directory is used instead ofinternal
asinternal
code will be hidden by github.