Architecture

Overview

Particle Horizon is an observability collection solution built on the OpenTelemetry Collector architecture.

It provides a locally deployed collection service that gathers operational telemetry from supported applications and infrastructure, converts that information into a standard telemetry format, and forwards it to the monitoring or observability platform configured for your environment.

The solution combines:

• The Particle Horizon Collector (pho-collector)
• Standard OpenTelemetry Collector components
• Particle Horizon-specific telemetry receivers
• A Particle Horizon licence validation component
• Customer-selected telemetry destinations

The Collector is designed to operate close to the systems being monitored. Depending on the integration being used, this may mean installing it directly on the monitored server or on another system with suitable network access.

High-Level Architecture

A typical deployment follows the architecture below:

flowchart LR
    subgraph CE["Customer Environment"]
        DACS["DACS<br/>PostgreSQL<br/>Local DACS processes"]
        VE["VisualEdge<br/>Installation metadata<br/>Licence information"]
        MO["MosaicOA PE<br/>Status endpoint<br/>Application metrics"]

        subgraph PHO["Particle Horizon Collector"]
            RX["Receivers"]
            PR["Processors"]
            EX["Exporters"]
            LIC["PHO Licence Extension"]

            RX --> PR --> EX
            LIC -. validates .-> RX
        end

        DACS --> RX
        VE --> RX
        MO --> RX
    end

    EX --> OBS["Customer Observability Platform"]

The exact components enabled within the Collector depend on the products being monitored and the configuration agreed for your deployment.

Particle Horizon Collector

The Particle Horizon Collector, installed as pho-collector, is the central component of the architecture.

It is a dedicated OpenTelemetry Collector distribution containing both standard OpenTelemetry functionality and Particle Horizon-specific components.

The Collector provides the runtime responsible for:

1. collecting telemetry;
2. converting source-specific information into structured telemetry;
3. processing and batching telemetry;
4. forwarding telemetry to the configured destination; and
5. providing health and operational telemetry about the Collector itself.

The Collector uses the standard OpenTelemetry pipeline model:

flowchart LR
    R["Receiver"] --> P["Processor"] --> E["Exporter"]

For example:

flowchart LR
    D["DACS"] --> DR["DACS Receiver"]
    DR --> BP["Batch Processor"]
    BP --> OE["OTLP Exporter"]
    OE --> OP["Observability Platform"]

This modular architecture allows Particle Horizon to support different monitored products without requiring a different monitoring platform for each application.

Receivers

A receiver is the part of Particle Horizon responsible for obtaining telemetry from a monitored system.

Receivers understand how to communicate with, inspect, or query a particular application.

Particle Horizon includes standard OpenTelemetry receivers as well as specialist receivers developed for supported products.

Only the receivers required for your environment need to be enabled.

DACS Receiver

The DACS receiver collects operational information from supported DACS components and converts it into OpenTelemetry metrics.

Depending on the DACS architecture, information can be obtained from several sources, including:

• DACS PostgreSQL databases
• dacs_svr
• Station daemon (dacs.stnd)
• DACS ESP
• Service Control Point (scp_main)
• Sink daemon (dacs.snkd)
• Local WAN daemon (dacs.wanl)
• Remote WAN daemon (dacs.wanr)

Some DACS information is obtained using the local DACS set_debug utility.

Where this collection method is enabled, the Collector must normally run on the server containing the relevant DACS process.

flowchart TB
    subgraph HOST["DACS Server"]
        SVR["dacs_svr"]
        STN["dacs.stnd"]
        ESP["dacs.esp"]
        SD["set_debug"]
        PHO["pho-collector<br/>DACS Receiver"]

        SVR --> SD
        STN --> SD
        ESP --> SD
        SD --> PHO
    end

    PHO --> OBS["Observability Platform"]

The Collector executes the supported local utility directly and interprets the resulting operational statistics.

Different metric groups can be enabled according to the monitoring requirements for the environment.

If a local DACS collection attempt fails, Particle Horizon does not manufacture a replacement value. Metrics from that source are omitted for that collection interval and the Collector retries automatically during the next interval.

Monitoring rules should therefore consider missing telemetry as well as metric values when determining service health.

DACS Database Collection

Where database collection is enabled, the DACS receiver can connect to a PostgreSQL data source.

flowchart LR
    DB["DACS PostgreSQL"] --> DR["pho-collector<br/>DACS Receiver"]
    DR --> OBS["Observability Platform"]

Database connectivity is validated when the relevant receiver starts.

