Skip to main content

Alarm archive and restore after a restart

The alarm service records every alarm event: an alarm came, was acknowledged, went, was closed by the system, or was shelved and unshelved. Where the events are kept decides what the History tab of the alarm list can show and what comes back after the alarm service restarts.

Where alarm events are kept​

StorePresentWhat it keepsUsed for
History database of the projectAlwaysAlarm events in the default events table (hist_events, 5 years by default)The event list; restoring open alarms after a restart when there is no long-term archive
In-memory journalAlwaysThe last 10,000 events since the alarm service started; lost when it stopsThe History tab when there is no long-term archive
Long-term alarm archiveOnly when set up for the serverEvery event for 2 years, written in batches of 1,000 events or every 0.5 secondsThe History tab and its downloads; restoring open alarms and shelving

The long-term alarm archive is a ClickHouse database. It is used only when the server settings below give its address; a standard installation does not have one. In that case the long-term record of alarms is the event list, see What the event list records, and the retention of its table is set as described in How history is recorded.

What the alarm history shows​

The History tab of the alarm list reads the long-term alarm archive when there is one. A note next to the list says when it does not:

  • Archive off — from memory: there is no long-term archive. The list shows only the events in memory, that is, the events since the alarm service last started, at most 10,000.
  • Archive unreachable — from memory: the archive is set up but cannot be read at the moment. The list and its downloads come from memory until the archive answers again.

A search covers at most 366 days, and a CSV download holds at most 1,000,000 rows. How operators use the tab is described in Search and export the alarm history.

When the alarm service restarts​

The alarm service restarts when the project or the server restarts. While it starts, alarm lists and the alarm bar show Alarm service starting…, and acknowledging waits, until the open alarms are restored and the first live values are read. Then:

  • Open alarms come back. Every alarm that was still open in the last 30 days returns with its state, the time it came and went, and who acknowledged it and when. The text and priority of a signal alarm are taken from its current definition. A level that the definition no longer has becomes the last level the definition has.
  • Live values decide. An alarm whose condition is still present stays as it was, so an acknowledged alarm is not raised again. An alarm whose condition has cleared goes.
  • Removed definitions are closed. An alarm whose definition no longer exists is closed by the system. An unacknowledged alarm whose definition is now out of service or shelved, or now uses the acknowledge mode none, is acknowledged by the system.
  • Communication, command and system alarms come back as they were and are taken over by the service that raises them, so a device that is still lost does not get a second alarm. See Communication, command and system alarms.
  • Shelving comes back from the long-term alarm archive. A shelving that ended while the service was stopped is ended at the start.

Server settings​

These settings apply to every project on the server. They are environment variables that the process manager (scada-manager) reads when it starts and passes to the alarm service, so set them before you start YTCC.

VariableDefaultMeaning
CLICKHOUSE_URLNot set (no long-term archive)Address of the long-term alarm archive, for example http://127.0.0.1:8123
CLICKHOUSE_DBscadaDatabase of the archive; it must exist, the alarm service creates its table
CLICKHOUSE_USER, CLICKHOUSE_PASSWORDNot setSign-in for the archive, if it needs one
ALARM_RESTORE_DAYS30How many days back open alarms and shelving are restored from the archive