tadgh / shizuka

A Client/Server application for monitoring a network of computers.

Shizuka

A Client/Server application for monitoring a network of computers.

Features

1. Remotely monitor networked computer statistics such as CPU usage, RAM Usage, network throughput, and uptime.
2. Get Notified by E-mail when events are triggered(RAM/CPU Usage goes over a threshold).
3. Perform a limited set of commands on remote computers from the command page.
4. View on the go with the Mobile App.

shizuka's Issues

Allow client naming locally.

As opposed to simply using FQDN. Use FQDN by default, but allow for another name.

(webserver) Monitor types can be created by users(only HDD)

Use a CHOICES based on the client's available drive-list

Write CPU-Related Functions

Write Monitor Manager

Write a class that:

• Holds a list of Monitor Objects.
• Has Some Output Option
• Can Execute polling on all monitors
• Can Pause Monitors.

Complete Message receiving system celery task.

Have it classify messages by type, and perform some unique actions based on type.
e.g; Type = Monitor Report will pass the remaining part of the message to some function that deletes or adds monitors based on what is shown in the report.

Get full documentation coverage on client and server classes.

Write Network Saturation related Functions

Determine max bytes/sec for BytesSentMonitor and BytesReceivedMonitor.

Convert outgoing message and data spools(from server -> webserver) to use queues

Currently using lists. Queues allow them to be thread-safe. Any downsides to this?

Write RAM Related Functions

Change Monitor Instantiation to Factory-based using constants.

Type is now the monitor's Identifier:
i.e; RAM/HDD_C/HDD_D/HDD_SLASH_USERS/BytesReceived/BytesSent/Swap/CPU

Workflow:
Client receives message:
Monitor: {RAM add}
Client generates a new Ram monitor.

Client receives message:
Monitor: {RAM remove}
Client attempts to remove its ram Monitor

Client receives message:
Monitor: {HDD_C add}
Client attempts to add Storage monitor for HDD_C.

Client receives message:
Monitor: {HDD_D add}
Client attempts to add Storage monitor for HDD_C.

Client Discovery message needs to include a list of mount points and basic information about the client

IP
MAC
MOUNT_POINTS
HOST_NAME
CPU_COUNT
RAM_AMT
WIN/LINUX

change monitor reporting to use type as key

when reporting, use TYPE as the key, and [minimum, polled(), maximum] as the value.

Sample:
{
'client_id' : 'shizuka.client.Mulder'
'data': {
'RAM': [0, 12313, 355343],
'HDD_C': [0, 12313, 355343],
'HDD_D': [0, 12313, 355343],
'BYTESREC': [0, 12313, 355343],
}
}

Write Simple Server.

This first server iteration must:

• Automatically add any new clients that appear
• Poll data from any clients
• Print data to console.

Ideally a secondary thread handles polling all the clients.

Convert Notifier to a threaded class

Currently only a threaded method. Making it a threaded class gives control over stopping and restarting conditions in the thread.

Write Uptime related Functions

Have Client registered to the Pyro Nameserver.

Need to determine the best way to handle communications.

Should we have the server ask for a poll whenever it wants, or should the server register itself to the client, and whenever it polls itself, it calls some method on the server?

Write HDD/SSD related monitors, and a discovery manager.

Discovery manager will report how many drives are found on the computer. By default all drives will be monitored,

Get client to send a ready signal to the server once it is online.

The configuration of a client will be done web-server side.

Write a MessageHandler class

Class is responsible for:

Passing messages from client classes to the server class.

Modify Data notification to Queue system as well ?

@adambellemare watcha think?

Since the only time we are currently polling data is like this:

Notifier -> DataManager -> All monitors -> Data.

Should we change it to:
Datamanager Fills the data queue
Notifier Consumes the Data Queue