Monitor Collectors

In Graylog 7.2, Graylog Collector has been released as a preview feature for evaluation and feedback purposes. This feature's design and behavior could change significantly in future releases. To share feedback on your experience with Graylog Collector, email feedback@graylog.com.

The Collectors Overview page shows the state of every enrolled collector, whether it is reporting, whether it is healthy, and whether it has applied the configuration Graylog holds for it. This article explains how to read that state and how to inspect an individual collector.

Prerequisites

Before proceeding, ensure that the following prerequisites are met:

  • You must be a Graylog administrator or have either the Collectors Manager or Collectors Reader role.

  • To view a collector's own logs, you must be a Graylog administrator, or a Graylog administrator must share access to the Collector System Logs stream with any non-administrator user. Neither Collectors role grants that access on its own. See Manage Sharing.

View Collector Status

The Overview tab at System > Collectors summarizes the deployment, with counts of instances, fleets, and sources, and how many instances are online or offline. A card for each fleet shows its instance and source counts. The Recent Activity list records administrative changes, showing who made each one and when. Use that list to tie a change in collector behavior to the change that caused it.

The Instances tab lists every enrolled collector with its status, sync state, hostname, operating system, fleet, version, and when it was last seen. You can filter the list by any of those values.

Important: The Instances tab hides collectors that have not reported within the visibility threshold, which by default is one day. A collector missing from the list is not necessarily gone. To adjust the default settings, see Configure Collector Settings.

The Sync column shows whether a collector has confirmed applying the configuration Graylog last sent it. A collector that stays unsynced has received a configuration it cannot apply, which its health information explains.

Inspect a Collector

Select Details on a collector's row to open a panel showing its status, sync state, fleet, operating system, version, when it enrolled, and when it was last seen, along with its health.

Health comes from the collector itself. An unhealthy collector reports the error that made it unhealthy and when the state last changed. A collector can be online and unhealthy at once because it is still reporting while part of its configuration is failing. For a collector that has gone offline, the panel shows the last known health rather than a current one.

Active Sources lists the sources the instance received from its fleet, each tagged with its type. Use that list to confirm a collector is collecting what you expect because a fleet that mixes operating systems delivers only the source types each host supports.

Synchronization lists any actions still queued for a collector that has not synced, which tells you what is waiting rather than only that something is.

From the table view, use View System Logs to open the collector's own diagnostic logs, which it ships to Graylog, so you can read them without access to the host. The search icon opens the Search page filtered to the messages that collector has sent, which is the only way to confirm data is actually arriving.

Troubleshooting and Common Issues

The following section outlines troubleshooting steps for common issues to assist you in resolving potential challenges you may encounter.

Configuration Not Applying

A collector whose Sync column stays at Sync pending has been sent a configuration it has not confirmed applying. That behavior is normal for a few seconds after a fleet changes but a problem if it persists.

Open the collector's details and read its health, which reports the error. Then read the collector's own logs through View System Logs, or the supervisor log on the host if the collector is not reporting at all.

A source type that does not apply to the host's operating system is not a cause. Graylog builds each collector's configuration against the operating system it reported and omits source types the host cannot use, so a Windows Event Log source in a fleet of Linux hosts is never sent to them.

Further Reading

Explore the following additional resources and recommended readings to expand your knowledge on related topics: