gmemstr / platypus Goto Github PK

View Code? Open in Web Editor NEW

204.0 12.0 10.0 12.83 MB

Large-scale server monitoring application written in Golang

Home Page: https://status.gmem.ca

License: GNU General Public License v3.0

HTML 22.30% JavaScript 9.49% Go 68.21%

sysadmin server-stats scanning platypus websockets statistics uptime go golang

platypus's Introduction

Platypus

Simple realtime server monitoring

Dependencies

go get github.com/gorilla/mux
go get github.com/gorilla/websocket
go get github.com/go-yaml/yaml
go get github.com/shirou/gopsutil

Usage

Master server:

go build -o platypus main.go
chmod +x platypus
./platypus

Client servers:

go build -o platypus_client client/client.go
chmod +x platypus_client
nano config.yml
# Input your secret key and master server IP here, secret key found on master server in .secret
# master: example.com
# secret: s3cr3tk3y
# End config
./platypus_client

Navigate to your master server and check out the stats.

Rewrite

Rewriting this from the ground up. Why did I do this in Python.

The goal of the rewrite is to move away from using Python for the entire stack and instead break things up into smaller chunks, maybe moving this to it's own GitHub / Gitlab org, which will allow it to be much more modular and open ended when it comes to what kind of information you want to monitor and how.

Steps

Rewriting the core functionality, which is a basic stats dashboard and server management through an admin interface. We also want to rethink how to handle Active Online Reporting - websockets still seems like the best option for this but there's got to be a better way. Might opt for Go master server side as it's something I have experience in and should offer good performance etc.
Rebuild the client based on the specifications of #1, and deciding the best way to build and distribute the package w/ configuration - I personally want to go with something we can compile into a very small package and ship with a master server-generated configuration file of some sort. Was thinking C++ might be a good option over Go size wise but there could be additional time overhead.
Write a straightforward API both client (or "node") side, which would allow applications to construct and send custom messages to the master server, and master server side, which will handle said customer messages. This should be fairly straightforward once we have #1 and #2 complete.
A plugin system - I don't really know what form this would take since it's pretty far down the line, but it's something to consider. Some sort of simple scripting language that we can easily write an interpreter for in Go for the master server and would expose various variables / functions.

platypus's People

Contributors

Stargazers

Watchers

Forkers

manjufy apexcz habibtalib bellyfat zhiliangpersonal keevol ixuzhi jangocheng cloudxo darksidesfear

platypus's Issues

Configure which disk to monitor

Currently the default client only watches whatever disk is mounted at /, this should be added to the configuration file.

ModuleNotFoundError: No module named 'src.Config'

Above, the error when i trying install

C:>python setup.py
Traceback (most recent call last):
File "setup.py", line 2, in
from src.Config import Config
ModuleNotFoundError: No module named 'src.Config'

Better UX for first time client setup

SQL Database "Goes Away"

Thought I'd fixed this in commit 35bb828 but evidently not. MySQL server will sometimes "Go Away" (e.g times out).

Improve admin interface

Admin interface is really really basic and barebones, could use a bit of prettying up.

Obvious sign when frontend disconnects from websocket

Frontend API docs

Plugin System

High level

Implement a plugin system within Platypus to allow modification of behavior and data handling through the use of an internal plugin API, which also disallows exposure of secrets. This would primarily be on the master node side, as custom clients would be preferred rather than implementing the same plugin system into the client.

Possibilities

Configuration-based plugins
- Easier to implement code-wise
- Lower barrier of entry
- Could get complex fast
- Rigid, not as dynamic
Scripting-based plugins
- Harder to implement code-wise
  - Depends on final scripting language
- Much more flexible, deeper customization
- Higher barrier to entry as a trade off

Configuration-based

Configuration would come in the form of .yaml files which would be located within a plugins/plugin_name directory. Platypus would seek through these directories and load the plugin.yaml file, which can in turn reference other yaml files. These can define rules for how Platypus should behave or handle incoming data from clients. This would take some time to completely flesh out and sort of the syntax of.

No the ideal solution, but is an option if it can be fleshed out completely.

Scripting-based

This is the ideal solution, which would implement a language interpreter into Platypus for X scripting language, with some slight modifications to expose hooks/events allowing modification of data handling as it comes in from either the web clients or server clients.

The language would have to be interpreted, as I'm not entirely sure how implementation of a compiled language would work. Right now, the choice is between Lua and Python, however other options, or even a custom language, can be considered. These would likely have to couple with a .yaml file to expose some metadata for the plugin.