What is the Particle Horizon Collector?

The Particle Horizon Collector, commonly referred to as the Collector, is a lightweight software service used to collect, process, and securely forward operational telemetry from systems within your environment.

The Collector is based on the OpenTelemetry Collector and includes additional Particle Horizon components designed to monitor supported applications and infrastructure.

In simple terms, the Collector acts as the local collection point between your systems and the Particle Horizon observability platform.

Your Systems
     |
     | Metrics / Logs / Traces
     v
+------------------------+
| Particle Horizon       |
| Collector              |
|                        |
| Collect                |
| Process                |
| Prepare                |
+-----------+------------+
            |
            | Telemetry
            v
   Particle Horizon

Why is the Collector needed?

Many applications and infrastructure components expose information about their health and operation in different ways.

For example, one system may expose metrics through a database, another through an application interface, while another may expose information through files located on the server.

The Collector provides a common way of gathering this information and converting it into standard telemetry that can be processed by Particle Horizon.

This allows Particle Horizon to provide monitoring without requiring every monitored application to communicate directly with the Particle Horizon platform.

Where does the Collector run?

The Collector normally runs within the customer environment, close to the applications or infrastructure being monitored.

Depending on the system being monitored, it may run:

• directly on an application server;
• on a dedicated monitoring server;
• alongside services that generate OpenTelemetry data; or
• on a server with network access to the systems from which it collects information.

Some monitoring integrations require the Collector to run directly on the monitored server. For example, some DACS monitoring functions execute the locally installed DACS diagnostic utility and therefore require the Collector to be installed on the relevant DACS host.

Your Particle Horizon implementation documentation will identify where Collectors should be deployed within your environment.

What does the Collector do?

A Collector performs three main functions:

1. Collect

The Collector receives or retrieves telemetry from configured sources.

Depending on the integration, this could include:

• application health information;
• infrastructure metrics;
• database statistics;
• application version information;
• service availability;
• licence status;
• logs;
• application traces; and
• telemetry generated by OpenTelemetry-compatible applications.

The standard Collector can also receive OpenTelemetry data using both OTLP/gRPC and OTLP/HTTP.

2. Process

Before telemetry is forwarded, the Collector can process the information.

Processing may include operations such as:

• batching telemetry;
• filtering information;
• adding useful context;
• removing unnecessary attributes;
• transforming metrics; and
• preparing telemetry for its destination.

The exact processing performed depends on your Particle Horizon configuration.

3. Export

After collection and processing, telemetry is passed to the configured destination.

This separation between collection, processing, and exporting is one of the main advantages of the Collector architecture.

It means applications do not need to understand where monitoring data will ultimately be stored or analysed.

What is a Receiver?

You may occasionally see the term Receiver when reviewing Particle Horizon configuration or support documentation.

A Receiver is simply the part of the Collector responsible for obtaining telemetry from a particular source.

For example:

DACS
  |
  v
DACS Receiver
  |
  v
Collector

or:

VisualEdge
    |
    v
VisualEdge Receiver
    |
    v
Collector

Different receivers understand different applications, protocols and data sources.

The Collector combines these receivers into a single service so that you do not need a separate monitoring application for every integration.

What is a Processor?

A Processor operates on telemetry after it has been collected but before it is exported.

For example, processors may:

Receive telemetry
       |
       v
+----------------+
|    Processor   |
|                |
| Batch          |
| Filter         |
| Transform      |
| Add context    |
+-------+--------+
        |
        v
Export telemetry

Particle Horizon supplies an appropriate configuration for the monitoring services deployed within your environment.

Customers generally do not need to modify processors unless instructed to do so by Particle Horizon support.

What is an Exporter?

An Exporter determines where the Collector sends processed telemetry.

This might be a central Particle Horizon telemetry service or another approved observability endpoint.

Conceptually:

Receiver
   |
   v
Processor
   |
   v
Exporter
   |
   v
Particle Horizon

This design allows the system collecting the information to remain separate from the system storing and analysing it.

Does the Collector collect everything from my server?

No.

The Collector does not automatically inspect or transmit everything available on a server.

Information is collected through explicitly configured receivers and telemetry pipelines.

For example, if a VisualEdge receiver is configured, it accesses the specific installation files and directories required to determine VisualEdge status and release information. Similarly, DACS integrations interact with explicitly configured DACS sources.

The information collected therefore depends on:

• the monitoring integration being used;
• which Collector components are enabled;
• the configuration supplied for your environment; and
• the Particle Horizon services included within your deployment.

Does the Collector require inbound Internet access?

The network requirements depend on your deployment architecture.

In a typical deployment, the Collector initiates connections towards configured telemetry destinations rather than requiring external systems to initiate connections to the Collector.

Some local applications may also send telemetry to the Collector using OpenTelemetry.

Your Particle Horizon deployment documentation will specify any required:

• firewall rules;
• destination addresses;
• DNS requirements;
• ports; and
• proxy configuration.

Do not expose Collector listening ports to untrusted networks unless this is specifically required by your deployment design.

How frequently does the Collector gather information?

Collection frequency varies by integration.

For many integrations, telemetry is collected periodically. A source may, for example, be checked every 30 or 60 seconds.

The collection interval can normally be adjusted where required.

Changing collection intervals can affect:

• monitoring responsiveness;
• workload on the monitored application;
• network utilisation; and
• the volume of telemetry generated.

For this reason, Particle Horizon recommends using the supplied settings unless a different interval has been agreed as part of your implementation.

What happens if a monitored system is unavailable?

The behaviour depends on the integration.

For several Particle Horizon receivers, a temporary collection failure does not cause the Collector itself to stop.

Instead, the affected source is retried at its next collection interval.

For the host-based DACS integrations, for example, unsuccessful collection results in no telemetry being produced for that source during that collection cycle. Collection is retried automatically and resumes when the source becomes available again.

This distinction is important:

Collector running
      |
      +---- Source A available ----> telemetry received
      |
      +---- Source B unavailable --> temporary telemetry gap
      |
      +---- Source C available ----> telemetry received

A problem with one monitored source does not necessarily mean that the Collector itself has failed.

Is the Collector licensed?

Some Particle Horizon-specific Collector components require a valid Particle Horizon licence.

The Collector includes a licence component that validates the supplied licence and makes the appropriate licensed capabilities available to supported Particle Horizon receivers.

For example, Particle Horizon-specific receivers such as the DACS and VisualEdge receivers require the appropriate licensed entitlement before they can start.

The licence mechanism can also report telemetry relating to:

• licence validity;
• licence expiry;
• remaining licence duration; and
• licence validation success or failure.

Sensitive licence information such as raw licence content and signatures is deliberately excluded from this telemetry.

Does the Collector need administrator or root access?

Not necessarily.

The required permissions depend on the monitoring integration.

The Collector service account only needs sufficient permissions to access the resources required by the enabled receivers.

For example, an integration might require:

• read access to particular application files;
• permission to connect to a database;
• permission to execute a vendor-provided diagnostic utility; or
• network access to a local or remote service.

Some host-based DACS monitoring requires permission to execute the locally installed set_debug utility.

Where possible, the Collector should operate using the principle of least privilege.

Is the Collector the monitoring platform?

No.

The Collector is one part of the Particle Horizon monitoring solution.

Its primary purpose is to collect and transport telemetry.

+---------------------+
| Customer Systems    |
+----------+----------+
           |
           v
+---------------------+
| PHO Collector       |
|                     |
| Collect             |
| Process             |
| Forward             |
+----------+----------+
           |
           v
+---------------------+
| Particle Horizon    |
| Observability       |
| Platform            |
+---------------------+

The central Particle Horizon platform is responsible for capabilities such as storing, analysing, visualising and alerting on the telemetry received from Collectors.

Can more than one Collector be deployed?

Yes.

Larger environments will commonly have multiple Collectors.

For example:

London
  ├── DACS Server -------- Collector
  ├── VisualEdge --------- Collector
  └── Application Hosts
           |
           v
      Collector

New York
  ├── DACS Server -------- Collector
  └── Application Hosts -- Collector

                |
                v

       Particle Horizon

Multiple Collectors allow monitoring to remain close to the systems being observed and avoid creating a dependency on a single collection point.

The number and placement of Collectors will be determined as part of the Particle Horizon solution design.

Collector security

The Collector should be treated as an infrastructure service and deployed using normal security best practices.

Customers should ensure that:

• the Collector runs using an appropriately restricted service account;
• configuration files containing credentials are protected;
• credentials are supplied using approved secret-management methods;
• unnecessary listener ports are not exposed;
• network access is restricted to the required sources and destinations;
• the Collector and its dependencies are kept at supported versions; and
• Collector configuration changes follow your organisation’s change-control process.

The standard configuration specifically warns against exposing Collector endpoints unnecessarily on all network interfaces and recommends binding services to the appropriate interface where required.

How do I know whether the Collector is working?

Depending on your deployment, Collector health may be visible through:

• Particle Horizon dashboards;
• Collector service status;
• Collector logs;
• telemetry freshness monitoring; and
• Collector health endpoints.

A functioning operating-system service does not necessarily mean that every configured source is being collected successfully.

For example:

Collector Service       RUNNING
DACS Collection         HEALTHY
VisualEdge Collection   HEALTHY
Telemetry Export        HEALTHY

or:

Collector Service       RUNNING
DACS Collection         NO DATA
VisualEdge Collection   HEALTHY
Telemetry Export        HEALTHY

The second example indicates a problem with one monitoring source rather than a failure of the Collector service itself.

What should I do if the Collector stops reporting data?

First determine whether the problem affects:

• a single monitored application;
• several monitored applications; or
• the entire Collector.

Useful checks include:

1. Confirm that the Collector service is running.
2. Check whether the monitored application is running.
3. Confirm that required local files or application interfaces remain available.
4. Check network connectivity to any remote sources.
5. Review the Collector logs for collection or export errors.
6. Confirm that the Particle Horizon licence is valid where licensed receivers are being used.
7. Contact your Particle Horizon support team if telemetry does not recover.

Do not include passwords, access tokens, private keys or licence files when providing diagnostic information to support.

Frequently Asked Questions

Does the Collector modify the applications it monitors?

Normally, no.

Collector receivers are designed primarily to read operational information from the configured source.

Any integration requiring an application-specific interaction will be documented as part of the deployment.

Will restarting the Collector restart my application?

No.

The Collector is a separate service from the monitored application.

Restarting it will temporarily interrupt telemetry collection but should not restart the monitored system.

What happens to monitoring while the Collector is stopped?

Telemetry that would normally have been collected during that period may be unavailable.

Monitoring resumes when the Collector starts and successfully reconnects to its configured sources.

Can I install one Collector for my entire organisation?

Possibly, but this is not always the best architecture.

Some integrations require access to resources located directly on the application server, and larger environments benefit from keeping telemetry collection close to monitored systems.

Your Particle Horizon solution design defines the appropriate Collector placement.

Can I change the Collector configuration myself?

Where customers manage their own Collector configuration, changes should follow the agreed Particle Horizon documentation and your organisation’s normal change-control procedures.

For managed deployments, contact your Particle Horizon support team before making configuration changes.

Does the Collector only support Particle Horizon components?

No.

The Collector is based on OpenTelemetry and includes a broad set of standard OpenTelemetry components in addition to Particle Horizon-specific integrations.

This provides a common telemetry collection architecture that can support both Particle Horizon integrations and compatible third-party or OpenTelemetry-enabled systems.

Summary

The Particle Horizon Collector is the component that connects your monitored systems to Particle Horizon.

Its role can be summarised as:

          COLLECT
             |
             v
          PROCESS
             |
             v
          FORWARD
             |
             v
       PARTICLE HORIZON

It provides a standard, extensible way to collect telemetry from applications and infrastructure without requiring each monitored system to integrate directly with the Particle Horizon platform.

For most customers, the Collector operates quietly as a background infrastructure service. Once installed and configured, it continuously gathers the telemetry required to give Particle Horizon visibility of the systems and services within your monitoring scope.