Credentials should be provided using environment variables or an approved secrets-management mechanism rather than being stored directly in the Collector configuration.

VisualEdge Receiver

The VisualEdge receiver monitors information available from a local VisualEdge installation.

The receiver can inspect information such as:

• whether the expected VisualEdge installation is present;
• VisualEdge release information;
• VisualEdge licence information;
• remaining licence duration; and
• selected application installation metadata.

The Collector reads the configured VisualEdge installation paths rather than requiring an additional monitoring agent inside VisualEdge.

flowchart TB
    subgraph VEHOST["VisualEdge Server"]
        FILES["VisualEdge Application Files"]
        RX["pho-collector<br/>VisualEdge Receiver"]

        FILES --> RX
    end

    RX --> OBS["Observability Platform"]

Because the receiver reads local VisualEdge resources, the Collector should normally run on the VisualEdge server when this integration is enabled.

MosaicOA PE Receiver

Particle Horizon can collect telemetry from the MosaicOA PE status interface.

Unlike local filesystem-based VisualEdge collection, this receiver communicates with a configured MosaicOA status endpoint over HTTP or HTTPS.

flowchart LR
    MO["MosaicOA PE<br/>/status endpoint"] -->|"HTTP / HTTPS"| RX["pho-collector<br/>MosaicOA PE Receiver"]
    RX --> OBS["Observability Platform"]

The receiver can collect information including:

• processing statistics;
• topic statistics;
• update and DataView information;
• JVM heap and non-heap utilisation;
• processing timing information; and
• application version information.

Where configured, additional MosaicOA-related information can also be collected from InfluxDB.

flowchart LR
    MO["MosaicOA PE<br/>Status Endpoint"] --> RX["MosaicOA PE Receiver"]
    INF["InfluxDB<br/>Optional"] --> RX
    RX --> PROC["Processors"]
    PROC --> EXP["Exporter"]
    EXP --> OBS["Observability Platform"]

Failure of an optional InfluxDB query does not prevent the main MosaicOA status metrics from being collected.

OpenTelemetry Collection Pipeline

Once information has been collected by a receiver, Particle Horizon converts it into the OpenTelemetry data model.

The data then passes through a pipeline.

flowchart LR
    R["Receiver"] --> P["Processor"] --> E["Exporter"] --> O["Monitoring Platform"]

This separation is an important part of the Particle Horizon architecture.

The application-specific receiver does not need to understand the monitoring system that ultimately consumes the telemetry.

Likewise, the destination platform does not need to understand the native interface of every monitored application.

Particle Horizon provides the translation layer between them.

Processors

Processors operate on telemetry after it has been collected and before it is exported.

Depending on the customer configuration, processors may be used to perform functions such as:

• batching telemetry;
• adding or modifying resource attributes;
• filtering telemetry;
• transforming telemetry;
• limiting memory consumption;
• redacting selected information; or
• applying other OpenTelemetry processing rules.

A commonly used processor is the batch processor.

flowchart LR
    RX["Receiver"] --> B["Batch Processor"]
    B --> EX["Exporter"]

Batching groups telemetry before transmission, improving the efficiency of communication with the destination monitoring platform.

Exporters

Exporters send processed telemetry from Particle Horizon to another system.

Particle Horizon is built around the OpenTelemetry Collector ecosystem and can therefore support a range of exporter types depending on the deployment.

A common architecture is to use OTLP, the OpenTelemetry Protocol.

flowchart LR
    APP["Monitored Application"] --> PHO["Particle Horizon"]
    PHO -->|"OTLP"| GW["Observability Gateway"]
    GW --> MON["Metrics / Logs / Trace Platform"]

OTLP supports both:

• gRPC; and
• HTTP.

Particle Horizon may operate either directly against the destination platform:

flowchart LR
    APP["Application"] --> PHO["Particle Horizon"] --> OBS["Monitoring Platform"]

or as part of a larger OpenTelemetry architecture:

flowchart LR
    APP["Application"] --> PHO["Particle Horizon"]
    PHO --> GW["Central OpenTelemetry Gateway"]
    GW --> OBS["Customer Observability Platform"]

The gateway model can be useful where multiple servers or sites forward telemetry to a central telemetry service.

Collector Self-Monitoring

Particle Horizon also produces telemetry about the Collector itself.

This allows monitoring systems to distinguish between an application problem and a problem with the telemetry collection service.

Collector self-monitoring can include information relating to:

• Collector availability;
• telemetry received;
• telemetry processed;
• telemetry exported;
• failed exports;
• Collector resource utilisation; and
• Particle Horizon licence status.

