Git Product home page Git Product logo

grofer's Introduction

grofer

Go Checks License Check Go Report Card Go Reference Publish Development Docker Image Publish Stable Docker Image Mentioned in Awesome Go

Latest Stable Version: GitHub tag (latest SemVer)

A clean and modern system and resource monitor written purely in golang using termui and gopsutil!

Currently compatible with Linux only.

Installation

Using go get:

go get -u github.com/pesos/grofer

As an executable:

curl -sSL https://github.com/pesos/grofer/releases/download/<version tag>/grofer_<architecture> --output grofer
chmod +x grofer

architecture: underlying system architecture on which grofer will be run

  • grofer_386
  • grofer_amd64
  • grofer_arm
  • grofer_arm64

For system wide usage, install grofer to a location on $PATH, e.g. /usr/local/bin

mv grofer /usr/local/bin

Building from source:

git clone https://github.com/pesos/grofer
cd grofer
go build grofer.go

Docker

  1. Get docker image using

      docker pull ghcr.io/pesos/grofer
    

    Note: This will use the latest image which is built from the stable branch.

    For previous releases, you will need to use the version number as the tag. Example: docker pull ghcr.io/pesos/grofer:v1.2.0

    For the latest image from the main branch (development image). The tag main can be used. Example: docker pull ghcr.io/pesos/grofer:main

  2. Run using

         docker run \
          --name grofer \
          --rm -it \
          -v /:/host:ro \
          -v /var/run/docker.sock:/var/run/docker.sock:ro \
          --privileged \
          --pid=host \
          --network=host \
          ghcr.io/pesos/grofer

    Additional subcommands and flags to grofer can be passed directly at the end of the above command:

         docker run \
          --name grofer \
          --rm -it \
          -v /:/host:ro \
          -v /var/run/docker.sock:/var/run/docker.sock:ro \
          --privileged \
          --pid=host \
          --network=host \
          ghcr.io/pesos/grofer proc
         docker run \
          --name grofer \
          --rm -it \
          -v /:/host:ro \
          -v /var/run/docker.sock:/var/run/docker.sock:ro \
          --privileged \
          --pid=host \
          --network=host \
          ghcr.io/pesos/grofer --help
  3. (Optional) create an alias for docker run to be able to run it using just grofer

         alias grofer="docker run \
          --name grofer \
          --rm -it \
          -v /:/host:ro \
          -v /var/run/docker.sock:/var/run/docker.sock:ro \
          --privileged \
          --pid=host \
          --network=host \
          ghcr.io/pesos/grofer"

    Then use grofer as normal:

         grofer --help
         grofer proc

    Container metrics also work inside docker:

         grofer container

Building Docker image

docker build -t ghcr.io/pesos/grofer .

Usage

grofer is a system and resource monitor written in golang.

While using a TUI based command, press ? to get information about key bindings (if any) for that command.

Usage:
  grofer [flags]
  grofer [command]

Available Commands:
  about       about is a command that gives information about the project in a cute way
  completion  Generate completion script
  container   container command is used to get information related to docker containers
  export      Used to export profiled data.
  help        Help about any command
  proc        proc command is used to get per-process information

Flags:
      --config string   config file (default is $HOME/.grofer.yaml)
  -c, --cpuinfo         Info about the CPU Load over all CPUs
  -h, --help            help for grofer
  -r, --refresh uint    Overall stats UI refreshes rate in milliseconds greater than 1000 (default 1000)

Use "grofer [command] --help" for more information about a command.

Display Overall Metrics

grofer [FLAGS]

The command displays the default root page which provides overall CPU, Memory, Network and Disk Metrics.

Optional flags:

  • -c | --cpuinfo: Enabling this flag provides detailed information about CPU loads.

  • -h | --help: Provides help information about grofer.

  • -r | --refresh UINT: Sets the UI refresh rate in milliseconds. The number (UINT) provided must be greater than 1000

Display Process Metrics

grofer proc [FLAGS]

This command displays a table with information about all running processes. Additionally, it can be used to kill a running process too. Key-bindings for navigation and available process actions can be found by pressing ? in the UI.

Optional flags:

  • -h | --help: Provides help details for grofer proc.

  • -p | --pid INT32: Provides in depth metrics about process identified by given PID.

  • -r | --refresh UINT: Sets the UI refresh rate in milliseconds. Much like the root command, this value must be greater than 1000.

Display Container Metrics

grofer container [FLAGS]

