Troubleshoot the Open Collector

Errors Occur During Open Collector Deployment Running the init Command

The likely explanation is that the necessary ports are not open. Check the ports described in Install the Open Collector and see the troubleshooting steps in Issues With Open Ports section below.

Exporting Log Data to File

If you want to write log data to a local file for viewing or recording of errors, you can do this by running the troubleshoot command:

./lrctl <service> troubleshoot export --outfile troubleshoot.tar.gz

• Where <service> is a LogRhythm Open Collector component such as oc, eventhubbeat, metrics, etc.

• Unpack the tar.gz file to view the log data

After Configuration, No Pending Log Source Appears in the Client Console

After logs are flowing from the Beat to Open Collector to System Monitor Agent, the Pending Log Source may take up to 15 minutes to appear in the Client Console. 

The best place to start looking is Metrics. Metrics quickly show you if any logs are reaching the Open Collector.

• If Metrics is unavailable, check:

  • The service status:

    ./lrctl metrics status
    

  • That port 3000 inbound is open on the Open Collector

• If Metrics shows all 0 graphs, check the Beat and Open Collector status:

  ./lrctl <beatname> status
  ./lrctl oc status
  

• If Metrics shows logs flowing through the Open Collector, check the System Monitor Agent and associated firewalls (outbound from Open Collector and inbound into System Monitor Agent).

Obtain Diagnostic Metadata in Generic JSON Collector Logs

Logs collected through the Generic JSON Collector (port 6044) automatically include agent version and JSON policy name metadata, just like the Beats JSON Listener (port 5044). This gives administrators direct diagnostic context when investigating collection and parsing issues.

When escalating an issue to support, the agent version and JSON policy name are directly visible in the log. You can provide this information immediately without performing manual configuration lookups.

What Metadata Is Included

Logs received on port 6044 include two additional fields:

• Agent version, the version of the Beat that sent the log.

• JSON policy name, the name of the JSON policy that was applied when the log was collected.

The format of these fields matches the metadata already present in port 5044 logs.

Use the Metadata for Troubleshooting

This metadata can be used to diagnose parsing failures. When logs are not parsing as expected, check the JSON policy name field to confirm the correct policy is being applied to the incoming data. If the wrong policy is listed, review the policy assignment for that Beat in your Open Collector configuration.

You can also use this data to identify version-related issues. If you suspect a specific Beat version is causing collection or parsing problems, check the agent version field in the affected logs. This allows you to confirm exactly which version is sending data and determine whether an upgrade or rollback is appropriate, without manually reviewing agent configurations.

The JSON policy name field lets you verify that expected policies are being applied consistently across all Beat deployments feeding into port 6044.

Logs Do Not Have Correct Timestamps

The Open Collector extracts the timestamp from the log message and sends it in the syslog message. The Agent needs a new Syslog Relay Regular expression to extract that timestamp; otherwise logs have a timestamp from when they were received by the System Monitor Agent.

For more information, see the Configure the <Beat Name> Log Source in the SIEM topic in the applicable Beat documentation.

1. Ensure the System Monitor Agent collecting the logs has:

   • The correct Syslog Relay Regular Expression at the top of the list

   • The Open Collector IP Address in the list of Syslog Relay IPs

2. Ensure the Open Collector configuration has the correct timezone of the System Monitor Agent. You can verify it using the command:
   

   ./lrctl oc config view | grep "Timezone"
   

Issues With Open Ports

You can use telnet to check if a port is open.

• If the port is open, you will see one of the following:

  • Connected to ...

  • Connection closed by foreign host

• If the port is not open, you will see one of the following:

  • Connection timed out

  • Network is unreachable

The following example shows how to install telnet, hit gcr.io (Google Container Registry) over 443 but not over 4436 (a blocked port), and then check a System Monitor IP (10.4.1.64, in this case) over port 514.

When attempting to start OC Metrics or the Open Collector, you may see the following error message:

• If you are on CentOS 8 or RHEL 8, this message indicates that you did not change "nftables" to "iptables" in your firewalld.conf file.  Please see OS installation instructions for your version of Linux.

Broken Configuration

If a configuration is broken, it may be easiest to reset and start fresh. Use the following commands.

Open Collector Maintenance

./lrctl oc stop
./lrctl oc config remove
./lrctl oc config create

Beat Maintenance

./lrctl <beatname> stop
./lrctl <beatname> config remove
./lrctl <beatname> config create

Remove Docker Volumes and Containers

docker volume ls
docker container ls
docker volume rm <volumename>
docker container rm <containername>

Completely Remove Docker

sudo yum remove -y docker-ce docker-ce-cli

Open a Support Ticket

In the event you have exhausted the troubleshooting guide, open a support ticket using the contact information provided in the front of this guide.

1. List troubleshooting steps already taken.

2. Run:

   ./lrctl open-collector troubleshoot export --outfile troubleshoot.tar.gz
   

3. Save the troubleshoot.tar.gz file to provide it to the support team.

System Diagram

This diagram outlines the collection and transformation process for logs when parsed through the Open Collector.

More information on the functionality of the JQ-Parsing vs. JSON Parsing engines can be found at Configure Open Collector Connection to the SIEM.