This chapter lists general known issues by Fabasoft app.telemetry encompassed with the recommended solution.
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:
To resolve the situation, ensure that following criteria apply:
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.
To turn on crash dumps for app.telemetry Linux services (Agent, Server) follow the described steps below:
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]+$"
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: .188.8.131.52.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:
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!
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.
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:
Linux Shell – Test SNMP Example
snmpwalk -v 1 -c <COMMUNITY-STRING> <TARGET-AGENT-IP> 184.108.40.206.220.127.116.11
snmpwalk -v 1 -c <COMMUNITY-STRING> <TARGET-AGENT-IP> 18.104.22.168.4.1.2021
# example ...
snmpwalk -v 1 -c public 10.20.30.40 22.214.171.124.126.96.36.199
snmpwalk -v 1 -c public 10.20.30.40 188.8.131.52.4.1.2021
It may occur that some Fabasoft app.telemetry checks for getting the number of running system processes return the message "SNMP-Counter .184.108.40.206.220.127.116.11.6.0 not available!”. This may be a predefined app.telemetry counter check named “System: Running Processes” or a self-defined SNMP counter check for that counter.
This message indicates that the desired SNMP counter could not be checked by the Fabasoft app.telemetry agent because the counter is potentially really not available from net-snmp.
You have upgraded your RHEL/CentOS installation from version 6.5 to version 6.6 and therefore got an updated net-snmp package version (net-snmp-5.5-49.el6_5.2 or net-snmp-5.5-49.el6_5.3) containing a bug described in the following bug reports causing the SNMP counter HOST-RESOURCES-MIB::hrSystemProcesses.0 to be not available:
Check the status of the bug reports mentioned above and look for an updated net-snmp RPM package solving that bug.
Or downgrade to the older net-snmp RPM package version (<= net-snmp-5.5-49.el6_5.1) from RHEL/CentOS 6.5.
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:
The solutions for the reasons above (same numbered item) are listed below:
The following table shows the different access possibilities for the example base page: http://store.company.com/dir/page.html
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.
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:
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.
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.
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.
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:
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:
SELinux module installation error message examples
# semodule -i /opt/app.telemetry/selinux/apptelemetryserver.pp
Failed to resolve roletype statement at /etc/selinux/targeted/tmp/modules/400/apptelemetryserver/cil:2
# semodule -i /opt/app.telemetry/selinux/apptelemetryagent.pp
libsepol.context_from_record: type apptelemetryserver_port_t is not defined (No such file or directory).
libsepol.context_from_record: could not create context structure (Invalid argument).
libsepol.port_from_record: could not create port structure for range 10000:10000 (tcp) (Invalid argument).
libsepol.sepol_port_modify: could not load port range 10000 - 10000 (tcp) (Invalid argument).
libsemanage.dbase_policydb_modify: could not modify record value (Invalid argument).
libsemanage.semanage_base_merge_components: could not merge local modifications into policy (Invalid argument).
Errors may refer to different policy modules or different port types.
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.
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
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.
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.
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.