This command displays information about all existing containers. Key-bindings for navigation and available container actions can be found by pressing ? in the UI.

Optional flags:

  • -h | --help: Provides help details for grofer container.

  • -c | --container-id STRING: Provides in depth metrics about the container identified by given ID.

  • -r | --refresh UINT: Sets the UI refresh rate in milliseconds. Much like the root command, this value must be greater than 1000.

Export Metrics

grofer export [FLAGS]

This command exports collected information to a specifc file format.

Optional flags:

  • -h | --help: Provides help details for grofer export.

  • -i | --iter UINT32: Set the number of iterations to fetch data.

  • -p | --pid INT32: Specify the PID of the process to profile. If not set, all processes are are measured.

  • -t | --type STRING: Specify the export file format. Defaults to LJSON.

  • -f | --filename STRING: Specify the file to store the exported data in. Defaults to grofer_profile.

  • -r | --refresh UINT: Specify frequency of data fetch in milliseconds. default value taken as 1000.

Examples

grofer

grofer

Information provided:

  • CPU utilization per core
  • Memory (RAM) usage
  • Network usage
  • Disk storage

grofer --cpuinfo

The -c, --cpuinfo flag displays finer details about the CPU load such as percentage of the time spent servicing software interrupts, hardware interrupts, etc.

grofer-cpu

Information provided:

  • Usr : % of time spent executing user level applications.
  • Sys : % of time spent executing kernel level processes.
  • Irq : % of time spent servicing hardware interrupts.
  • Idle : % of time CPU was idle.
  • Nice : % of time spent by CPU executing user level processes with a nice priority.
  • Iowait: % of time spent by CPU waiting for an outstanding disk I/O.
  • Soft : % of time spent by the CPU servicing software interrupts.
  • Steal : % of time spent in involuntary waiting by logical CPUs.

grofer proc

This lists all running processes and relevant information.

grofer-proc


grofer proc -p PID

This gives information specific to a process, specified by a valid PID.

Passing a PID of 0 will list all the processes instead (same as grofer proc).

grofer-proc-pid

Information provided:

  • CPU utilization %

  • Memory utilization %

  • Child processes

  • Number of voluntary and involuntary context switches

  • Memory usage (RSS, Data, Stack, Swap)


grofer container

This provides overall container metrics.

grofer-container


grofer container -c CID

This provides per container metrics.

grofer-container-cid

Information provided:

  • CPU and Per CPU utilization %

  • Memory utilization %

  • Container processes

  • Volume Mounts

  • Attached Networks

  • Block and Network I/O

  • Metadata (Image, Name, ID, Status, State, PID)


grofer export -i 1 -p 1

This allows exporting of profiled data either of system usage or data particular to that of a process. Data format is JSON by default.

grofer-export


Shell Completions

grofer includes a subcommand to generate shell completion scripts to get autocompletion for subcommands and flags

Bash

To get completions for current session only,

source <(grofer completion bash)

To load completions for each session, the generated script must be moved to the completions directory. Take a look at the third question here to find out the right place to put the script

Zsh

If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once:

echo "autoload -U compinit; compinit" >> ~/.zshrc

To load completions for each session, the generated script must be placed in a directory in your fpath. For a quick-and-dirty solution, run once:

grofer completion zsh > "${fpath[1]}/_grofer"

You will need to start a new shell for this setup to take effect.

Fish

To get completions for current session only,

grofer completion fish | source

To load completions for each session, the generated script must be moved to the completions directory

grofer completion fish > ~/.config/fish/completions/grofer.fish

Credits

grofer's People

Contributors

7wik-pk avatar abhinav-chd avatar anihm136 avatar anirudhrowjee avatar ataboo avatar egawata avatar gituser143 avatar localleon avatar madhavjivrajani avatar mattharwood avatar metonymic-smokey avatar mihirkestur avatar nsankethreddy avatar panzerox123 avatar prncvrm avatar samyak2 avatar siddhant94 avatar siddhantrao23 avatar souvikmaji avatar temanisparsh avatar tfidfwastaken avatar tzzed avatar yogendra0sharma avatar yongruilin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

grofer's Issues

Optimize data fetch from gopsutil

Currently functions in generalStats.go just format and send data to the UI (PrintCPURates(), PrintMemRates(), PrintDiskRates()). Although they run concurrently, the data fed to these functions are fetched sequentially.

This can be made better by getting the data from within these functions itself and adding subsequent sleeps after all functions are called.

