Networking Requirements

Overview

Particle Horizon Collector (pho-collector) is an observability collector installed within your environment. It gathers supported operational and application metrics and processes them using the OpenTelemetry Collector framework.

Depending on the components enabled within your deployment, the Collector may:

• Receive telemetry from systems on your network.
• Connect to a DACS PostgreSQL database.
• Connect to an HTTPS/SOAP service where specifically configured.
• Collect information directly from software installed on the same server.
• Forward telemetry to an upstream monitoring or observability platform where configured.

The exact network access required depends on your deployment configuration. You should permit only the connections required by the components you have enabled.

Network Requirements Summary

• The SOAP service port is defined by the configured endpoint and may therefore differ from TCP 443.

Important: Do not create firewall rules for components that are not enabled in your deployment.

1. DNS Requirements

The Collector host must be able to resolve any DNS names used within its configuration.

This normally includes:

• The DACS PostgreSQL server hostname.
• Any configured SOAP endpoint.
• Any upstream telemetry or monitoring endpoint.
• Internal proxy servers, where applicable.

Your normal corporate DNS infrastructure may be used.

There is no requirement to use public DNS where all configured services are internally hosted and resolvable.

2. DACS PostgreSQL Connectivity

When DACS PostgreSQL collection is enabled, the Collector establishes a connection from the Collector host to the configured PostgreSQL server.

A typical configuration uses:

Collector -> DACS PostgreSQL Server -> TCP 5432

Firewall requirement

Permit:

SOURCE:
Particle Horizon Collector

DESTINATION:
Configured DACS PostgreSQL server

PROTOCOL:
TCP

DESTINATION PORT:
5432

TCP 5432 is the normal PostgreSQL port. If your PostgreSQL service uses a non-standard port, permit the port configured in the Collector instead.

Example

For a database endpoint such as:

postgresql://dacs-db.internal:5432/dacs

the Collector must be able to establish a TCP connection to:

dacs-db.internal:5432

The Collector validates PostgreSQL connectivity during startup. Incorrect credentials, DNS resolution problems, routing problems, or firewall restrictions can therefore prevent the DACS PostgreSQL receiver from starting.

Recommended security controls

Where possible:

• Restrict the firewall rule to the Collector host or Collector subnet.
• Restrict database access to the specific PostgreSQL server.
• Use a dedicated database account for monitoring.
• Grant the account only the database permissions required for metric collection.
• Use encrypted PostgreSQL connectivity where supported by your environment.

Avoid permitting unrestricted access from the Collector to an entire database network where a more specific rule can be used.

3. DACS Host-Local Collection

Particle Horizon can collect information directly from supported DACS processes using the locally installed DACS set_debug utility.

Examples include:

• DACS Server
• DACS Station Daemon
• DACS ESP
• DACS SCP
• DACS Sink Daemon
• DACS WANL
• DACS WANR

These components execute locally on the server hosting the relevant DACS process.

Network requirement

No additional firewall port is normally required for this collection method.

Communication takes place between the Collector and software installed on the same server.

For example:

pho-collector
      |
      | Local process execution
      v
/reuters/dacs/tools/set_debug
      |
      v
Local DACS Process

The Collector service account must instead have appropriate local operating-system permissions to execute the configured set_debug binary.

Some DACS components may reside on different servers. In this situation, a Collector instance is normally deployed on the corresponding host rather than opening a remote set_debug connection.

4. VisualEdge Collection

The VisualEdge receiver obtains installation, release and licence information directly from the local VisualEdge installation.

It reads configured locations such as:

/opt/VisualEdge/server/webapps/ROOT/VisualEdgeUI
/opt/VisualEdge/server/webapps/ROOT/VisualEdgeServlet/WEB-INF/lib
/opt/VisualEdge/licence.txt

Network requirement

No additional inbound or outbound network access is required solely for VisualEdge collection.

The Collector requires local filesystem access to the configured VisualEdge installation paths.

