Skip to main content
Version: 7.9

RSRemote Administration

Introduction​

RSRemote is part of Resolve Actions Pro along with the other components of the platform - RSView, RSControl, RSMgmt, RSMQ, RSSearch. The purpose of RSRemote is to manage the interaction with external event generation systems.

The purpose of RSRemote is to:

  • Captures the events from an external event generation system and sends them to the Actions Pro system for processing.
  • Optionally updates or deletes events from the external event generation system.
  • Process a large amount of simple validation events and reduce the pressure on Actions Pro Core.
  • Distribute the load of the automation execution and gateway processing to multiple hosts.
  • Provide flexibility to adapt to customers' complex network environment.

Getting Started​

Business Value​

The business need for creating a unified RSRemote management dashboard is derived from the fact that a growing number of Actions Pro customers have an increasing number of RSRemote components on their Actions Pro system. This unified UI is designed to simplify the management of these RSRemotes.

Issues, resolved with implementing the RSRemote Administration Dashboard:

  • Difficulties to identify the status of standalone RSRemotes.
  • Not possible to control RSRemote status or configure them from central location.
  • Cases in which standalone RSRemotes lose connectivity and not re-connect.
  • Standalone RSRemotes are often located in a secure place, as behind firewalls.

The ability to configure the RSRemote from a central UI instead of the clumsy procedure of logging onto the RSRemote and then make the necessary configuration setting, saves time and increases the work efficiency of the platform administrators and developers. 

About the RSRemote Administration Dashboard​

This is a Dashboard on which you can:

  • View all RSRemote instances that are connected to an Actions Pro Core.
  • Select an RSRemote instance directly from the Dashboard and review its configuration.
  • Modify one or more RSRemote configurations and manually save the changes. Note that the changes are not automatically deployed until you specifically do it.
  • Deploy a modified configuration to a target RSRemote instance and launch it. As the deployment process require you to restart the system, notification message warns you for that. There is notification for successful or failed process. The changed configuration is marked as deploy when successful. In case of failure you are notified for the reasons of failure.

Accessing RSRemote Administration​

To access the RSRemote Administration functionality of Actions Pro, go to Main Menu > Remote Administration > RSRemote Administration.

The RSRemote Administration dashboard appears.

RSRemote Configuration​

To configure an RSRemote:

  1. From the RSRemote Administration dashboard, select an instance.
  2. From the Actions drop-down, click RSRemote Configuration.
    The configuration screen related to the selected instance appears.
    All components of this instance are collapse by default. You can expand one or more of them to review the information it contains.
    In this mode, the fields of the components are inactive and you cannot make any changes.
  3. Click Edit to make configuration changes on an RSRemote instance.
    Note that clicking Edit will lock the file, preventing others from making changes while you are working on it.
    In Edit mode, all fields of the file become active and you can apply the necessary changes.
  4. When finished, click Save Changes.
  5. In the confirmation message that appears, click Continue to deploy the new configuration to the gateway.

Health Check​

This functionality enables you to check the status of the components that are part of your system - whether they are accessible, functional and operational. Additionally to performing health check on an Actions Pro component such as RSRemote, you can apply this process to non-Actions Pro components such as RabbitMQ or a database.

For Actions Pro Components ​

In case of Actions Pro components, health check is performed only on active components. Active/in-active status of the components is based on their registration. Only instantaneous (no history) component health check results/reports are persisted into the database, specifically into the component_health_check table.

Primary RSView performs scheduled health checks of all active RSRemotes in cluster and all active Actions Pro components on the node each active RSRemote runs on.

System property component.healthcheck.interval.inminutes determines the health check schedule. This schedule is configurable with default value of 15 minutes and minimum value of 5 minutes. If one health check is missed, the system reports the latest registered value, and if two health checks are missed, it reports RED status and the check is indicated as failed.

You can initiate on demand health check of any active RSRemote component and also on all active components running on that node.

All of the Actions Pro component health checks require functional ESB (Enterprise Service Bus) and primary RSView.

Health check status codes (where Color = Value) are GREEN = 1, YELLOW = 2, RED = 3. Health check status displayed on the Dashboard is the one with the highest value.

Health Check Types​

ESB Ping to RSRemote, RSView, RSControl, and RSMgmt​
  • Checks accessibility of components connected through ESB (Enterprise Service Bus).
  • ESB Ping waits max 5 seconds to get response back from addressed component.
Component Specific Check​
  • Checks whether Component is functional.
  • Check varies based on functionality provided by a component.

Performing a Health Check On Demand​

To perform a health check On Demand:

  1. Go to RSRemote Administration Dashboard and select an instance. 
  2. From the Actions drop-down, select Health Check.
  3. Click Continue to perform the action.

If the check is performed successfully, the following confirmation message window appears: Successfully Checked Health Status for Selected RSRemote and Components.

Performing a Scheduled Health Check​

Scheduled health check runs periodically in the background. The default frequency is set to every 15 minutes. It is configurable by the system property component.healthcheck.interval.inminutes.

The tests performed are:

  • ESB Ping: Ping every component.
  • RSControl Health Check: Run a simple runbook on the RSControl.
  • RSMgmt Health Check: Check is made for the RSMgmt to verify it's collecting metrics.
  • RSRemote Health Check: Run a simple command from the RSRemote.

