Skip to content

Watchdog 3.0 UserGuide

Watchdog Server User Guide

Overview

This guide explains how the watchdog server works in simple terms. It focuses on how the server checks a controller's license and provides the correct settings based on which department it belongs to. It also includes a new section on the key expiry feature and instructions on accessing the Grafana dashboard for data analytics.

Workflow

Step 1: Sending Information from the Controller

The controller gathers details about itself, such as:

  • Unique ID (GUID)
  • Hostname (name of the computer)
  • Version (software version)
  • IP addresses
  • MAC address (unique identifier for network interfaces)
  • Operating system (OS)
  • Label (a tag to identify the machine)

This information is sent to the /api/check-license/ endpoint on the watchdog server.

Step 2: Checking the License

The server receives the information and checks if the license is valid. It ensures all required details are present and that the GUID is formatted correctly. If everything checks out and the GUID is not already in use, it registers the GUID. If the number of active devices exceeds the allowed limit, the request is denied.

Step 3: Matching Information to Configuration Settings

The server reads the configuration and mapping files. It uses the details from the controller to find the best matching department based on criteria like label, IP address, hostname, MAC address, and operating system.

Step 4: Sending Configuration to the Controller

Once the right department is identified, the corresponding settings from the browsermon-watchdog.conf file are selected. These settings are customized based on the controller's operating system (e.g., setting the log directory path differently for Windows and Linux).

Step 5: Config is sent to Controller

The new config from browsermon-watchdog.conf is sent to the controller along with the valid license message.

Key Expiry Feature

Overview

The key expiry feature allows administrators to set an expiry date for the keys used by controllers. This ensures controllers must periodically check in with the watchdog server to renew their keys, enhancing security and control over access.

Workflow

Step 1: Generating and Assigning Keys

When a controller initially registers with the watchdog server or when a key expires, the server generates a new key with an associated expiry date. This key is then assigned to the controller.

Step 2: Checking Expiry

Each time the controller communicates with the watchdog server, the server checks the expiry date of the assigned key.

Step 3: Logging Remaining Days

Upon successful communication, the watchdog server logs the remaining days until the key expires. This information is logged for monitoring purposes.

Step 4: Key Expiry

Once the expiry date is reached, the key is considered expired. The controller will no longer be able to receive configurations or updates from the watchdog server until a new key is generated and assigned.

Implementation Details

Configuration

Administrators can configure the expiry duration for keys in the watchdog.conf file.

Logging

The remaining days until key expiry are logged in the watchdog server's log files. Administrators can monitor these logs to ensure timely renewal of keys.

Grafana Dashboard

The watchdog server integrates with Grafana to provide a comprehensive interface for viewing history and data analytics.

Accessing the Grafana Dashboard

Users can view the Grafana dashboard by navigating to http://localhost:1514 in their web browser. This dashboard presents the history and analytics data collected by the watchdog server in an intuitive and visual format.

Benefits of the Grafana Dashboard

  • Data Visualization: The Grafana dashboard offers various charts, graphs, and tables to help users visualize historical data and trends.
  • Customizable Views: Users can customize the dashboard to display the most relevant metrics and information for their needs.
  • Real-Time Monitoring: The dashboard allows for real-time monitoring of data, providing up-to-date insights into the performance and status of the watchdog server.

Configuration Files

Example mapping.conf File

This file contains mappings for different departments, specifying conditions like the hostname pattern, label, operating system, IP address range, and MAC address pattern (can be changed on runtime).

# mappings.conf
# File to define groups for the browsermon controllers 
# based on any criteria (guid, hostname, mac, version, ip, os, label)

[Staff]
host=austin-*
label=staff
os=windows

[HR]
host=newyork-*
os=linux
label=hr
address=123.11.219.0/24
mac=23:ab:123:*

[Accounts]
host=sunnyvale-*
os=linux

[CEO]
host=chicago-ceo*
label=ceo
os=windows

Example browsermon-watchdog.conf File

This file defines the settings for each department, including the browser type, mode, schedule window, log directory, log mode, rotation interval, Kafka mode, eti_mode, cache_ttl and cache_max_size (can be changed on run time).

[HR]
browser=firefox
mode=scheduled
schedule_window=1m
logdir=/opt/browsermon/logs
logmode=json
rotation=1h
kafka_mode=false
eti_mode=false
cache_ttl=30d
cache_max_size=1000

[Accounts]
browser=chrome
mode=scheduled
schedule_window=1m
logdir=/opt/browsermon/logs
logmode=csv
rotation=1h
kafka_mode=true
eti_mode=true
cache_ttl=30d
cache_max_size=1000

[CEO]
browser=firefox
mode=scheduled
schedule_window=1m
logdir=C:\\browsermon\\history
logmode=csv
rotation=1h
kafka_mode=true
eti_mode=true
cache_ttl=30d
cache_max_size=1000

Customizing Information for Different Departments

Users can customize the information sent from the controller to get different settings based on their department. The information should include fields like guid, hostname, version, ip_addresses, mac_address, os, and label.

Example Information for HR Department

{
    "guid": "123e4567-e89b-12d3-a456-426614174000",
    "hostname": "newyork-hr1",
    "version": "1.0.0",
    "ip_addresses": ["123.11.219.5"],
    "mac_address": "23:ab:123:45:67:89",
    "os": "linux",
    "label": "hr"
}

Example Information for CEO Department

{
    "guid": "987e6543-e21b-12d3-a456-426614174999",
    "hostname": "chicago-ceo1",
    "version": "1.0.0",
    "ip_addresses": ["192.168.100.100"],
    "mac_address": "12:34:56:78:90:ab",
    "os": "windows",
    "label": "ceo"
}

How the Matching Works

  1. Label Matching: This is the highest priority. If the controller's label field matches the label specified in the mapping.conf file, the department associated with that label is selected immediately.
  2. Hostname Matching: If no label match is found, the system checks if the controller's hostname matches the pattern defined for a department. A wildcard (*) can be used in the hostname pattern to allow for partial matching.
  3. IP Address Matching: If neither label nor hostname matches, the IP address is compared. The controller's IP addresses are checked to see if any of them fall within the subnet ranges specified for a department.
  4. MAC Address Matching: If the IP address does not match, the system will try to match the controller's MAC address using a pattern that can include wildcards.
  5. Operating System (OS) Matching: As the last option, the controller's OS is compared against the OS specified for the department. The system performs a partial match if a wildcard (*) is used, ensuring that different versions of the same OS can be grouped together.

The matching process in NOT case-sensitive.

The process follows a first-match-wins strategy. As soon as a match is found, the department associated with that match is selected, and the remaining conditions are ignored.

Example Workflow of Matching

Here’s a simple example to illustrate how the matching process works:

  • Controller Information:
  • Label: "hr"
  • Hostname: "newyork-hr1"
  • IP Addresses: ["123.11.219.5"]
  • MAC Address: "23:ab:123:45:67:89"

  • OS: "linux"

  • Matching Process:

  • Label Matching: The system checks the label "hr". It finds that the HR department has a matching label, so it immediately selects the HR department.
  • Hostname, IP, MAC, and OS: Since the label matched, the system does not proceed to check the other conditions (hostname, IP, MAC, or OS).

The HR department is selected based on the label match, even though other conditions might also match.

Conclusion

By customizing the information based on the department's criteria, users can ensure that the watchdog server provides the most suitable settings for each controller. This enhances the flexibility and efficiency of managing different configurations across various departments within a company while also ensuring secure access through the key expiry feature. Additionally, the Grafana dashboard provides a powerful tool for visualizing and analyzing the collected data, further enhancing the capabilities of the watchdog server.