flowchart LR
    APP["Application"] --> PHO["pho-collector"]
    PHO --> AT["Application Telemetry"]
    PHO --> CT["Collector Health Telemetry"]
    AT --> OBS["Observability Platform"]
    CT --> OBS

Monitoring the Collector itself is strongly recommended for production deployments.

Licensing Architecture

Particle Horizon-specific receivers use the Particle Horizon licence extension.

The licence extension is loaded by the Collector and validates the Particle Horizon licence before licensed components are allowed to operate.

flowchart TB
    LIC["Particle Horizon Licence"] --> LE["PHO Licence Extension"]

    subgraph COL["pho-collector"]
        LE
        DACS["DACS Receiver"]
        VE["VisualEdge Receiver"]
        MO["MosaicOA PE Receiver"]

        LE -. entitlement .-> DACS
        LE -. entitlement .-> VE
        LE -. entitlement .-> MO
    end

A licence can grant access to specific Particle Horizon components.

Licensed receivers validate that the required entitlement is available when they start.

Licence validity is also exposed as Collector self-telemetry, allowing expiry or validation problems to be monitored proactively.

The licence monitoring architecture exposes operational licence state rather than sensitive licence contents.

Network Architecture

Network requirements depend on the receivers and exporters enabled in the deployment.

Particle Horizon should be deployed using the principle of least network privilege.

Only communication paths required by the configured integration should be permitted.

flowchart LR
    DB["PostgreSQL"] --> PHO["pho-collector"]
    MO["MosaicOA PE"] --> PHO
    PHO -->|"OTLP / TLS"| OBS["Observability Platform"]

Where local collection methods are used, no network connection is required between the receiver and the local application component.

For DACS:

flowchart LR
    SD["DACS set_debug"] -->|"Local process execution"| PHO["pho-collector"]

For VisualEdge:

flowchart LR
    VF["VisualEdge Files"] -->|"Local filesystem access"| PHO["pho-collector"]

This reduces unnecessary application network exposure.

Standard OpenTelemetry Interfaces

The base Collector distribution can expose standard OpenTelemetry interfaces where they are enabled in the customer’s configuration.

Common interfaces include:

Not every deployment requires these interfaces.

Where an interface is not required, it should not be exposed.

Where network listeners are enabled, they should be bound only to the interfaces required by the deployment and protected using the customer’s standard host firewall and network-security controls.

Deployment Architecture

Particle Horizon is distributed as a standalone application.

Linux deployments can be provided as:

• RPM packages;
• DEB packages; or
• compressed archive distributions.

Windows deployments can be provided as compressed archives.

The Linux installation architecture separates application binaries, configuration, local data and logs.

flowchart TB
    ROOT["/opt/particle_horizon"]

    ROOT --> SW["SOFTWARE"]
    ROOT --> LINK["pho-collector"]
    ROOT --> CFG["local_config"]
    ROOT --> DATA["local_data"]
    ROOT --> LOGS["logs"]

    SW --> VER["pho-collector-<version>"]
    VER --> BIN["bin/pho-collector"]
    VER --> INFO["BUILD_INFO.txt"]
    VER --> NOTICE["THIRDPARTY_NOTICES"]

    CFG --> PCFG["pho-collector/config.yaml"]
    DATA --> PDATA["pho-collector/"]
    LOGS --> PLOG["pho-collector/"]

Versioned software directories allow the installed software release to remain separate from customer-specific configuration and operational data.

This separation simplifies maintenance and upgrades.

Security Architecture

Particle Horizon is intended to operate as part of the customer’s existing security architecture rather than bypassing it.

Customers should apply their normal controls for:

• server hardening;
• filesystem permissions;
• service-account permissions;
• secrets management;
• firewall policies;
• TLS certificates;
• outbound connectivity;
• application access; and
• central logging.

Credentials

Passwords, access tokens and similar secrets should not be placed directly into configuration files.

Environment variables or the customer’s approved secrets-management solution should be used instead.

Local Permissions

Some receivers require access to local application resources.

flowchart LR
    SA["Particle Horizon Service Account"] --> DACS["Execute approved DACS set_debug utility"]
    SA --> VE["Read configured VisualEdge files"]

The service account running Particle Horizon should be granted only the permissions required for the enabled receivers.

Network Listeners

Collector interfaces should not automatically be exposed to untrusted networks.

Where OTLP, diagnostic, health or metrics endpoints are required, network access should be restricted to the systems that require them.

TLS