To then limit rate of influx of data into the UI, we can add small delays between subsequent data fetches using time.Sleep().

[FEATURE REQ] Add keybinding to kill processes

Generally I use a system profiler to monitor processes taking up large amounts of system resources, which I would usually need to kill. Having a keybinding to kill a process from the proc page would be very helpful in this regard

Describe the solution you'd like
A simple single key keybinding to kill a highlighted process from within the proc page

Describe alternatives you've considered if any
None

[FEATURE REQ] add monitoring of system resources given docker container id

Is your feature request related to a problem? Please describe.
Given that functionality for resource monitoring is provided on a per-process basis, I think it'd be super cool to have this feature for Docker containers as well.

Describe the solution you'd like
grofer docker --cid cid
grofer export --cid cid

Proposed solution
Gopsutil provides good support for getting info about containers.

Beyond this, the extended proc functionality of gopsutil can be used by obtaining the PID from the container ID by running something like docker inspect -f '{{.State.Pid}}' <Container ID>

Additional context
Need to see if information for all the currently provided widgets is obtainable.

[REFACTOR] Small changes needed to increase code readability and maintainability.

Small amounts of refactoring can be done to all files under cmd which have additional flags.

Creating const types for default values of flags.

  • Each flag in cobra needs to have a default value set. As of now the default value in some cases is mentioned while creating the flag such as

    procCmd.Flags().Int32P("pid", "p", -1, "specify pid of process")

  • For increased readability and also maintainability, it would be better to have a const of these default values like this:

const (
	DefaultProcRefreshRate = 3000
)

Splitting flag initialization to multiple lines

A flag initialization such as:

procCmd.Flags().Int32P("refresh", "r", DefaultProcRefreshRate, "Process information UI refreshes rate in milliseconds greater than 1000")

could be re-written to:

procCmd.Flags().Int32P(
    "refresh",
    "r",
    DefaultProcRefreshRate,
    "Process information UI refreshes rate in milliseconds greater than 1000",
)

[BUG] Increased refresh rate time due to data fetch and serve delays.

Describe the bug
Currently although UI is refreshed at given refresh rate, data being fetched and sent to UI is slower. Functions that serve the data take time to fetch data and then sleep for the given refresh rate. This causes a visible delay in the UI.

To Reproduce
Steps to reproduce the behavior:

  1. build grofer go build grofer.go
  2. run ./grofer -r 1000
  3. Notice fields being updated in intervals much larger than 1 second.

Expected behavior
The functions serving data should consume a total of "refresh rate" amount of time to fetch, send data and sleep (1 cycle). This could be fixed by checking time consumed in fetching and serving data, and then reducing sleep time accordingly.

Desktop (please complete the following information):

  • OS: Ubuntu 18.04
  • Go Version 1.14.2

[FEATURE REQ] provide functionality for user defined refresh rates

Is your feature request related to a problem? Please describe.
Currently, the UI refreshes at a default, hard-coded rate of 100 ms. A user-defined refresh rate would be beneficial.

Describe the solution you'd like
Add a persistent flag to the root command in cmd/root.go called -r or --refresh in long-form with a default value of 100 (ms).

Additional context
All commands created using the cobra cli tool are by default children of the root command, by setting a persistent flag on root, it will allow grofer to use the same flag for all child commands as well and a similar syntax for refresh rate can be used for all commands defined.

For more information, refer to this link.

Ex:

grofer proc -r 10
grofer -r 1000
grofer proc -p PID -r 1000

[BUG] allignment in list of child processes in `grofer proc -p PID` is not consistent.

Describe the bug
The alignment in the table for the list of child processes of a process is not consistent. I'm assuming this is happening due to the varying lengths of PID.

To Reproduce
Steps to reproduce the behavior:
Run grofer proc -p 1 and hit the key a few times.

Expected behavior
Alignment remains consistent irrespective of the length of the PID.

Screenshots
Screenshot_20200819_231213

Desktop (please complete the following information):

  • OS: Kubuntu 20.04
  • Go Version: 1.14.7
  • Terminal: Konsole

Additional context
Should be fixable by looking at the code in the getChildProcs function in the file src/display/process/procGraphs.go

[BUG] Incorrect timestamps

Describe the bug
Timestamp in grofer proc are incorrect!

To Reproduce
Steps to reproduce the behavior:

  1. Run grofer proc

Expected behavior
Timestamps of when the process was actually created.

Screenshots
image

