Troubleshooting¶
There are a number of ways you can troubleshoot the ingester
and API
. The most accessible ways are through the log files and the API test script.
Ingester Troubleshooting¶
This section covers the various ways you can troubleshoot ingester
operation.
Ingester Logging¶
It is always good to verify the operation of the ingester
by observing changes in its log file. It is a good source of troubleshooting information.
You can see these changes as they occur by using the tail -f
command as seen below:
$ tail -f /opt/infoset-ng/log/infoset-ng.log
The location of the log file is governed by the log_directory
parameter in the configuration.
Testing Ingester Operation¶
You can test the operation of the API by using the curl
command which is often used to test basic website functionality. The example below shows how. Replace SERVER_IP
with the IP address or fully qualified DNS name.
$ curl http://SERVER_IP:6000/infoset/api/v1/status
infoset-ng API Operational.
$
The curl
response should be infoset-ng API Operational
if
successful.
Invalid Agents¶
There is the possibility that agents may be posting incorrectly formatted JSON data to the API
. You can view the contents of these invalidated files in the failures/
sub-directory of the API
cache directory. The cache directory is defined in the ingest_cache_directory:
option of the configuration file.
API Troubleshooting¶
There are a number of ways you can troubleshoot the API
. The most accessible ways are through the log file.
API Logging¶
It is always good to verify the operation of the API
by observing changes in its log file. It is a good source of troubleshooting information.
You can see these changes as they occur by using the tail -f
command as seen below:
$ tail -f /opt/infoset-ng/log/api-web.log
The location of the log file is governed by the log_directory
parameter in the configuration.
Poor or Blocked Network Connectivity¶
It is possible that there could be firewalls or intermittent connectivity causing issues to your API
you should familarize yourself with the tcpdump
command to determine whether connections are coming through.
In this example we are testing to see whether we are receiving traffic from IP address 192.168.1.100 on TCP port 6000 which the API
uses
$ sudo tcpdump -ni tcp port 6000 and host 192.168.1.100
You can also use the basic telnet
command to determine whether the remote device or network can communicate with the API
. In this example we are testing to see whether we can communicate with the API
running on a server with IP address 192.168.1.200 on the default TCP port 6000.
$ telnet 192.168.1.200 6000
Trying 192.168.1.200...
Connected to 192.168.1.200.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
If you get no response, then you need. Try this approach on both the local and remote ends of the connection. In other words, use the same command on both the remote client and API
server. If there is response on the server, but none on the client, then there is probably a connectivity issue.
You can also determine whether the API
server is running at all. Use the netstat
command on the API
server itself to determine whether it is listening on port 6000. If there is no response, then the API isn’t running.
$ netstat -ant |grep 6000
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
$
You should also try to use the curl
examples in the API
guide to assist further.