If the Health Check is successful, the Status is green.

The Health Check Status is red in case the ESB Ping fails, or if the RSControl, RSMgmt, RSRemote fail for that specific component.

You can view the health status of the Actions Pro components on the RSRemote Administration Dashboard, at the lower left part.

RSRemote Cron Management​

A new CRON Job is installed with the installation or update of an RSRemote. This CRON Job runs periodically to assist with the remote configuration of the Gateways and RSRemote blueprints. RSRemote installation does not fail in case of failed CRON Job deployment and a log error is printed out. RSRemote installation is allowed only to a user with administrative Linux server permissions. 

The Job allows periodical RSRemote and the RSMgmt restarts. The default setting for executing the Job is 30 seconds. 

note

It is strongly recommended that the default BluePrint setting is not changed as it may cause system resource loss. Use one of the options to restart the RSRemote alone or RSRemote and RSMgmt.

Cron Run Interval​

The interval is in seconds. This version only supports intervals less than or equal to 60 seconds. Cron will run every minute for input greater than 60 seconds, default is 30. Otherwise, cron will run on the upper nearest denominator of interval.

For example, if the interval is set to 13 or 14, the cron will run every 15 seconds.

Change the following Blueprint property to change the run interval:

rscron.interval=30

Cron Logging​

By default, Cron Task's logger is disabled and no logs are recorded.

Cron task is a stand-alone Java application, rscron, that is called by Linux crontab or Windows Task Scheduler, say, every 5 seconds. Only one process can run rscron at a time. A process running rscron will terminate if there is already a process running rscron. 

To turn the logger on, follow these steps:

  1. Follow the instructions below for LINUX to enable syslogd TCP protocol on port 514. For Windows, you do not need to make any change on the system.
  2. Modify blueprint, set rscron.syslog.enabled=true. 
  3. Run config.sh for Linux or config.bat for Windows.

Linux​

All logs will go to /var/log/messages. A requirement for this is rsyslogd must have tcp protocol enabled on port 514. If not enabled, rsyslogd's tcp protocol can be enabled usign the following steps:

  1. Comment out or add the following two lines in /etc/rsyslog.conf.
    $ModLoad imtcp  
    $InputTCPServerRun 514
  2. Restart syslogd:
    systemctl restart rsyslog.service

Windows​

Use Task Scheduler API 2.0, it requires minimum support.

Task Scheduler 2.0 Interfaces

Installing Windows Scheduled Tasks for Cron Process requires Administrative Role (Run As Administrator). This requirement allows the Cron Process to use adequate permission to modify the Windows registry and to add an entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\ResolveCronLogAppender

If Cron Process can not create the entry to the Windows Register and throws exception on logging, you need to manually add the entry. You can add it without any keys.

All Cron Process' logs are recorded onto Windows Event Log. You can see them using Event Viewer > Windows Logs > Application > ResolveCronLogAppender.

Manually Restarting RSRemote on Configuration Changes​

You can choose not to create a Windows Scheduled Task or a cron job for automatic RSRemote management on configuration changes. In this case, you will need to restart RSRemote manually after making configuration changes to the instance or its gateways from the Web UI.

On Windows, run these commands to restart RSRemote:

C:\Program Files\Resolve Systems\bin\stop.bat rsremote
C:\Program Files\Resolve Systems\bin\config.bat
C:\Program Files\Resolve Systems\bin\run.bat rsremote

On Linux, run these commands to restart RSRemote:

<install-dir>/bin/stop.sh rsremote
<install-dir>/bin/config.sh
<install-dir>/bin/run.sh rsremote

Troubleshooting​

When python is not recognized as an internal or external command, operable program or batch file.​
Probable Cause​

Issue arises when Windows cannot find python executable from its PATH environment variable.

This can be due to multiple reasons, for example:

  • Windows doesn't have Python installed
  • Windows can't find python executable in its PATH.
Possible Resolution​

Make sure that Python is installed and that Windows can find the python executable in its PATH. Test it by opening a cmd prompt and typing in python. The test is successful if it runs.

If you need to install Python or modify the PATH environment after the RSRemote service has been installed, re-install Rsremote, so it has the updated PATH environment. PATH is only set for RSRemote on install.

Take these steps to re-install RSRemote:

  1. Stop rsremote.
  2. Go to Actions Pro Home.
  3. Go to rsremote/bin.
  4. Run uninstall-service.bat with Admin privilege to uninstall existing service.
  5. Run install-service.bat with Admin privilege to install service.
  6. Run rsremote.

Reference ​

Terminology​

Actions Pro components - RSControl, RSMgmt, RSMQ, RSSearch, RSView, RSRemote.

RSRemote - an Actions Pro component which purpose is to interact with systems that are external to the platform. 

Instance - a concrete occurrence of any object (variable, function, method), existing usually during the runtime of a computer program.

Node - a basic unit of a data structure, such as a linked list or tree data structure. Nodes contain data and also may link to other nodes. 

Health Check - in Actions Pro, checks the status of the components that are part of a system - whether they are accessible, functional and operational.