Particle Horizon Collector v0.2

The 0.2.x release line turns pho-collector into a broader Particle Horizon observability distribution: it adds the MosaicOA PE and VisualEdge receivers to the existing DACS capability, keeps proprietary components behind the Particle Horizon licence extension, corrects Linux service packaging, and then substantially expands and refreshes the upstream OpenTelemetry Collector component set.

Current 0.2.x recommendation: use 0.2.2 for new deployments. It contains the functionality introduced throughout the 0.2.x line together with the OpenTelemetry 0.156.0 dependency refresh and the expanded bundled component catalogue.

At a glance

0.2.0 — Custom receiver expansion

Release date: 9 July 2026

0.2.0 is the main functional release in the 0.2.x series. It promotes the collector and the Particle Horizon component module from the beta line to stable 0.2.0 pins and makes the new MosaicOA PE and VisualEdge receivers part of the standalone distribution.

Added: MosaicOA PE receiver

First shipped in pho-collector: 0.2.0

The new mosaicoapereceiver polls a MosaicOA PE status endpoint and translates its comma-separated status output into OpenTelemetry metrics and bounded resource attributes.

Key capabilities include:

• Configurable http or https scheme, host, port, path, scrape timeout, and collection interval.
• TLS configuration for CA trust, client certificates, and verification behaviour.
• Topic-level metrics:
  • mosaicoa.pe.topic.records
  • mosaicoa.pe.topic.polls
• Numeric summary metrics including:
  • mosaicoa.pe.xpaths.total
  • mosaicoa.pe.summary_xpaths.total
  • mosaicoa.pe.updates.total
  • mosaicoa.pe.dataviews.total
  • mosaicoa.pe.mods
  • mosaicoa.pe.cimp.points_written
  • mosaicoa.pe.gc.avg_time
  • mosaicoa.pe.heap.memory.usage
  • mosaicoa.pe.non_heap.memory.usage
• Preservation of bounded non-numeric status information such as PE version, generation time, last reset time, and CIMP process time.
• Cardinality controls for allowed attributes and maximum label length.
• Resilient parsing: malformed rows can be skipped while valid rows from the same response continue to be emitted.
• Scrape/network failures are isolated to the affected collection cycle rather than crashing the Collector.
• Licence-seat validation through the pho_license extension.

A typical receiver configuration is:

extensions:
  pho_license:
    file: /etc/otelcol/license.json

receivers:
  mosaicoapereceiver:
    scheme: https
    host: 10.0.0.15
    port: 8443
    path: /status
    timeout: 10s
    collection_interval: 30s
    tls:
      insecure: false
      insecure_skip_verify: false
      ca_file: /etc/otelcol/mosaicoa-ca.pem

service:
  extensions: [pho_license]
  pipelines:
    metrics:
      receivers: [mosaicoapereceiver]

Added: VisualEdge receiver

First shipped in pho-collector: 0.2.0

The new visualedgereceiver replaces the legacy shell-script style of inspecting a VisualEdge installation with a Collector-native metrics receiver.

It reads VisualEdge installation metadata from the local filesystem and emits:

• visualedge.installation.available
• visualedge.release.info
• visualedge.licence.info
• visualedge.licence.days_remaining

The receiver can collect:

• VisualEdge release version from VisualEdgeGUIVersion.txt.
• Release timestamp from the GUI version file metadata.
• MosaicOAPI JAR version metadata directly from the JAR rather than relying on an external helper command.
• VisualEdge licence end date.
• Calculated licence days remaining as a numeric gauge.
• A bounded visualedge.status value to describe states such as ok, missing_path, missing_file, and parse_error.

Default paths match a conventional VisualEdge installation under /opt/VisualEdge, while all relevant paths, collection interval, and timeout are configurable.

extensions:
  pho_license:
    file: /etc/otelcol/license.json

receivers:
  visualedgereceiver:
    collection_interval: 30s
    timeout: 10s
    ui_dir: /opt/VisualEdge/server/webapps/ROOT/VisualEdgeUI
    gui_version_file: /opt/VisualEdge/server/webapps/ROOT/VisualEdgeUI/VisualEdgeGUIVersion.txt
    servlet_lib_dir: /opt/VisualEdge/server/webapps/ROOT/VisualEdgeServlet/WEB-INF/lib
    mosaicoapi_jar: /opt/VisualEdge/server/webapps/ROOT/VisualEdgeServlet/WEB-INF/lib/MosaicOAPI-jar-with-dependencies.jar
    license_file: /opt/VisualEdge/licence.txt

service:
  extensions: [pho_license]

Proprietary receiver licensing

The Particle Horizon proprietary receivers use the pho_license Collector extension. A deployment must enable the extension and the licence must grant a positive seat count for each proprietary receiver being started.

For the 0.2.0 distribution this covers the bundled Particle Horizon receivers:

• dacsreceiver
• mosaicoapereceiver
• visualedgereceiver

Component and platform baseline

0.2.0 uses:

