Introduction to the Collector and Logging Sessions
The Timebase Data Collector connects to various data sources and establishes logging sessions with the Timebase Time Series Historian.
The Timebase Data Collector is an application that gathers data from various sources and logs that data into the Timebase Time Series Historian. Data sources supported include MQTT, SparkplugB, OPC UA, Telegraf, a standalone module for Ignition (doesn't use Collector) and a Data Simulator, and an open source plug-in that can be used by the community to develop additional protocol support.
Logging Sessions#
A logging session defines how and where data collected by the Data Collector is sent.
- A logging session connects to a single instance of a data source and data type.
- A logging session can target multiple historians but will only write to a single dataset within the targeted historian(s).
- Each session operates independently of other logging sessions.
- Each session has its own store and forward capability and buffer.
Store and Forward Functionality#
The store and forward mechanism ensures data integrity even in unstable network conditions. Data is temporarily buffered locally and forwarded to the historian once the connection is restored preventing data loss during disruptions.
Buffered Data is stored in C:\ProgramData\Flow Software\Timebase\Collector\Data by default in Windows and in the \data volume in Docker.
The directory is the Collector's Data path. On Docker it is the Data environment variable in the Compose file; on Windows it is set per component in the Timebase Service Starter.
Data Collector FAQs#
1. What Permutations and Configurations Are Allowed?
One Collector service hosts any number of collector instances, of any mix of types. Each instance is one logging session: it has one type (MQTT, Sparkplug B, OPC UA, Telegraf or Simulator), connects to one source, and writes to one dataset on one or more historians. A fresh installation already carries three such instances side by side in the one service, example-simulator, example-mqtt and example-opcua, all disabled until you turn one on.
2. Can One Collector Have Multiple Collector Types?
Yes. Add an instance per source from the Collector interface and choose its type as you create it. An MQTT instance and an OPC UA instance run together in the same service, each with its own store-and-forward buffer and its own historian links. What stays fixed is the instance itself: one instance has one type, and changing the protocol means adding another instance.
this is new in 2.0. Before 2.0 a Collector was one protocol: collecting from MQTT and OPC UA meant two Collector services on Windows, or two containers on Docker, each with its own configuration. A Collector upgraded from 1.3 keeps working as it was, as a single instance in its service, and you can add instances of other types beside it rather than installing another Collector.
3. Can One Collector or Logging Session Log to Multiple Datasets?
No. A single collector instance or logging session can only target a single dataset.
It is always a best practice to keep a 1:1 relationship between a logging session and a dataset. This makes it easier in the future to troubleshoot as well as backup or restore historic files.
4. When Running Docker, Do You Need to Spin Up Multiple Containers?
No. One collector container serves the whole stack, however many types and sources you collect from; the Compose file in Start Here for Docker runs exactly one. Add a second container only for a reason outside the Collector itself, such as a source on a network segment the first container cannot reach, or to give one very large instance its own memory limit.
From Timebase 2.0 the timebase/collector image no longer runs as root. It runs as the unprivileged user app (uid 1654), so a volume written by an earlier release, which ran as root, is not writable by it and the Collector exits with a message naming the directory. The Compose files we provide carry a volume-init service that hands the volume over on every start. If you run the image any other way - your own Compose file, docker run, a bind mount, Kubernetes - do it once yourself before starting the 2.0 image: see Timebase 2.0 Release Notes.