• A Pro.Monitor instance can be configured to work following 3 types of roles:
  • Standalone Server
  • Primary Server
  • Agent

• Communication between Server and agents is Unidirectionnal: Only agents will initiate connection to the Server.
• The Server doesn't require any inbound connection the agent's network.
• The server can therefore be publicly accessible while the agents can be in protected area: No need for SSL tunnel, VPN or complex network settings to deploy a mutli-instance implementation and centrally manage the monitoring of multiple isolated environments.
• This architecture can also be used to add more robustness, by having several monitoring agents and be resilient in case one goes down.

• Go to Settings→Admin configuration→Multi-instance.

• In the Multi-instance tab, you can configure:
  • Primary server mode: If active, the instance will manage monitoring configuration
  • Agent: If active, the instance will execute monitoring tasks (connect to systems, detect problems, generate metrics and alerts)
  • Agent name: A meaningful name to identify the agent in the primary sever (something better than IP)
  • Primary server URL: The primary server to bind to.

• The registered agent tab will show all currently ACCEPTED and PENDING agents:
• You can visualize information about each agent, Name, Status, CPU, Memory, Disk, Version, Drivers.
• Two tables will display the agents details, the first will show ACCEPTED agents, the second the PENDING ones.

• When an agent registers for the first time in Pro.Monitor, it has a PENDING state. It will not execute any task.
• An administrator will then ACCEPT the agent via the dedicated button
• Few seconds later, the agent will appear in the list of accepted agents
• When an agent is ON with a status WORKING, it is ready to execute monitoring tasks.
• Monitoring workload will be evenly distributed across agents, according to their associations (see agents groups).
• You can temporarily deactivate an agent by selecting it and using ACTION menu to press Deactivate. No more tasks will be executed.
• You can delete an accepted agent. It will go back in the list of pending agents, until switched off.
• If an accepted agent stops to poll the primary server, it will be detected after few minutes. Its state will switch to OFFLINE and its current workload will be rescheduled on other available agents.

NOTE: When several agents share the same workload, it is recommended to use similar specs for their servers.

• The Server/Agent architecture has primarily be designed to centrally monitor systems from several isolated environments
• That means that one agent might only have access to a subset of systems, and must only execute tasks related to them.
• In the Agents groups tab, you can configure which group of systems will be monitored by which agent(s).
• Simply select an agent and press the Assign button to load the list of groups. You can then mass assign several groups to an agent in one click.
• You can also use the plus button to assign just one group.

• Agent to groups associations are displayed in the table at the bottom
• You can delete single associations from the table or use assign for mass delete.

NOTE: In standalone mode, it is not necessary to assign groups to the local agent. But if you do so, unassigned groups won't be monitored.
WARNING: If a group is not assigned to any agent, all its systems won't be monitored and a warning popup will be displayed

• This is the default mode, no specific configuration is required.
• Primary server and agent roles are both enabled. In this mode, Pro.Monitor is an agent and a primary server at the same time.
• The server will manage the configuration, user interface and execute monitoring tasks.
• Every Pro.Monitor instance with an enabled agent has a local agent used to execute monitoring tasks.
• The agent will appear automatically in the list of accepted agents and cannot be deleted.

NOTE: In standalone mode, it is not necessary to assign groups to the local agent. But if you do so, unassigned groups won't be monitored.

• In this mode, Pro.Monitor will manage the configuration of the monitoring and distribute tasks to one or several remote agents.
• It will be used as monitoring portal for the users and also hold the database, and connect to the plugins.
• Primary server role must be active in the Multi-instance tab
• Full primary server URL, including scheme and port number must be registered in the Primary server URL field of each agent
• Each agent bound to the server must be accepted once by the admin
• Associations between groups and agents must be done via the Agents groups tab.
• One group can be managed by several agents, in that case, group workload will be distributed across each compatible agent.
• Some system settings from primary server will be propagated automatically to each agent:
  • Number of parallel tasks
  • Monitoring process timeout
  • Log level and duration
• Most others like Monitoring process memory will still be local settings
• If the Agent role is enabled, the local agent will be used as any remote agents.

NOTE: You can visualize agent activities in the Monitor statistics menu (Must activate monitors results retention in System tab)

• In Multi-instance tab, activate Agent mode and deactivate Primary server role
• Define the agent name to use
• Set the primary server URL
• Save the settings. The agent will connect to the primary server and will be handled from there.
• Some local settings will still remain available, such as System→monitoring processes memory or log retention
• Connecting to primary server in HTTPS:
  • Server must use an certificate generated for its actual IP (will not work will the default certificate)
  • Download server certificate using your browser and add it in the Pro.Monitor keystore of the agent (see HTTPS config for more details)

NOTE:

• If the instance was previously used as a server, its configuration will be hidden until switched back to its server role.
• The Agent doesn't require any licence