Known Issues

This chapter lists general known issues by Fabasoft app.telemetry encompassed with the recommended solution.

Connection to Agent Refused

Issue:

The status of a Fabasoft app.telemetry agent is displayed as "not connected" in the agent view of the app.telemetry client.

The error message text is similar to the following:

Connection refused because of multiple active connections

This situation is caused by multiple connections to a single Fabasoft app.telemetry agent. Multiple connections to a single Fabasoft app.telemetry agent might occur because one of the following configuration issues:

1. More than one Fabasoft app.telemetry server connect to the same Fabasoft app.telemetry agent.
2. One Fabasoft app.telemetry agent is configured multiple times within one Fabasoft app.telemetry server installation.

Solution:

To resolve the situation, ensure that following criteria apply:

1. Each Fabasoft app.telemetry agent is dedicated to one specific Fabasoft app.telemetry server.
2. All agents configured in the Fabasoft app.telemetry client connect to dedicated Fabasoft app.telemetry agents (e.g. no duplicate "network address" properties).

Turn on Crash Dumps on Linux

Issue:

The Fabasoft app.telemetry Linux services support as any other Linux process to produces a crash dump. With the default configuration this feature is disabled but can be enabled with a simple configuration file.

Solution:

To turn on crash dumps for app.telemetry Linux services (Agent, Server) follow the described steps below:

1. Open and edit the sysconfig configuration file for the apptelemetryagentd or the apptelemetryserverd in order to change the setting for the specified process. The files are self-explaining. Just uncomment or change the appropriate lines and restart the processes by means of using the init script.
   • /etc/sysconfig/apptelemetryagentd
   • /etc/sysconfig/apptelemetryserverd
2. 'Enable core files' by setting the core file limit to unlimited or any other reasonable value.
   • for Red Hat-based Linux systems: activate/uncomment the following line:
   • DAEMON_COREFILE_LIMIT='unlimited'
3. Set the core file location (optional):
   1. default (if not set explicitly) the system will write the core files two one of the following locations (depending on the startup kind of the process - during system boot or manually)
      • Processes started during system boot will be dumped to the root file system folder "/" (/core.1234)
      • Processes started manually by a user using the init script will be dumped to the current folder
      • In some cases the dump file may be placed next to the binary file (/opt/app.telemetry/bin)
   2. You can explicitly set the dump file location via the kernel core_pattern setting
      • Create the desired target directory and make it world writeable:
        mkdir /tmp/dumps
        chmod 777 /tmp/dumps
      • set the core file pattern in the kernel variable (file)
        echo "/tmp/dumps/core" > /proc/sys/kernel/core_pattern
        the default pattern is "core" which will place a file starting with the name "core" in the default location described above.
4. Restart the processes by means of using the service utility
   • service apptelemetryagentd restart
   • service apptelemetryserverd restart

Finding core files somewhere on your Linux system:

If you don't know where your core files are placed and you know there must be a core file somewhere on your system, you could try finding the core file with the following find statement:

find / -mount -type f -regex ".*/core\.[0-9]+$"

SNMP Counter not Available

Issue:

It may occur that some Fabasoft app.telemetry checks return the message "SNMP-Counter (...) not available". This message indicates that the desired SNMP counter could not be checked by the Fabasoft app.telemetry agent.

The numeric value in brackets in the message (for example: .1.3.6.1.4.1.2021.4.15.0) is the SNMP OID of the defined counter check that is queried to get the resulting value. If there are more than one of such messages listed, the counter value is calculated based on a formula consisting of several SNMP values.

The case that SNMP-Counters are not available can have different problem causes:

1. no SNMP daemon installed on target system (package net-snmp is missing)
2. SNMP daemon not running on target system
3. SNMP configuration invalid to get that counter
   1. security restrictions: SNMP community string mismatch
   2. security restrictions: SNMP security view does not allow accessing that counter
4. app.telemetry counter check configuration invalid for that target system – counter or instance does not exist

Note: many app.telemetry counter checks for unavailable SNMP counters with a short update interval may decrease the app.telemetry agent performance, so check your counter configuration carefully!

Solution:

To resolve this problem follow the solution tips for the appropriate problem item (item number from issue list above) and test the configuration as described below.

1. If no SNMP daemon is installed, install the software-package "net-snmp-5.x.<arch>.rpm"
2. If SNMP daemon is not running, start the daemon using "service snmpd start".
   Additionally you should set the SNMP daemon to autostart at system startup "chkconfig --level 345 snmpd on"
3. Check the SNMP configuration / security restrictions ... (/etc/snmp/snmpd.conf)
   1. Configure SNMP authentication: configure SNMP community string on both sides. The SNMP community string set in the snmpd.conf configuration (rocommunity <string>) has to match the defined community string in the app.telemetry agent configuration (app.telemetry web client > edit mode > target agent > SNMP community
   2. Configure SNMP view restrictions: you should include all required SNMP counters in your SNMP configuration
      1. The simplest configuration is to disable all access control configuration lines in the configuration file and only set the SNMP community string with the following configuration line: "rocommunity <string>"
      2. Another possibility is to include all counters and do not restrict any counters by means of using the following configuration line: "view systemview included .1"
      3. The most secure configuration is to include only the required SNMP subtrees for your desired counters, but then you need to find out all required SNMP OIDs.

To test the SNMP configuration and the availability of the SNMP counters you need to have the additional SNMP software package "net-snmp-utils" installed on one of your Linux systems that could connect to the problematic target system (for example you could install these utilities on the app.telemetry server).

All you have to do is run the following commands with your concrete values set:

app.telemetry Client not Working after Installation

Issue:

After installation of Fabasoft app.telemetry on a new Linux system and trying to access the Fabasoft app.telemetry client with your web browser the client may show an info dialog with the message that something is not working properly.

The following reasons could prevent the Fabasoft app.telemetry client from working properly:

1. Fabasoft app.telemetry server is not running
2. SELinux is running in “enforcing” mode and the app.telemetry SELinux policies have not been installed or applied correctly.
3. The app.telemetry connection/listening ports of server/webserver are misconfigured

Solution:

The solutions for the reasons above (same numbered item) are listed below:

1. Start the Fabasoft app.telemetry server service/daemon and check if it is set to automatic startup
2. SELinux Troubleshooting
   1. If you don’t really need SELinux, just turn it off or to permissive mode
      • Check SELinux state: sestatus
      • Change to permissive mode: setenforce 0
      • Change SELinux configuration mode for startup (persistent) – modify /etc/selinux/config
   2. Check the setup output of the Fabasoft app.telemetry RPM installation and see if any Warnings/Errors occurred during setup
      /var/log/app.telemetry/<server|agent|webapi>-rpm.log
      • On installation errors you might have not installed the required RPM packages for SELinux policy file management (policycoreutils-python) – install the missing packages and reinstall the app.telemetry RPM files
   3. Maybe you have to restart the app.telemetry daemons to get the SELinux policies be applied
   4. Check the SELinux audit log and grep for denied log entries
      cat /var/log/audit/audit.log | grep “=AVC”
3. Check if the app.telemetry server and agent are running and listening on their configured ports by means of using the ss -tnl tool (apptelemetryserver default port 10000, apptelemetryagent default port 10001)

Security Warning/Restriction for End-2-End Instrumentation

Issue:

The Fabasoft app.telemetry end-2-end instrumentation for websites via the JavaScript SDK is based on data communication POST-requests between the web site and the Fabasoft app.telemetry web service (WebAPI).

Web browsers have security limitations for POST-requests invoked from JavaScript for different locations (different protocol, target, port) so you may receive warning messages or even all the data transfer with the WebAPI is blocked and no end-2-end instrumentation is possible.

The following table shows the different access possibilities for the example base page: http://store.company.com/dir/page.html

Source: https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript: new window

So if you have any troubles with denied POST-requests to the configured app.telemetry WebAPI check and compare the used URLs and follow the hints listed below.

Solution:

In order to use Fabasoft app.telemetry end-2-end instrumentation (via JavaScript SDK) ensure that the instrumented web site is allowed to send the data (POST-requests) to the configured WebAPI url.

1. The simplest solution is to install the app.telemetry WebAPI on the same host (also same port and protocol) that also provides your instrumented web page.
2. Using a Load-Balancer to route the requests correctly via a sub directory.
3. Server-side routing of the requests using a local WebAPI url inside your instrumented web page and some special server-side logic capturing and forwarding all telemetry requests to the WebAPI.
4. Using Apache mod_alias, mod_proxy or mod_rewrite to route the requests.
5. Using an iframe with script content from the target domain and specific client-side code to handle the data.
6. Using a web browser with support for cross-origin resource sharing (https://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html: new window - e.g.: Mozilla Firefox 3.5). This may also require some code modifications.
7. Using „Signed Scripts for Mozilla Firefox“ (http://www-archive.mozilla.org/projects/security/components/signed-scripts.html: new window).

Feedback Dialog shows two Screenshot Properties

Issue:

When using the Fabasoft app.telemetry feedback dialog (report dialog) via the app.telemetry API and your application is running in a Fabasoft application context with available Fabasoft plugin there are different screenshots provided:

• A native screenshot provided by the Fabasoft plugin with a native screenshot preview opened in a desktop application (this type is also called the legacy native screenshot)
• An HTML5 screenshot (which may also fetch the screenshot data from the Fabasoft plugin if available) providing a full-featured screenshot inline preview with mark/crop/blackout features.

If you can see those 2 different screenshot attachments in your feedback dialog you are still using a legacy configuration when calling the createDialog-API-call.

Solution:

In order to disable the legacy native screenshot you have to set the screenshot property object to “enabled:false” when passing to the createDialog-API-call.

Bar Chart Text Overlapping

Issue:

In some situations your dashboard charts may look improperly (e.g. long bar chart label texts overlap).

Depending on your web browser window size, your dashboard settings (number of columns to display) and your chart settings (height of chart) the chart content may fit into the available space or not.

Solution:

Beside the basic features of reducing the number of dashboard columns, increasing the chart height or reducing the label length (of your service checks) some new improvements may help you solve your problems.

With Fabasoft app.telemetry 2012 Spring Release the chart capabilities have been improved the following way:

• Chart legend labels are limited in their maximal length (depending on the chart width) - anyway you should display the legend only if you need it (for bar charts this information is most times redundant)
• Gauge chart scaling improved
• Bar Charts axis labels improved:
  • Horizontal bar chart: long axis label texts now wrap around (depending on the chart size)
  • Vertical bar chart: the axis label texts can now be rotated to display them diagonal or even vertical to prevent overlapping texts ... for this purpose you can define the axis label rotation angle in the chart properties (edit view) with a value between -90° and 90° (negative angle values (e.g.: -30) are displayed left of the bar and positive values (e.g.: 45) are displayed right of the bar, a value of 0 displays the labels horizontal as before)

SELinux policy module installation broken on RHEL/CentOS 7.3+

Issue:

On RHEL / CentOS 7.3+ you may experience problems during SELinux module installations or updates or policy modules are not in use on systems that upgraded from an earlier version.

You might see error messages like:

Errors may refer to different policy modules or different port types.

Cause:

In case SELinux policy modules get loaded during the upgrade of the RHEL/CentOS operating system a situation may arise in which policy modules can’t be loaded because the installed SELinux tools have inconsistent versions. Such an error may then leave some SELinux modules in an inconsistent state which causes errors like the ones listed above.

Solution:

After the upgrade to 7.3+ has completed to install all package updates reinstall all the app.telemetry policy modules using:
semodule –i /opt/app.telemetry/selinux/*.pp

Empty Configuration after the upgrade to Version 2018 UR 2

Issue:

The configuration appears to be completely empty and it is impossible to create any new items in the configuration view because of a network error.

Cause:

On RHEL / CentOS 7 services are not automatically started after the RPM installation, this also applies to new services during an upgrade from a Fabasoft app.telemetry version that did not yet have these services.

Solution:

Run the /opt/app.telemetry/bin/serversetup.sh script to execute the required upgrade steps and make sure the apptelemtryconfiguration service is enabled and started. Upon starting the Fabasoft app.telemetry Configuration Service all remaining Fabasoft app.telemetry services will receive their configuration and resume normal operation.