Desktop (please complete the following information):

  • OS: Ubuntu 18.04
  • Go Version: 1.16

Migrate to termdash for ui

In response to #30 migration to termdash has to be taken up.

To work on this issue:

  • Development related to migration to termdash will be done on the migrate branch only.
  • While sending in a PR for the same, instead of "Fixes #Issue", mention "Part of #Issue" and reference this issue.

TODO:

  • Overall visuals, displayed by the command grofer
  • Per proc visuals, displayed by the command grofer proc -p PID
  • Info about all procs, displayed by the command grofer proc

Make overall stats into a struct type

For cleaner and more maintainable code, would it be possible to make all the stats being rendered by the grofer command into a single struct type so that a new channel does not have to be created for every new type of metric being displayed? Only two channels can be passed to the RenderCharts function, endChannel and dataChannel and all functions that update these metrics could be part of a struct method. So it could look something like this:

// Metrics struct comment
type Metrics struct {
	memInfo  []float64
	diskInfo [][]string
	cpuInfo  []float64
	netInfo  map[string][]float64
}

// Update function comment
func (m *Metrics) Update() {
     ...
}

[FEATURE REQ] provide a time period to run `export` command for

Is your feature request related to a problem? Please describe.
Along with providing an option for a number of iterations to run for at a specific refresh rate, it would be helpful to provide a total run time and a refresh rate at which this should happen.

Describe the solution you'd like
grofer export -t 120 -r 500
Total time period -t can be added as a non-persistent flag and units would be in seconds.

If the -t flag is used then the parameter for iteration should be explicitly calculated using total time and refresh rate.

This is done with the assumption that data fetch is almost instantaneous in nature which is a non-realistic yet reasonable assumption to make imo.

To be worked on after #34

Development for export feature is being done on the export branch (link)

[BUG] error handling needs to be done correctly

Describe the bug
Currently, all errors that might occur are being returned up the function call stack with the intention of being returned to the files in the cmd directory. cobra provides functionality for handling errors by providing Run or RunE in the cmdNameCmd struct which allows you to return an error to cobra and it tries and handles it.

With the current concurrency model of grofer, the functions for retrieving data and rendering data are put in go-routines because of why "returning" an error to that function is rendered pointless.

Proposal:
Have a channel of type error which blocks waiting for an event to occur, on a successful run, nil could be passed to the channel in which case the program can exit, whereas, on the occurrence of an error, the error can be taken out of the channel and handled or returned to another function if need be for handling.

To Reproduce
Steps to reproduce the behavior:

  1. Go to src/general/cpuInfo.go
  2. Change "mpstat" to "baby-shark-dodododo" (hopefully not a valid command although that would be awesome) on line 52
  3. Execute: go run grofer.go --cpuinfo
  4. Everything renders fine.

Expected behavior
Error messages must be displayed.

Desktop (please complete the following information):

  • OS: Kubuntu 20.04
  • Go Version: 1.14.7

Additional context
Since such errors aren't handled, the kill signal does not execute properly on pressing the q key which is meant to exit the program. There is an error that's occurred but that goroutine cannot handle it which is why the kill signal works in the rendering part but does not work correctly in the data serving part and it blocks there and the services of ctrl + c need to be employed.

-c flag throws error

Describe the bug
mpstat binary not installed by default.
-c flag throws error "Error: exec: "mpstat": executable file not found in $PATH"

To Reproduce
Steps to reproduce the behavior:

  1. Open terminal (shell used: zsh 5.8)
  2. Command: grofer -c
  3. See error: "Error: exec: "mpstat": executable file not found in $PATH"

Expected behavior
Show Info about the CPU Load over all CPUs

Desktop:

  • OS: Ubuntu 20.10 x86_64
  • Go Version: 1.14.7

[FEATURE REQ] Add functionality to export data to JSON/CSV.

Is your feature request related to a problem? Please describe.
As of now we only display stats through the UI, exporting these to a file in the format of JSON, CSV, etc., will be extremely useful.

Describe the solution you'd like
A functionality where running grofer export [ --type=JSON ] [ --iter=100 ] [ --interval=500 ] FILE would export stats over a specified number of iterations over given intervals into a specific file format.

Add automated testing

Describe the bug
The lack of automated tests is a big deal, given that we are going to have a lot more external contributions. We need to add a good amount of tests that cover most of the code and also add a GitHub Actions workflow that runs those tests every time a PR is made, so that we do not have to worry about new commits breaking existing functionality. Passing tests should be a minimum requirement to merge a PR.