Where Particle Horizon communicates with remote application endpoints or external telemetry platforms, TLS should be used wherever supported.

Customer certificate authorities can be configured where private PKI is used.

Telemetry Flow

A complete telemetry flow can be represented as:

flowchart TB
    SRC["Source Systems"]

    SRC --> LS["Local Sources"]
    SRC --> NS["Network Sources"]

    LS --> RX["Particle Horizon Receivers"]
    NS --> RX

    RX --> OTel["OpenTelemetry Metrics"]
    OTel --> PROC["Processors"]
    PROC --> EXP["Exporters"]
    EXP --> OBS["Observability Platform"]
    OBS --> OUT["Dashboards / Alerts / Reporting"]

The Collector provides the boundary between application-specific collection and standardised observability telemetry.

Failure Isolation

Particle Horizon is designed so that individual telemetry sources can fail without necessarily causing the entire monitoring service to stop.

flowchart LR
    DACS["DACS Local Collection"] -. failed scrape .-> PHO["pho-collector"]
    DB["PostgreSQL Collection"] --> PHO
    VE["VisualEdge Collection"] --> PHO
    PHO --> OBS["Observability Platform"]

A failed scrape generally affects the current collection interval for that source.

Other configured receivers and pipelines can continue to operate.

Where telemetry cannot be collected safely, the preferred behaviour is generally to omit that telemetry and record the collection failure rather than report an artificial value that could incorrectly indicate that the application is healthy.

Collection Intervals

Particle Horizon uses scheduled collection intervals for polling-based receivers.

sequenceDiagram
    participant A as Application
    participant R as Receiver
    participant O as Observability Platform

    loop Every configured collection interval
        R->>A: Collect telemetry
        A-->>R: Return source data
        R->>O: Export processed telemetry
    end

Different sources can have different collection intervals.

The appropriate interval depends on:

• how quickly the underlying state changes;
• how quickly an operational problem must be detected;
• the cost of querying the application;
• network utilisation;
• database load; and
• the monitoring platform’s data-retention model.

Collection intervals should therefore be agreed as part of the deployment design rather than reduced unnecessarily.

Component Responsibilities

Customer Responsibilities

The customer is normally responsible for the surrounding infrastructure in which Particle Horizon operates.

This includes:

• providing a supported operating environment;
• providing network connectivity where required;
• maintaining firewall rules;
• providing application credentials where required;
• maintaining the operating-system service account;
• providing appropriate filesystem permissions;
• providing certificates and trusted CA chains where required;
• providing connectivity to the chosen observability platform; and
• protecting configuration files and credentials according to organisational security policy.

Particle Horizon configuration should be treated as infrastructure configuration and managed through the customer’s normal change-management processes.

Particle Horizon Responsibilities

Particle Horizon provides the collection layer between supported applications and the customer’s observability platform.

This includes:

• the pho-collector distribution;
• supported Particle Horizon receivers;
• telemetry normalisation;
• supported Collector components;
• application-specific metric interpretation;
• Particle Horizon licensing functionality; and
• release packages and associated software metadata.

The Collector is deliberately separate from the destination monitoring product.

This enables the telemetry architecture to evolve independently from the monitored application.

Architectural Benefits

Standardised telemetry

Application-specific information is converted into OpenTelemetry-compatible telemetry before leaving the Collector.

Localised collection

Receivers can be deployed close to the monitored application, including directly on the application host where local access is required.

Reduced application coupling

The monitored application does not need to integrate directly with the customer’s observability platform.

Flexible telemetry destinations

OpenTelemetry exporters allow the downstream monitoring architecture to be changed without redesigning application-specific collection.

Failure isolation

An issue with one telemetry source does not necessarily interrupt collection from other configured sources.

Secure deployment

Network access, credentials and operating-system permissions can be restricted to the interfaces required by the enabled integrations.

Extensible architecture

Additional Particle Horizon receivers can be incorporated into the same Collector architecture as support for new applications is introduced.

Summary

Particle Horizon acts as an observability integration layer between supported customer applications and modern monitoring platforms.

flowchart LR
    APP["Customer Applications"] --> PHO["Particle Horizon Collector<br/><br/>Receivers<br/>Processors<br/>Exporters"]
    PHO --> OBS["Customer Observability Platform"]

Receivers handle the application-specific collection work, while the OpenTelemetry Collector provides a standard mechanism for processing and exporting the resulting telemetry.

This approach provides a common monitoring architecture across supported platforms while allowing each integration to use the most appropriate and least intrusive method of obtaining operational information.