Agents vs. Gateways

The Particle Horizon Collector can be deployed in different locations across your environment depending on where telemetry needs to be collected and how it should be transported.

Two common deployment patterns are Agents and Gateways.

Both patterns use the same underlying Collector technology. The difference is primarily where the Collector runs, what it collects, and where it sends telemetry.

This guide explains the difference and helps you decide which pattern is appropriate for your environment.

Overview

At a high level:

• An Agent runs close to the system or application being monitored.
• A Gateway runs as a shared telemetry service and receives data from multiple Agents, applications, or other telemetry sources.

A typical deployment looks like this:

flowchart TB
    A["Application / Host<br/>PHO Collector Agent"]
    B["Application / Host<br/>PHO Collector Agent"]
    G["PHO Collector Gateway"]
    O["Observability Platform"]

    A -->|OTLP| G
    B -->|OTLP| G
    G --> O

You do not always need both layers. Smaller environments may send telemetry directly from an Agent to its destination, while larger environments commonly use one or more Gateways.

What is an Agent?

An Agent is a Collector deployed close to the workload or infrastructure from which telemetry is collected.

This normally means running the Collector:

• on the same server as an application;
• on the same server as a monitored product;
• alongside a workload;
• or within the same local environment where access to files, processes, commands, or local endpoints is required.

The Agent performs collection as close to the telemetry source as possible.

For example:

flowchart TB
    subgraph DACS["DACS Server"]
        D["DACS Processes"]
        A["Particle Horizon Collector<br/>Agent"]
        D --> A
    end

    A -->|OTLP| U["Gateway or Backend"]

This is particularly important for receivers that depend on information available only on the local machine.

For example, some Particle Horizon components require access to local installation files or executables. The DACS receiver configuration includes sources that execute /reuters/dacs/tools/set_debug and therefore require the Collector to run on the appropriate DACS server.

Similarly, the VisualEdge receiver reads installation information from local filesystem locations such as /opt/VisualEdge/....

These are natural Agent deployments.

What does an Agent do?

An Agent commonly performs one or more of the following functions:

• collects telemetry from the local operating system;
• queries locally accessible applications or services;
• reads local files;
• executes local monitoring commands;
• receives telemetry from applications running on the same host;
• performs initial telemetry processing;
• batches telemetry;
• forwards telemetry to a Gateway or backend.

For example:

flowchart TB
    A["Application"]
    AG["PHO Collector Agent"]
    GW["PHO Collector Gateway"]

    A -->|OTLP| AG
    AG -->|Process and Batch| GW

The Collector supports pipelines made from receivers, processors, and exporters. The standard PHO Collector configuration includes OTLP receivers for traces, metrics, and logs together with a batch processor.

When should I use an Agent?

Use an Agent when telemetry collection requires access to something local to the monitored system.

Typical examples include:

An Agent is especially useful when you want the monitored host to establish the outbound connection rather than exposing the monitored workload directly to a central telemetry system.

What is a Gateway?

A Gateway is a centrally or regionally deployed Collector that receives telemetry from other systems.

Instead of being associated with a single monitored host, it normally services multiple Agents or applications.

For example:

flowchart LR
    A1["Agent A"]
    A2["Agent B"]
    A3["Agent C"]
    A4["Agent D"]
    APP["Application"]

    G["PHO Collector Gateway"]
    B["Backend"]

    A1 --> G
    A2 --> G
    A3 --> G
    A4 --> G
    APP --> G
    G --> B

A Gateway therefore becomes an aggregation point within the observability architecture.

Applications and Agents can send telemetry to the Gateway using protocols such as OpenTelemetry Protocol (OTLP).

The PHO Collector includes OTLP receivers for both:

• OTLP/gRPC
• OTLP/HTTP

The supplied Collector configuration listens on the standard OTLP ports:

• 4317 - OTLP/gRPC
• 4318 - OTLP/HTTP

What does a Gateway do?

A Gateway typically performs functions such as:

• receiving telemetry from multiple Agents;
• receiving telemetry directly from instrumented applications;
• centralising telemetry processing;
• batching data before export;
• applying shared telemetry policies;
• forwarding telemetry to one or more observability destinations;
• reducing the number of systems that require direct connectivity to a backend.

A Gateway might therefore sit between your monitored infrastructure and your central observability platform.

flowchart TB
    A1["Agent"]
    A2["Agent"]
    A3["Application"]
    G["PHO Collector Gateway<br/><br/>Receive<br/>Process<br/>Batch<br/>Export"]
    O["Observability Backend"]

    A1 --> G
    A2 --> G
    A3 --> G
    G --> O

Agent vs. Gateway

The main differences are summarised below.

The same Collector can perform either role

Agent and Gateway are deployment roles, rather than completely different Collector products.

The Particle Horizon Collector is a standalone OpenTelemetry Collector distribution.

Its behaviour is determined by its configuration.

For example, a Collector configured with a local product receiver could act as an Agent:

receivers:
  dacsreceiver:
    dacs_svr:
      enabled: true
      tool_path: /reuters/dacs/tools/set_debug

processors:
  batch: {}

exporters:
  otlp:
    endpoint: telemetry-gateway.example.com:4317

service:
  pipelines:
    metrics:
      receivers: [dacsreceiver]
      processors: [batch]
      exporters: [otlp]

Conceptually:

flowchart LR
    D["DACS"]
    R["dacsreceiver"]
    B["batch"]
    E["OTLP exporter"]
    G["Gateway"]

    D --> R --> B --> E --> G

By contrast, a Gateway would normally receive OTLP data:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch: {}

exporters:
  # Your destination exporter configuration

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters:
        - <destination>

The exact exporters available depend on the Particle Horizon Collector distribution and your deployed configuration.

Agent-only architecture

A Gateway is not mandatory.

For smaller deployments, an Agent can send telemetry directly to the final destination.

flowchart LR
    H["Host<br/>PHO Agent"]
    B["Observability Backend"]

    H --> B

This architecture has fewer components and can be appropriate when:

• the environment is small;
• only a small number of Agents are deployed;
• every Agent can securely reach the destination;
• central processing is not required.

As the number of monitored systems increases, however, a Gateway layer can simplify connectivity and telemetry management.

Agent and Gateway architecture

Larger installations will often use both roles.

flowchart TB
    subgraph SA["Site A"]
        A1["Agent<br/>Server 1"]
        A2["Agent<br/>Server 2"]
        GA["Gateway A"]

        A1 --> GA
        A2 --> GA
    end

    O["Observability Platform"]

    subgraph SB["Site B"]
        B1["Agent<br/>Server 3"]
        B2["Agent<br/>Server 4"]
        GB["Gateway B"]

        B1 --> GB
        B2 --> GB
    end

    GA --> O
    GB --> O

This makes it possible to place Gateways at appropriate network boundaries, sites, data centres, or other aggregation points.

Why use a Gateway?

A Gateway architecture offers several operational benefits.

Centralised connectivity

Without a Gateway:

flowchart LR
    A1["Agent 1"] --> B["Backend"]
    A2["Agent 2"] --> B
    A3["Agent 3"] --> B
    A4["Agent 4"] --> B
    A5["Agent 5"] --> B

Every Agent requires connectivity to the backend.

With a Gateway:

flowchart LR
    A1["Agent 1"] --> G["Gateway"]
    A2["Agent 2"] --> G
    A3["Agent 3"] --> G
    A4["Agent 4"] --> G
    A5["Agent 5"] --> G

    G --> B["Backend"]

Only the Gateway requires upstream connectivity to the destination.

This can simplify firewall rules and network architecture.

Centralised processing

Telemetry processing that applies to the whole environment can be performed at the Gateway rather than being repeated on every Agent.

This allows responsibilities to be separated:

flowchart LR
    A["Agent<br/><br/>Collection<br/>Lightweight processing<br/>Forwarding"]
    G["Gateway<br/><br/>Aggregation<br/>Shared processing<br/>Routing<br/>Export"]

    A --> G

Exactly where processing should occur depends on the requirements of your environment.

Isolation from backend changes

Agents can send telemetry to a stable Gateway endpoint.

The Gateway can then control how that telemetry is sent onwards.

Conceptually:

flowchart LR
    A1["Agent"]
    A2["Agent"]
    A3["Agent"]

    G["Gateway"]
    B1["Backend A"]
    B2["Backend B"]

    A1 --> G
    A2 --> G
    A3 --> G

    G --> B1
    G --> B2

This can reduce the number of Agent configurations that need to change when telemetry destinations change.

Why use Agents?

Gateways cannot replace Agents where telemetry must be collected locally.

Consider a component that reads:

/opt/VisualEdge/...

A remote Gateway cannot normally access that filesystem.

The Collector therefore needs to run on or near the VisualEdge installation.

The Particle Horizon VisualEdge receiver is designed to read local VisualEdge installation metadata and emit metrics describing installation availability, release metadata, and licence state.

Likewise, some DACS sources require the Collector to execute a locally installed DACS utility. These sources require local access to:

/reuters/dacs/tools/set_debug

In these scenarios, the Agent performs the local collection and forwards the resulting telemetry.

Choosing where a receiver runs

One of the easiest ways to decide between Agent and Gateway deployment is to ask:

Does this receiver need access to the monitored machine?

If the answer is yes, it normally belongs on an Agent.

flowchart LR
    F["Local file receiver"] --> A1["Agent"]
    C["Local command receiver"] --> A2["Agent"]
    H["Host-specific product receiver"] --> A3["Agent"]

If the receiver simply accepts telemetry over the network, it may be suitable for a Gateway:

flowchart LR
    A1["Application"]
    A2["Application"]
    A3["Agent"]

    G["Gateway<br/>OTLP Receiver"]

    A1 -->|OTLP| G
    A2 -->|OTLP| G
    A3 -->|OTLP| G

Some receivers can operate in either location depending on network accessibility and architecture.

For example, a receiver querying PostgreSQL does not necessarily need to be installed on the database server. It only requires appropriate network access and credentials.

Security considerations

Agent and Gateway deployments have different network exposure.

Agents

Where possible, Agents should minimise exposed network listeners.

If applications on the host send telemetry to the Agent, listeners can be restricted to appropriate interfaces.

Gateways

Gateways deliberately receive telemetry over the network and therefore require appropriately controlled inbound connectivity.

The default PHO Collector configuration exposes OTLP receivers on:

0.0.0.0:4317
0.0.0.0:4318

The default configuration also warns that binding services to 0.0.0.0 increases network exposure and recommends binding endpoints to a specific interface where appropriate.

Production deployments should therefore consider:

• network segmentation;
• firewall rules;
• interface binding;
• encryption;
• authentication where applicable;
• limiting access to known telemetry producers.

See the Networking Requirements documentation for deployment-specific network guidance.

Do I need a Gateway for every Agent?

No.

Multiple Agents normally share a Gateway.

flowchart LR
    A1["Agent 01"] --> G["Gateway"]
    A2["Agent 02"] --> G
    A3["Agent 03"] --> G
    A4["Agent 04"] --> G
    A5["Agent 05"] --> G
    A6["Agent 06"] --> G
    A7["Agent 07"] --> G

The appropriate Agent-to-Gateway ratio depends on factors such as:

• telemetry volume;
• available CPU and memory;
• network capacity;
• geographic distribution;
• availability requirements;
• failure-domain design.

There is therefore no universal requirement for one Gateway per site or a fixed number of Agents per Gateway.

Can applications send directly to a Gateway?

Yes.

An Agent is not required when an application can already emit telemetry using a protocol accepted by the Gateway.

flowchart LR
    A["Instrumented Application<br/>OpenTelemetry SDK"]
    G["PHO Gateway"]

    A -->|OTLP| G

The PHO Collector’s standard OTLP receiver supports both gRPC and HTTP endpoints.

A mixed architecture is also possible:

flowchart LR
    APP["Application"]
    A1["Agent"]
    A2["Agent"]
    G["Gateway"]
    B["Backend"]

    APP --> G
    A1 --> G
    A2 --> G
    G --> B

Can one Collector act as both?

Technically, a Collector can perform local collection while also receiving telemetry from other systems.

For example:

flowchart LR
    L["Local Receiver"]
    R["Remote OTLP"]
    C["Collector"]
    B["Backend"]

    L --> C
    R --> C
    C --> B

However, for larger environments it is usually easier to reason about, secure, and scale the platform when Agent and Gateway responsibilities are clearly separated.

This also allows each role to be sized and maintained independently.

Recommended deployment approach

For most enterprise deployments, use the following pattern:

flowchart LR
    S["Monitored Systems"]
    A["PHO Collector Agents"]
    G["PHO Collector Gateways"]
    O["Observability Platform"]

    S --> A
    A -->|OTLP| G
    G --> O

Deploy an Agent where local collection is required.

Deploy a Gateway where telemetry from multiple sources needs to be aggregated, processed, routed, or exported centrally.

Applications capable of exporting OTLP directly may send telemetry directly to a Gateway instead of using a local Agent.

Example: DACS deployment

A DACS installation may require an Agent because some DACS telemetry sources depend on software installed locally.

flowchart TB
    subgraph D["DACS Server"]
        DP["DACS"]
        A["PHO Collector Agent"]

        DP -->|Local command| A
    end

    G["PHO Gateway"]
    O["Observability Platform"]

    A -->|OTLP| G
    G --> O

The Agent can collect DACS-specific metrics, while the Gateway provides the central telemetry aggregation layer.

Example: VisualEdge deployment

VisualEdge telemetry can require access to installation files on the VisualEdge server.

flowchart TB
    subgraph V["VisualEdge Server"]
        F["/opt/VisualEdge/..."]
        A["PHO Collector Agent"]

        F --> A
    end

    G["PHO Gateway"]
    O["Observability Platform"]

    A -->|OTLP| G
    G --> O

The local Agent reads the installation data and converts it into telemetry before forwarding it upstream.

Example: Application telemetry

An application already instrumented with OpenTelemetry may not require an Agent.

flowchart LR
    A["Application<br/>OpenTelemetry SDK"]
    G["PHO Gateway"]
    O["Observability Platform"]

    A -->|OTLP| G
    G --> O

Alternatively, the application may send telemetry to a local Agent first:

flowchart LR
    A["Application"]
    AG["PHO Agent"]
    G["PHO Gateway"]

    A -->|OTLP| AG
    AG -->|OTLP| G

The preferred pattern depends on your networking, processing, and operational requirements.

Decision guide

Use the following questions when designing your deployment.

A useful rule of thumb is:

Collect locally. Aggregate centrally.

Summary

Agents and Gateways use the same Particle Horizon Collector technology but fulfil different roles.

An Agent runs close to the monitored workload and is best suited to local telemetry collection.

A Gateway provides a shared endpoint that receives telemetry from multiple Agents or applications and forwards it towards the required destination.

For many environments, the preferred architecture is:

flowchart LR
    S["Source"]
    A["Agent"]
    G["Gateway"]
    O["Observability Platform"]

    S --> A
    A --> G
    G --> O

Not every source requires an Agent, and not every environment requires a Gateway. The correct design depends on where telemetry originates, what local access is required, and how telemetry must cross your network.

When deciding between the two, start with one question:

Does the Collector need to be close to the monitored system in order to collect the data?

If yes, deploy an Agent.

If the Collector primarily receives and aggregates telemetry from other systems, deploy it as a Gateway.