• Particle Horizon component module github.com/cjcit-pho/phocol_components v0.2.0.
• OpenTelemetry Collector and contrib components from the 0.152.0 line.
• OpenTelemetry confmap provider modules from the 1.58.0 line.

The release promotes the collector from 0.2.0-beta.1 to 0.2.0 and likewise switches the proprietary component pins from 0.2.0-beta.1 to 0.2.0.

0.2.1 — Packaging and component alignment fixes

Release date: 13 July 2026

0.2.1 is a corrective patch rather than a new receiver feature release. It preserves the receiver set introduced in 0.2.0 while fixing Linux service execution paths and ensuring the distribution consumes the 0.2.1 Particle Horizon component release.

Fixed: Linux systemd service paths

Fixed in: 0.2.1

The packaged pho-collector.service was corrected to use the Particle Horizon installation layout rather than inherited otelcol-contrib defaults.

The service now:

• Starts the Collector through /opt/particle_horizon/pho-collector.
• Loads configuration from /opt/particle_horizon/local_config/pho-collector/config.yaml.
• No longer references an otelcol-contrib.conf environment file that is not part of the Particle Horizon package.

This is particularly important for .deb and .rpm installations managed through systemd.

Fixed: collector/component version alignment

Fixed in: 0.2.1

The distribution version was corrected from 0.2.0 to 0.2.1, and all proprietary component imports were moved from phocol_components v0.2.0 to v0.2.1:

• pho_license
• dacsreceiver
• mosaicoapereceiver
• visualedgereceiver

The phocol_components repository points its v0.2.0 and v0.2.1 tags at the same component commit, so this patch is principally about correct release identity and dependency alignment rather than a distinct receiver implementation change.

Compatibility baseline

0.2.1 remains on the OpenTelemetry 0.152.0 component line and 1.58.0 confmap provider line. No new Particle Horizon receiver type is introduced by this patch.

0.2.2 — OpenTelemetry 0.156.0 and broader component coverage

0.2.2 focuses on the underlying Collector distribution. It keeps the Particle Horizon proprietary components on phocol_components v0.2.1, while upgrading the upstream OpenTelemetry stack and enabling a much larger selection of contrib components.

Upgraded: OpenTelemetry Collector ecosystem

Added in: 0.2.2

The Collector’s upstream component baseline moves from 0.152.0 to 0.156.0 across extensions, exporters, processors, receivers, and connectors.

Configuration providers move from the 1.58.0 line to 1.62.0 for the core env, file, http, https, and yaml providers.

Expanded: bundled upstream component catalogue

Added in: 0.2.2

Many upstream components that were commented out of the 0.2.0/0.2.1 OCB manifest are enabled in 0.2.2. This makes the standalone distribution considerably more flexible without requiring a custom rebuild for many common integrations.

Examples of newly enabled receivers include:

• Active Directory DS
• Aerospike
• Apache Spark
• AWS CloudWatch and Container Insights
• Kubernetes cluster, events, objects, and kubelet stats
• Kafka
• Loki
• NetFlow
• Oracle Database and PostgreSQL
• Prometheus Remote Write
• RabbitMQ
• SignalFx
• Snowflake
• Splunk Enterprise and HEC
• TCP/UDP log ingestion
• vCenter
• Wavefront
• Zipkin and ZooKeeper

The same expansion applies across the exporter and processor sections of the distribution, making 0.2.2 a substantially more complete general-purpose OpenTelemetry Collector build.

Release workflow/private module handling

Improved in: 0.2.2

The release and validation workflows were updated alongside the OTel refresh, including changes required to build the Collector reliably with private cjcit-pho Go modules. The OCB generation path also received a corresponding adjustment.

Particle Horizon custom components

The Particle Horizon custom component set remains:

• pho_license — phocol_components v0.2.1
• dacsreceiver — phocol_components v0.2.1
• mosaicoapereceiver — phocol_components v0.2.1
• visualedgereceiver — phocol_components v0.2.1

In other words, 0.2.2 expands and modernises the Collector around the custom receivers; it does not introduce a fourth Particle Horizon receiver.

Feature provenance

Use this table when you need to determine the minimum 0.2.x patch required for a capability.

Upgrade guidance

From 0.2.0 to 0.2.1

Upgrade is recommended for Linux package installations. The receiver configuration model remains materially the same, but the systemd service paths and release/component version alignment are corrected.

From 0.2.1 to 0.2.2

Review upstream OpenTelemetry 0.152.0 → 0.156.0 compatibility for any contrib components you actively configure. The Particle Horizon proprietary receiver imports remain on phocol_components v0.2.1, but the surrounding Collector ecosystem is newer and the compiled component surface is much larger.

New installations

Prefer 0.2.2 unless you have a tested dependency on the older OpenTelemetry 0.152.0 behaviour.

Related repositories

The standalone distribution is assembled in cjcit-pho/pho-collector. Particle Horizon proprietary component implementations live in cjcit-pho/phocol_components; the collector’s OCB manifest pins the component module version used by each release.