trey/psi-alerts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fleshed out both documents

Browse Source
This commit is contained in:
Trey Blancher 2023-08-24 10:00:32 -04:00
parent 0540fed30b
commit 68372af7d7
2 changed files with 51 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
CONFIGURE.md
View File

@ -25,6 +25,7 @@ Environment=EMAIL_TO="email@domain.tld"
Environment=SMS_DST="phone_number@sms.domain.tld"
Environment=NOTIFICATION_CMD="dunstify"
Environment=NOTIFICATION_OPTS="--timeout=0 --printid --urgency=critical --icon=/usr/share/icons/breeze-dark/emblems/16/emblem-warning.svg"
Environment=NOTIFICATION_HIST_CMD="dunstctl history"
Environment=NOTIFICATION_IDX=15
Environment=SSH_USER="username"
Environment=SSH_HOST="localhost"
@ -49,3 +50,40 @@ Environment=CLEAR_THRESHOLD="5.0"
# WantedBy=multi-user.target
```
All of these are required except where noted, there are no default options
(defaults may be added in the future). A brief description of each:
* **EMAIL_TO**: the email address the notification should be sent to. The
output of `pidstat` will be included in the body of this email, for each
triggered resource type (CPU, I/O, Memory), at the time the monitor alerted.
* **SMS_DST**: the email-to-SMS address, as defined by your mobile carrier.
Please review your mobile carrier's documentation. For Google Fi, based in
the US, the format is
`<mobile_number_without_country_code>@msg.fi.google.com`. This email address
does **not** get the output of `pidstat` in the body of the message.
* **NOTIFICATION_CMD**: The command on the remote host to run to display
notifications, e.g. `notify-send` or `dunstify`.
* **NOTIFICATION_OPTS**: Options for the `${NOTIFICATION_CMD}`. Should
include `--print-id` if supported by the command.
* **NOTIFICATION_HIST_CMD**: The command to display the notification history
(e.g. `dunst history`).
* **NOTIFICATION_IDX**: The index if the JSON structure that contains the
notification ID. `dunst`, as of version 1.9.2-1, displays its history as a
JSON structure. For other notification daemons, some other history mechanism
will likely be required; patches needed and welcome!
* **SSH_USER**: The SSH username to connect to the remote host that will
display the notifications to the system administrator.
* **SSH_HOST**: The SSH host to connect to. This is where
`${NOTIFICATION_CMD} ${NOTIFICATION_OPTS}` and `${NOTIFICATION_HIST_CMD}`
will run.
* **SSH_PORT**: The SSH port to connect to.
* **SSH_ID_PATH**: The path to the SSH id (private key file) to use for
authenticating to the remote host. This can be exluded if the local user
already has an ssh-agent running, with the necessary key and passphrase
entered. If ssh-agent is not desired, then this SSH id (private key file)
should have an empty passphrase (i.e., no passphrase). Not having this
environment variable, and no ssh-agent will disable the desktop notifications
(SMS and email will still work, as they don't use SSH)
* **CLEAR_THRESHOLD**: The percentage threshold the some avg300 threshold
should be below before considering the alert cleared. This will depend
highly on the workload running on

13
README.md
View File

@ -17,6 +17,18 @@ near real time.
* psi-by-example (a modified version of this is included in this project as a
submodule)
* a libnotify-compatible desktop notification system
* any notification program should use the `--print-id` parameter if
possible
* both `notify-send` and `dunstify` (part of
[dunst](https://dunst-project.org/)) support this
* note, this has only been tested with `dunst`, since it has the capability
of showing notification history
* `notify-send` specifically does not appear to retain a history, so the
`check_dunst_id_is_visible` function won't work with it (and the logic to
skip sending a new notification if one is already sent will be broken).
* since I don't use `notify-send`, I'm not sure how to solve this
* patches welcome!
* jq (for the aformentioned `dunst` integration)
## History
@ -98,6 +110,7 @@ below the configurable threshold for at least five minutes).
* consider reworking this for a user service, not a system service
* this could make desktop notifications simpler, and not having to use
SSH keys without passphrases
* possibly learn how to connect to an existing ssh-agent
* need to become much more familiar with user services
* consider reworking all code in a compiled language (other than C)
* time to learn Go