Moreover it should be a requirement that new functionality must also include tests for the same, wherever feasible.

I do not yet know about the testing facilities in Go, but I can help with setting up the CI workflow, once we get some tests added.

Major memory leak: `grofer proc -p` on processes having RSS value of zero

Describe the bug
Running grofer proc -p <pid> on any process that has RSS zero (usually all kernel processes seem to have RSS zero, along with stuff like some zombie processes) will cause a memory leak, which will rapidly fill up memory and freeze your device.

To Reproduce
Steps to reproduce the behavior:

  1. Run top
  2. Identify the PID of any process having RSS as 0
  3. Run grofer proc -p <PID>
  4. Watch your device die before your very eyes

Expected behavior
Display the stats without ideally dying.

Desktop (please complete the following information):

  • OS: Kubuntu 18.04
  • Go Version: 1.14.6

[DOC] document using `grofer export` format

  • The format in which metrics are exported by grofer export resembles the ndjson format.
    • This is done for ease of appending json objects to a file without having to buffer large json strings in memory.
    • It also makes it easier to read the file in efficient ways such as by maybe lazy loading using generators in python.
  • It'd be helpful to have this mentioned in greater detail in the README and also maybe have a few examples that make use of these metrics that are exported as ndjson showing how such files can be worked with.

Getting metrics

grofer export -p <valid PID> -f export.json

[BUG] Resizing issue with the Memory graphs

Describe the bug
The Graphs under the memory section don't resize along with the window size

To Reproduce
Steps to reproduce the behavior:

  1. Run ./grofre
  2. Resize the window

Expected behavior
To be able to see the graphs and the different memory elements' values even on a smaller window

Screenshots
Screenshot from 2020-09-25 10-31-53
Screenshot from 2020-09-25 10-31-59

Desktop (please complete the following information):

  • OS: Ununtu 20.04
  • Go Version: 1.14.1

[BUG] `grofer about` is heart broken

Describe the bug
The ♥ in the grofer about does not display fully.

To Reproduce
Run grofer about

Screenshots
Screenshot_20200812_231622

Expected behavior
Screenshot_20200812_231849

Desktop (please complete the following information):

  • OS: kubuntu 20.04
  • Terminal: konsole
  • Go Version 1.14.7

Additional context
halp

[FEATURE REQ] need more cute ascii art error messages for invalid PIDs

