HowTo: Groupwise Agents monitoring (localscripts)

How-to Articles
1

Updated 26-11-2023

This is a How-To regarding GroupWise and monitoring its processes via Local checks.

This local script is still under development by me, both to flex my Bash scripting skills as well as getting more familiar to Local Checks.

General warning
With all my work, this is a proof-of-concept as to how to monitor specific products, and unless you are fully aware of what you are getting into while i am trying to get full monitoring on something it should NOT be used in a production environment.

Intro
The GroupWise system is a product from (now called) OpenText, providing an on-premise mail solution with its own postoffice, transfer-agents and internet gateway.
Even tho the (via buy-over) the name of the supplier changed the product itself has not changed that much, and imho is rock-solid, as to why i am still using it.

The works
GroupWise consists of several components/services which for obvious reasons should be monitored:

  • GroupWise AdminService ( adminservice)
  • GroupWise Mail Transfer Agent(s) ( gwmta)
  • Groupwise Post Office Agent(s) (gwpoa)
  • GroupWise Internet Agent(s) (gwia)

Additional when using Groupwise WebAccess things which should be monitored are :

  • GroupWise Webaccess Agent
  • GroupWise Document Viewer Agent (gwdva)

The current code:
As of current the script will successfully monitor, and report the status of a/the processes of:

  • AdminService PID
  • Mail Transfer Agent PID, process listeners
  • Post Office Agent PID, process listeners
  • Internet Agent PID, process listeners

As a process is either running or not, its quite simple, so a status of 0 (OK) is sent to CheckMK when its running, and a status of 2 (CRIT) when not running.

The Actual script as to what i have made so far is available on my own git server (instead of keep editing this post)

This script should be saved in the /usr/lib/check_mk_agent/local - folder, in my case i named it appropriately groupwise.sh, and made it executable with chmod +x groupwise.sh

The plan:
I am planning to create more depth in this, as to also be able to expose more details of a/the running processes, but this will take time, collaboration is always appreciated to speed up development.

  • Glowsome
1 Like
2

Groupwise was initially from novell, right?
25 years ago I installed it at various customers and it did a very good job.
I quite astonished that its still alive.

You check with pgrep if the process is running. Why you dont use the built in check ps? Process information are sent by agent built in and you can use rule “State and count of processes” to monitor it.

regards

Michael

2 Likes
3

Groupwise was Indeed originally from Novell.
… which then was bought over by Attachmate
… then Attachmate got bought by Micro Focus.
… and Finally Micro Focus was bought by OpenText :slight_smile:

I had thought about going via rules it, but i’m deploying with Ansible, and found it easyer to deploy localchecks to (only) the mailservers.

  • Glowsome
4

You dont need to deploy anything if you use “State and count of processes”. Its built in the agent.

In the agent output you have the section <<<ps>>> where you can lookup your processes and copy over to the rule.

2 Likes
5

Hi Mike,

I understand the suggestion(s), and most welcome if i were to limit only to checking of the process itself.
But i will be taking it a bit further as to checking if the process is actually listening, and even planning to retrieve data over the admin-service api.

Also see it as me flexing my bash-script skills :slight_smile:

  • Glowsome
6

Hi @mike1098,

I tried the ‘Native’ -way (checking if a process is present) but was unable to isolate this in a correct way.
Meaning hosts (specifically monitored over SNMP) started showing up with warnings about the specific process.

As said before i am trying to not only monitor the process itself, but also report/monitor (expected) listeners on ports.
I can ofc. create a bash script which will search/check ports for the default known ports, but i am after a dynamic discovery of listener -ports of the process (gwadminservice, gwmta, gwpoa)

  • Glowsome
7

To check a process with SNMP you need the rule ‘State and count of processes (only SNMP)’
But via SNMP you get only limited data and its highly recommended to use the checkmk agent which provide a rich set of metrics and levels for processes.
Too check if a socket is working you have two choices. Deploy agent plugin ‘Established TCP/UDP connections’ and use the rule ’ TCP connection statistics’ to monitor the socket inside of the server or use the rule ‘Check TCP port connection’ to connect via TCP form outside to the socket.

regards

Michael

8

Hi @mike1098,

Again thanks for the hints regarding the rules, but the issue with the GroupWise agents is:

  • beforehand i do not know which IP a/the agent is running on/bound to nor can expect listening ports from the process (from an agent-perspective).
    → It is best practices to assign a secondary IP and have all GroupWise-services configured on that IP so that when you need to move GroupWise and its agents to a new server its easyer to unlink the secondary ip, move all files, and link the secondary ip to the new server again.

With the Local checks (in order of what i am after):

  • Find out if a GroupWise process is running on a particular server.
  • Find out when a GroupWise process is running on what IP.
    → As stated above the/a process can be (exclusively) bound to an IP.
  • Find out if a/the particular GroupWise process is listening on a (or multiple) port(s).
    → As stated, there is a set of default ports , but can be changed by admin if that suits their environment/needs better.

So (next to my desire to flex my (bash-) scripting skills) i am trying to catch all possibilities to get a reliable result in CheckMK.

best regards,

  • Glowsome
9

Updated the original post, so my work so-far is no longer in the post itself, but via my own Git-Server.
This makes me more flexible instead of keep editing the starter post.

  • Glowsome