Skip to main content

Data Point and Logging Settings

Logging settings control how and when Mango persists data point values to the database. Choosing the right logging type is one of the most impactful decisions you will make for system performance and storage consumption. This page explains each logging type, purge configuration, cache sizing, and value discarding.

Logging Types​

Mango supports six logging types. The appropriate choice depends on how frequently the data source polls, how much storage you have, and what level of historical detail you need.

When Point Value Changes (Default)​

This is the default logging setting. A point value is written to the database only when the value actually changes from the previous value. This provides a good balance between historical data quality and storage efficiency.

For Numeric points, a Tolerance (also called a "deadband") can be configured. When a tolerance is set, the new value is logged only if the absolute difference between the new value and the last logged value equals or exceeds the tolerance. For example, a temperature sensor with a tolerance of 0.5 will not log a new value unless it has changed by at least 0.5 degrees from the last recorded value.

When to use: Most data points. This is the best general-purpose setting for sensors that change gradually.

All Data​

Every point update from the data source is saved to the database, regardless of whether the value has changed. This produces the most complete historical record but also consumes the most storage.

When to use: Only when you need a record of every single update, such as for audit trails, high-frequency event analysis, or compliance requirements. Be cautious -- a point polled every second will produce 86,400 values per day.

Performance warning: Over time, accumulating all-data logs for many points can cause serious performance degradation in both the database and the UI.

Interval​

Interval logging decouples the data source polling frequency from the logging frequency. The data source collects values at its configured poll rate (which may be needed for event detection), but values are only logged to the database at the specified interval.

The Value type determines what gets logged at each interval:

  • Instant -- The current value of the point at the moment the interval fires.
  • Average -- The time-weighted average of all values collected during the interval.
  • Minimum -- The minimum value observed during the interval.
  • Maximum -- The maximum value observed during the interval.

For Average interval logging, you can optionally override the sample window size by checking Override interval logging sample window. The Sample window size sets how many recent poll samples are used to compute the average. For example, with a 5-second poll period and a sample window of 10, the average is computed over the most recent 50 seconds of data. The logged timestamp is the midpoint of the window, and no average is recorded until the window is full.

When to use: When you need fast polling for event detection but do not need to store every polled value. Common for high-frequency sensors (polling every few seconds) where a 1-minute or 5-minute logged summary is sufficient.

Interval and Point Value Change​

This hybrid logging type combines the "When point value changes" behavior with a periodic interval backup. If no value change exceeds the tolerance within the interval period, the current value is logged at the end of the interval anyway. This ensures that at least one value is recorded per interval even if the point value is stable.

When to use: When you need the efficiency of on-change logging but also want guaranteed periodic records for charting or reporting purposes.

When Point Timestamp Changes​

Similar to on-value-change logging, but the comparison is made on the timestamp of the sample rather than the value. A new record is logged whenever the timestamp of the incoming sample differs from the previous sample's timestamp, regardless of whether the value itself changed.

When to use: Specialized scenarios where the data source provides timestamped data and you need to capture every distinct timestamp, even if the value is unchanged.

Do Not Log​

No historical data is stored for this point. The point still has a current (runtime) value that can be viewed in real time and used by event detectors, but no history is kept in the database.

When to use: Points that serve only as intermediate values in calculations, or points whose history is not needed. Note that chart renderers and historical queries will not work for points with logging disabled.

Purge Settings​

Purge settings determine how long historical values are retained in the database. The purge process runs automatically every morning at 3:05 AM local time and removes values older than the configured retention period.

Each data point can either inherit the purge settings from its parent data source or override them:

  • Use data source purge settings (default) -- The data point uses whatever purge period is configured on its data source.
  • Override data source purge settings -- The data point defines its own retention period (e.g., keep 1 year of data even if the data source purges after 30 days).

Recommendations:

Point typeSuggested retention
High-frequency analog sensors30-90 days of raw data; use rollups for longer-term analysis
Critical alarm points1-2 years or longer
Internal/diagnostic points7-30 days
Counter/accumulator pointsDepends on billing or reporting cycles

Keeping excessively long histories for high-frequency points can degrade query performance. If long-term trend analysis is needed, consider using interval logging or rollup queries instead of storing every raw value indefinitely.

Default Cache Size​

The Default cache size sets the number of recent point values held in memory. Cached values are used to satisfy queries without hitting the database, improving performance for real-time dashboards and event detector evaluations.

Key considerations:

  • A larger cache reduces database load but consumes more heap memory. If your Mango instance has thousands of points each with large caches, memory usage can become significant.
  • A cache size of 0 means no values are cached. This may cause some event detectors (such as the Point Change detector) to behave unexpectedly. For most points, a cache size of at least 1 is recommended.
  • When the logging type is anything other than "All data," the cache is used to collate in-memory values with database-stored values. A reasonable cache size (e.g., 1-10) is usually sufficient.
  • Use the Reset cache option if you have manually deleted point values (for example, via SQL) and the cache may contain stale entries.

Value Discarding​

For equipment that occasionally sends errant readings (sensor spikes, communication errors), Mango provides value discarding:

  • Enable Discard extreme values on the data point's logging settings.
  • Set the Discard low limit and Discard high limit. Any incoming value below the low limit or above the high limit is silently dropped.
  • NaN and Infinity values are always discarded when this option is enabled.

Existing values already stored in the database are not affected by enabling discarding -- it only applies to new incoming values.

The Logging Properties tab on the data point edit window showing logging type, purge override, and cache size fields