Is your feature request related to a problem? Please describe.
For the command grofer proc -p PID, if the PID is invalid, a doggo error message is displayed which lives in src/utils/doggo.go.

        pid no exist, done doggo a sad 
                \
                 \
                /^-----^\
                V  o o  V
                 |  Y  |
                  \ ⌓ /
                  / - \
                  |    \
                  |     \     )
                  || (___\====

Describe the solution you'd like
If more ascii art can be added, every time there's an error, a new error message can be displayed by choosing a random number between 0 and n, n being the number of ascii art messages we have!

Grofer not supported on MacOS and Windows

Describe the bug
The individual process stats feature of grofer does not work on MacOS.

To Reproduce
Steps to reproduce the behaviour:
Run ./grofer proc -p <pid> as usual on a system running MacOS/Windows.

Expected Behaviour
Grofer should display process stats for the given PID like in Linux.

Actual Behaviour
On MacOS:
A runtime error with a segmentation violation.
The prompt in Terminal also does not function as usual after this,

Desktop (please complete the following information):

  • MacOS/Windows
  • Go Version 1.14

[FEATURE REQ] in-terminal dashboard for load/stress testing

Is your feature request related to a problem? Please describe.
It would be super cool and helpful if grofer could provide an in-terminal real-time display of different metrics evaluated during load/stress testing.

Describe the solution you'd like
Using some load-testing tool like vegeta the output generated using the tool can be piped to grofer, something like:
vegeta ... | grofer api, not too sure, would love to discuss specifics and feasibility.

Library Migration

Is your request related to a problem? Please describe.
Running grofer on certain terminal dimensions causes the Network and Memory graphs to go past the widget borders. This is most likely a bug in termui, which is no longer maintained.

Describe the solution you'd like
Migrating to another library like termdash would be one possible solution, which has cleaner looking widgets and could prove to be better for future applications. Further discussion on compatibility and ease of migration is required. A new branch could be created for this migration.

Screenshots
issues

Desktop (please complete the following information):

  • OS: Kubuntu 18.04
  • Terminal: konsole 17.12.3
  • Go: 1.14.6

[BUG] High exit time

Describe the bug

grofer or grofer proc takes a few seconds to exit to the shell prompt after pressing q or ctrl-c.

The time taken to exit increases as the refresh time is increased.

To Reproduce

Steps to reproduce the behavior:

  1. Run ./grofer -r 10000 in a terminal
  2. Exit grofer using q or ctrl-c
  3. Notice time taken for the shell prompt to reappear

Expected behavior

The process should exit immediately after q or ctrl-c is pressed.

Screenshots

image

Desktop (please complete the following information):

  • OS: Fedora 32 KDE
  • Go Version: v1.14.9

Additional context

This comment in #54

Require more Go Tests for CI testing

As of now the Travis tests are just to check if go build grofer.go succeeds and the code is formatted properly. We need go test files so that we can run some go test commands on Travis.

Remove duplicate/ugly error messages

Describe the bug
Everytime an invalid input is given the error message shows up twice.
Examples:

$ grofer invalid_command
Error: unknown command "invalid_command" for "grofer"
Run 'grofer --help' for usage.
unknown command "invalid_command" for "grofer"        # error message shows up again 


$  grofer proc -p 0

        pid no exist, done doggo a sad 
                \
                 \
                /^-----^\
                V  o o  V
                 |  Y  |
                  \ ⌓ /
                  / - \
                  |    \
                  |     \     )
                  || (___\====

Error: invalid pid
Usage:
  grofer proc [flags]

Aliases:
  proc, process, processess

Flags:
  -h, --help        help for proc
  -p, --pid int32   specify pid of process (default -1)

Global Flags:
      --config string   config file (default is $HOME/.grofer.yaml)

invalid pid                                   # error message shows up again

This seems to occur with every invalid input.

Moreover giving an argument of the wrong type will give an ugly error message, that is not meaningful to the user:

$ grofer proc -p notpid
Error: invalid argument "notpid" for "-p, --pid" flag: strconv.ParseInt: parsing "notpid": invalid syntax
Usage:
  grofer proc [flags]

Aliases:
  proc, process, processess

Flags:
  -h, --help        help for proc
  -p, --pid int32   specify pid of process (default -1)

Global Flags:
      --config string   config file (default is $HOME/.grofer.yaml)

invalid argument "notpid" for "-p, --pid" flag: strconv.ParseInt: parsing "notpid": invalid syntax       # error message shows up again and the message is ugly

To Reproduce
Steps to reproduce the behavior:

  • Give any input that is invalid
  • Give a string for the PID flag field

Expected behavior
Clean, unduplicated error messages

Desktop (please complete the following information):

  • OS: Ubuntu 18.04
  • Go Version: 1.14.6

[FEATURE REQ] add flags to the `export` command

Is your feature request related to a problem? Please describe.
Flags for refresh (refresh rate), iterations and type should be added to export command.

Describe the solution you'd like
In cmd/export.go non-persistent flags for refresh, iterations and type should be added and used similar to how refresh rate and pid flags are added to cmd/proc.go.

[FEATURE REQ] package name `graphs` is not accurate

Is your feature request related to a problem? Please describe.
The package graphs is inaccurately named since the info being displayed by the tool contains tables, lists, text, etc.

Describe the solution you'd like
Rename the directory src/graphs/... to src/display/...

PR deliverables:

  • rename directory to a more appropriate name
  • change import paths wherever necessary

[Enhancement] add cleaner and more efficient error handling

Currenltly, error handling is done in the usual pattern of

err := something()
if err != nil {
    return err // propagate err up the function call chain
}

However, this might not be the most robust and efficient way to do this as mentioned in this super interesting talk.

The main take away from this are that the current versions of Go pass return values around in memory rather than in registers as done by languages like C++. An excellent reference for the same can be found here. Therefore, doing error handling in the above mentioned form may not prove to be as efficient as one might like.

Some discussion might be required in terms of what approaches to use and if we should introduce external dependencies to handle the same, before proceeding with this issue in. Discussion can take place on the Discussions tab.

[BUG] High CPU utilisation

Describe the bug

grofer proc takes anywhere between 40-60% of a CPU core (measured using grofer proc -p $(pidof grofer) ). Looking through htop, the usage seems even higher, there are multiple grofer proc processes (5+) with two of them taking 60+10% CPU.

grofer uses 15-20% of a CPU core (again, measured through grofer proc -p $(pidof grofer) ). htop reports the CPU usage to be 25%+.

To Reproduce

Steps to reproduce the behavior:

  1. Open grofer proc in one terminal
  2. In another terminal, do grofer proc -p $(pidof grofer)
  3. Notice high CPU usage

Expected behavior

The profiler itself should not consume too much CPU power. Ideally, less than 5% seems good.

Screenshots

CPU usage as seen through grofer
CPU usage seen through htop

Desktop (please complete the following information):

  • OS: Fedora 32
  • Go: 1.14.6

Additional context

Could be solved by reducing the delay/interval to be around 1s.

[FEATURE REQ] Implement a menu of signal type options for killing a process

Is your feature request related to a problem? Please describe.
Currently, the functionality for killing a process is based on sending a SIGKILL to the process. Instead of always sending a SIGKILL, it might be better to provide the user with a list of signal types that can be used to terminate the process, eg: SIGTERM, SIGSTOP, etc.

Describe the solution you'd like
gopsutil provides support for 4 different types of signals that can be sent to a process. Support for signals other than the available ones can also optionally be added. A new menu can be displayed when the keys for "killing" a process are pressed, this menu can display the signal options as a termui list. Based on the selected option, that particular signal should be sent.

Additional context
Run htop and press F9 to kill a process, a menu of signal options is provided to choose from.

[FEATURE REQ] Add Dockerfile for `grofer`

Describe the solution you'd like
Have a Dockerfile for grofer for ease of use.

docker run pesos/grofer:latest

Additional context

  • On initial thought, this can be done by mounting the file systems being used by gopsutil to fetch metrics, /proc and /sys might be a good starting point.

[BUG] incorrect pid validation in `proc` command

Describe the bug
grofer proc -p [PID] should give an error when an invalid PID is entered (negative values and some cases 0 as well as 0 might indicate the sched or the swapper process), if a PID equal to the defaultProcPid is entered, it runs the grofer proc command which shows info about all processes.

To Reproduce
grofer proc -p -1

Expected behavior
The error shows for PID 0 and other negative numbers other than -1 should be shown for PID = -1 as well.

Desktop (please complete the following information):

  • OS: Kubuntu 20.04
  • Go Version 1.14.7

Additional context
Looking at cmd/proc.go should help!

Add directions to all the channels in the function signatures taking channel

Description
In many functions, for example the two shown below, the channel data only flows in one direction.

func GlobalStats(endChannel chan os.Signal, memChannel chan []float64, cpuChannel chan []float64, diskChannel chan [][]string, netChannel chan map[string][]float64, wg *sync.WaitGroup) {

func RenderCharts(endChannel chan os.Signal, memChannel chan []float64, cpuChannel chan []float64, diskChannel chan [][]string, netChannel chan map[string][]float64, wg *sync.WaitGroup) {

For example, in GlobalStats , endChannel only has its data flowing out of the channel (ie <-endChannel) and the other channels only receive data (ie cpuChannel <-).

Since the data only flows into one channel, we can make the types stricter in the function definition by having the channel direction specified, thus increasing type safety of the program.

Reference for how to do this: https://gobyexample.com/channel-directions

Deliverable in the PR

  • Identify all the functions where the channels only need to flow in a single direction
  • Specify the directions of the channels in the function signature
  • Make sure the program passes all tests (which have not been implemented yet, so for the time being ensure the program still runs correctly before submitting your PR)

This issue is for first-timers-only, that is, we are only going to accept your PR if you have never made a code contribution before.

[FEATURE REQ] structure of data that needs to be exported as a JSON or CSV

The format in which data needs to be exported needs to be discussed and decided upon. For instance, for overall/general information about the system being exported as a JSON, how will it be exported and to what level should the JSON be nested?

{
   cpu: {
        0 : %
        1: %
        ...
   },
   mem: {...}
}

or

{
    cpu: [...],
    mem: [...],
}

^ just an example of what needs to be discussed and decided upon!

[FEATURE REQ] Tab completion for grofer.

Is your feature request related to a problem? Please describe.
The grofer command would be easier to use with tab completion!

Describe the solution you'd like
As we're implementing cobra to parse command line options and arguments, we could enhance it with tab auto completions as cobra supports this for major shells.

Support for CPUs with multiple cores

Currently, the CPU usage grid displays the utilization in percentage for each individual logical core but is restricted to dual and quad core processors (with 4 and 8 logical cores assuming that HT is enabled).

A possible solution is to create an array with termui.NewRow objects whose width percentages are adjusted according to numCores. Unpacking this within the respective column in mainPage.Grid.Set should get the job done in theory since it supports variadic parameters.

[FEATURE REQ] provide support for different signal types

Is your feature request related to a problem? Please describe.
gopsutil provides support for 4 different types of signals that can be sent to a process, signals other than these 4 need to be implemented such as SIGABRT. A list of signals can be obtained by running kill -l

Describe the solution you'd like
Maybe the implementation of sending signals could be done using the Signal() function.

[FEATURE REQ] add functionality for getting help for a particular command

Is your feature request related to a problem? Please describe.
When running a particular interactive command like grofer or grofer proc it would be nice to have a way to get something like a table of available key bindings and what they do for that command.

Describe the solution you'd like
Pressing a key like h should pause the UI rendering and display a table of the available key bindings for that command and what they do like to scroll, k to kill a process in the grofer proc command once #16 is done etc.

[ENHANCEMENT] change type of `refreshRate` and `pid` flag to unsigned int

  • In cmd/proc.go and cmd/root.go the type of the refreshRate flag is an int32.
  • In cmd/proc.go the type of PID is int32.

In both these cases, I feel like it would be better to keep the type to unsigned integers as the values can never be allowed to be negative.

  • int32 for refreshRate could be changed to uint64 to handle the case of an extremely large refresh rate since refresh rate is to be provided in milliseconds.
  • int32 of pid could be changed to unit32.
    • The default value of PID could be changed to 0.

To be solved after #64

[BUG] Lots of lag when scrolling through child processes in `grofer proc -p PID`

Describe the bug
Extreme lag when scrolling through list of child processes in grofer proc -p PID

To Reproduce
Steps to reproduce the behavior:

  1. Run grofer proc -p 1
  2. Press the down arrow a couple of time and notice the time lag.

Expected behavior
Scrolling without lag.

Desktop (please complete the following information):

  • OS: Ubuntu 18.04
  • Go Version 1.14.2

[FEATURE REQ] Add keybind to navigate to child process in grofer proc

Is your feature request related to a problem? Please describe.
While running grofer proc with a pid with say a few child processes, there is no way to navigate to a child process directly,
The only way to do that would be to note down the PID and run grofer proc with noted PID

Describe the solution you'd like
Some sort of keybinding (like Ctrl-Enter) to directly jump to that child process would be nice

Additional context
Suggestions on what keybind to use are appreciated

[FEATURE REQ] add stats not provided by the `gopsutil` library

Is your feature request related to a problem? Please describe.
The gopsutil library does not provide APIs for getting information about certain system parameters and metrics which might be important to know in certain cases such as the the scheduling policy of a process or information about software interrupts, hardware interrupts, etc as requested in #21

Describe the solution you'd like
For interrupt information /proc/interrupts would need to be parsed and /proc/PID/sched would need to be parsed for information such as the scheduling policy for the process.

This feature can be added as part of the export feature currently being worked upon.

The CPU data visualization is not rendered properly

The visualization of the CPU data is rendered out of the screen

To Reproduce
Steps to reproduce the behavior:
(I use a 2 core 4 CPU system)

  1. Go to ... /grofer/
  2. Build the grofer code go build grofer.go
  3. Execute the newly created executable ./grofer
  4. See error

Expected behavior
All the widgets to be rendered in the screen

Screenshots

Screenshot from 2020-08-04 17-45-04

Desktop (please complete the following information):

  • OS: Ubuntu 20.04
  • Go Version:version go1.14.4 linux/amd64

[FEATURE REQ] Add keybindings for sorting output for `grofer proc`

Is your feature request related to a problem? Please describe.
As @Gituser143 pointed out, it'd be nice to have sort functionality based on different columns of the grofer proc output.

Describe the solution you'd like
ctrl + 1 for sorting by first column of the output? And so on for the other columns.

Describe alternatives you've considered if any
shift was discussed, but termui does not have keybindings for that.

[REFACTOR] Rename the file printStats.go and the functions inside it to more meaningful names

Is your feature request related to a problem? Please describe.
The file printStats.go and the functions inside it such as PrintMemRates and PrintCPURates were named that way when development started and formats of outputs were being decided. It makes more sense to rename the file and the functions inside it to something more apt such as ServeMemRates, ServeCPURates etc.

If changed, the corresponding function calls in other source code files must also be changed accordingly 😄

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.