jakobhviid / monitoringservice-docker Goto Github PK

The database will eventually be filled up with less relevant data. This will depend on the sampling interval and the amount of containers. But there is limited use cases for having 1 minute precision of a containers CPU usage older than a year, month or even week.
The system should therefore aggregate the stats of some kind, such that it will take up less space at the cost of accuracy. This could involve aggregating the CPU usage for a whole day, when the data gets older than 1 week. There should probably be more aggregations, such that the older the data gets, the less time accurate it becomes.

It is unclear right now what aggregations is needed. However, it could be implemented with configureable intervals and precisions.

I'm uncertain of how this should be implemented. The user should not have to login twice, but there is two options:

• The user logs in on the SocketServer (as normal), and when the user requests data through the REST API, this service should ask the SocketServer whether the JWT-token is authorized. This would requrie a new REST API method in the SocketServer, which would confirm the validity of a JWT-token. The drawback is that each REST API call made to the Monitoring service would require another HTTP call to the SocketServer.
• The other option is to have the SocketServer return a token that is authorized to access the Monitoring REST API, and then the frontend would use this token to communicate with the Monitoring REST API. The drawback is the SocketServer would be responsible for authorizing the user in the Monitoring service and that the frontend would have to maintain two tokens.

A new issue with the responsibility moved from the Dashboard Interface: jakobhviid/Dashboard-Interface-Docker#4

The following use cases is currently considered:

• As a user I want to see "state" and "health" counts for a specific container for a given period of time for several containers at the same time (tabledata) *
• As a user I want to see percentage of "healthy" records for a specific container for a given period of time for several containers at the same time (tabledata) *
• As a user I want to see aggregations (average, min, max) of CpuUsage, NumOfCpu, SystemCpuUsage, MemoryPercentage, NetInputBytes, NetOutputBytes, DiskInputBytes, DiskOutputBytes for several containers at the same time (tabledata) *
• As a user I want to see latest status record for a specific container
• As a user I want to see latest stats record for a specific container
• As a user I want to see graphs of CpuUsage, NumOfCpu, SystemCpuUsage, MemoryPercentage, NetInputBytes, NetOutputBytes, DiskInputBytes, DiskOutputBytes for a given period of time (line chart) *
• As a user I want to see graphs of "state" and "health" changes over time for a specific container (line chart?) *

* use cases should contain total stats / status record count and average time between each record

The frontend components will of course be implemented seperately in the Dashboard Interface repository.

Analyzing historical data to derive more meaningful notifications, handling outliers etc.

Allowing the user to define their own notifications through a graphical user interface, letting notifications be generated for specific events, thresholds etc.

Allowing the user the option of having notifications sent to the through different channels, currently the following are considered:

• Text-message
• Email
• Push-notifications

Healthcheck is currently not working, because it is missing from the Dockerfile and the diagnostics has not been implemented in the application yet. The script is already in the "scripts" directory (copied from Dashboard-Interface repository), however, it has not been tested.

The monitoring service monitor status information to generate notifications for the user on the interface (https://github.com/jakobhviid/Dashboard-Interface-Docker).

Currently the following notifications are considered for a minimum viable product:

• CPU usage
• Memory usage
• Health status

Further notifications, custom notifications and more delivery methods for the notifications (email, sms etc.) are relegated to other issues: Issue 12, Issue 10 and https://github.com/jakobhviid/MonitoringService-Docker/issues/11