Blog

So you, the Plumtree / AquaLogic / WebCenter admin, get a call from a user indicating that Collab email notifications are not being sent (a plausible symptom that the Collab Notification service is in "stopped" status), or that Publisher is not responding (an indication that the Publisher service might also be down), alternatively Portal searches yielding no results (a sign that the search server is down) ... the issues that a Portal admin can encounter are just myriad.

Ideally, we shouldn't be notified from our users that an issue has occurred.  Granted there are a number of monitoring software in the market; e.g. Microsoft Operations Manager that monitors disk space, memory and CPU utilization, among other tasks, presenting the results in console like dashboards, yet we haven't seen a monitoring software dedicated to guarding a Portal deployment alerting its admin staff of potential issues.  Hence, the impetus for Watcher, a software monitoring tool dedicated to watch a Portal installation.

Watcher is created to run different types of monitors (currently 10 different rules) for a typical Portal install; these include:

1.      "Service" monitor to check if a particular daemon service has stopped and it attempts to restart it.

2.      "File Size" monitor to check if log files have reached a particular threshold size and ensure that the Portal admin is alerted if the size is within a predefined threshold.

3.      "Disk Size" monitor to check if a hard drive has reached a certain threshold size.

4.      "Directory Size" monitor to check the size of a folder.

5.      "File Text" monitor to check if a specific text string has occurred within a log file.  That can be useful to skim through a log file and search for a particular error string.

6.      "HTTP" monitor to check that the Portal URL is responsive and is returning a response within a given time threshold and that the HTTP request status code is 200 (OK).

7.      "

Ping" monitor to ping a given host and ensure that the host is reachable within a given time threshold.

8.      "TCP" monitor to telnet a given host and send a command and parse the response.

9.      "Database" monitor to send different SQL statements and validate the result again specific thresholds; e.g. number of records in the ptUsers table should not be less than an "x" number thus indicating that the Active Directory Web Service has successfully executed.

10.  "Search Server" ensuring that all search nodes are in "Run" state.

The Watcher architecture is comprised of three components:

1)      A lightweight agent deployed as a service with a low footprint in terms of CPU and memory utilization running different monitors that can are configured as needed; i.e. different types of rules.

2)      A server console that receives the monitoring results from the different agents via HTTP requests.

3)      A notification service that alerts the admin of issues if a particular issue or threshold is encountered.

Watcher is shipped with preconfigured rules that can be further tailored as needed.  It can also be configured to monitor non Portal related services, database instances, hosts, URLs, etc.

To receive further information or schedule a demo, please contact us at info@function1.com

Thanks.

Hani