5. SOAP / HTTPS Collection

Particle Horizon includes support for configuring a DACS SOAP source.

This integration should only be enabled where instructed as part of your deployment.

When enabled, the connection is initiated by the Collector:

Particle Horizon Collector
        |
        | HTTPS
        v
Configured SOAP Endpoint

For an endpoint such as:

https://dacs-ui.internal/metrics

the expected firewall rule would normally be:

SOURCE:
Particle Horizon Collector

DESTINATION:
dacs-ui.internal

PROTOCOL:
TCP

DESTINATION PORT:
443

If the URL contains another port, permit that destination port instead.

The current standard configuration leaves SOAP collection disabled unless it is explicitly required.

6. Receiving OpenTelemetry Data

The Collector can receive OpenTelemetry telemetry from applications or other OpenTelemetry-compatible systems.

The standard Collector configuration provides both:

OTLP over gRPC

TCP 4317

OTLP over HTTP

TCP 4318

These ports are only required when another system will send telemetry directly to the Collector.

For example:

Application Server
       |
       | OTLP/gRPC TCP 4317
       v
Particle Horizon Collector

or:

Application Server
       |
       | OTLP/HTTP TCP 4318
       v
Particle Horizon Collector

Recommended firewall configuration

Do not expose these ports to networks that do not need to submit telemetry.

Where possible, restrict inbound access to:

• Known application servers.
• Known monitoring agents.
• Required application subnets.

These interfaces should not normally be exposed directly to the public Internet.

7. Collector Administrative and Diagnostic Interfaces

The standard Collector configuration may contain internal health and diagnostic interfaces.

These can include:

These interfaces are intended for administration and troubleshooting and should not normally be exposed to untrusted networks.

Where they are required:

• Bind them to a management or loopback interface where possible.
• Restrict access using host or network firewalls.
• Permit access only from authorised monitoring or administration systems.

A deployment may disable or change these listeners.

8. Outbound Telemetry Connectivity

After collecting telemetry, Particle Horizon may be configured to forward it to another observability platform or Collector.

For example:

Customer Environment

DACS / VisualEdge / Applications
              |
              v
      Particle Horizon Collector
              |
              | Outbound telemetry
              v
      Monitoring Platform

The destination, protocol and port depend on the telemetry platform selected for your service.

Common examples include:

Your implementation documentation will identify the actual destination required for your environment.

Do not create generic Internet access rules solely on the basis of the examples above.

9. Internet Access

The Collector itself does not require unrestricted Internet access simply to collect local DACS or VisualEdge telemetry.

Internet access may, however, be required where your deployment forwards telemetry to a cloud-hosted monitoring service.

Where outbound Internet access is required, we recommend permitting the specific destination hostname or service rather than allowing unrestricted outbound connectivity.

For example:

Collector
   |
   | TCP 443
   v
Approved telemetry destination

10. Proxy Servers

If your organisation requires outbound HTTPS connections to pass through a proxy server, provide the relevant proxy configuration during deployment.

The following information may be required:

• Proxy hostname.
• Proxy TCP port.
• Whether authentication is required.
• Any destinations excluded from proxying.
• Whether your organisation performs TLS inspection.

Internal connections such as PostgreSQL normally continue to use direct network connectivity unless your network architecture explicitly routes those protocols through another service.

11. TLS Inspection

Where HTTPS traffic passes through TLS inspection, the Collector host must trust the certificate authority used by your organisation’s inspection platform.

Failure to trust the inspection certificate can result in TLS errors when connecting to HTTPS endpoints.

If TLS inspection causes connectivity problems, your security team may need either to:

• Add the relevant enterprise CA certificate to the Collector host’s trusted certificate store; or
• Exclude the approved telemetry destination from TLS inspection.

The appropriate option depends on your organisation’s security policy.

12. Network Address Translation

NAT is supported provided that:

• The Collector can initiate the required outbound connections.
• Return traffic is permitted.
• Any access-control lists at the destination recognise the translated source address where source-IP restrictions are used.

Inbound NAT is not normally required unless external systems specifically need to send OTLP telemetry to a Collector located behind NAT.

13. Firewall Recommendations

Where practical, use least-privilege firewall rules.

Instead of:

Collector -> ANY -> ANY

use rules such as:

Collector -> DACS-DB-01 -> TCP 5432

and:

Application-Subnet -> Collector -> TCP 4317

This reduces the Collector’s network exposure and simplifies security review.

14. Example Deployment

A typical deployment using DACS PostgreSQL collection could look like:

                         Customer Network
+--------------------------------------------------------------+
|                                                              |
|  DACS Server                                                 |
|      |                                                       |
|      | Local set_debug                                       |
|      v                                                       |
|  +----------------------+                                    |
|  | Particle Horizon     |                                    |
|  | Collector            |                                    |
|  +----------+-----------+                                    |
|             |                                                |
|             | TCP 5432                                       |
|             v                                                |
|       +-----------+                                          |
|       | DACS      |                                          |
|       | PostgreSQL|                                          |
|       +-----------+                                          |
|                                                              |
|             |                                                |
|             | Optional outbound telemetry                    |
|             | TCP 443 / configured protocol                  |
+-------------|------------------------------------------------+
              |
              v
      Monitoring Platform

In this example:

1. Local DACS metrics require no additional network firewall rule.
2. The Collector requires TCP 5432 to the DACS PostgreSQL server.
3. Any external monitoring destination requires the corresponding outbound firewall rule.
4. OTLP TCP 4317/4318 is only opened if applications send telemetry to the Collector.

15. Information Required From Your Network Team

Before installation, confirm the following:

• The Collector server can resolve the required DNS names.
• The Collector can reach the configured DACS PostgreSQL server.
• TCP 5432, or the configured PostgreSQL port, is permitted where PostgreSQL collection is enabled.
• Required OTLP ports are permitted if systems will send telemetry to the Collector.
• Any required external telemetry destination is reachable.
• Required HTTPS destinations are permitted through your firewall or proxy.
• Proxy configuration has been provided where required.
• TLS inspection requirements have been identified.
• Diagnostic Collector ports are not unnecessarily exposed to untrusted networks.

16. Troubleshooting Network Connectivity

PostgreSQL receiver does not start

Check:

1. DNS resolution for the database hostname.
2. TCP connectivity to the configured PostgreSQL port.
3. Firewall rules between the Collector and database server.
4. Database credentials.
5. PostgreSQL access-control rules.
6. TLS configuration, if encrypted database connectivity is used.

On Linux, your administrator may use an appropriate connectivity test such as:

nc -vz <database-hostname> 5432

A successful TCP test confirms network reachability but does not validate database credentials.

OTLP telemetry is not reaching the Collector

Check:

1. The sending system is using the correct Collector hostname.

2. The sender is using the correct protocol:

   • gRPC — TCP 4317
   • HTTP — TCP 4318

3. The required Collector receiver is enabled.

4. The host firewall permits the connection.

5. Any intermediate firewall or network ACL permits the connection.

HTTPS connection fails

Check:

1. DNS resolution.
2. TCP 443 connectivity.
3. Proxy requirements.
4. TLS inspection.
5. Trusted certificate authorities.
6. The hostname and port configured for the destination.

Security Recommendation

Only expose the interfaces that are required for your deployment.

In particular:

• Do not expose Collector diagnostic interfaces to the Internet.
• Restrict OTLP ingestion to trusted systems.
• Limit PostgreSQL access to the required database server.
• Prefer destination-specific outbound firewall rules.
• Use encrypted protocols where supported.
• Store credentials using the deployment’s approved secret-management mechanism rather than directly in configuration files.

Your Particle Horizon implementation team can provide the final source, destination and port matrix for your specific deployment where additional integrations or exporters are enabled.