Ignition Edge Tag Historian Disappears

We have had a few situations where the historical provider disappears, store and forward page says we need to install the module. The module is there, activated and running. Restarting the module brings the historical provider back online. I dont see anything in the log for the historian.

anyone run into this before?

Does this happen in a situation where things have been working and suddenly stop? Or are there other [possibly] related events that precede this situation, such as a reboot/restart, etc?

EDIT: also, Ignition version and backing OS info?

we did have some power failures in the area. i dont know when the historian module quit working. I did find this in the older wrapper logs. (see screenshot)

Edge 8.1.14
RHEL 8.5
x86

All of those logs look “normal”, though the grep obviously could be filtering out other causal factors… If you think you have one of these “events” in the timespan currently represented in the logs, might be worth trying to pull them off of there for deeper analysis (before they get rotated out). (recommend zipping them up prior to download to save a bunch of space). We’d probably want to be able to correlate some kind of rough time frame and inspect the logs–it is likely there’d be some kind of telling output in the logs prior to that historical provider failing to show up.

Actually, ignore those errors, i was logged into the wrong gateway. (doh). in the correct gateway, i see nothing in the wrapper logs for “Historian”.

Are there some other keywords I can look for rather than searchign for the needle in the haystack? (since i dont know when it quit)

Not sure off the top of my head, though I’ll share a small filter script that I use to reduce the amount of hay:

#!/usr/bin/env bash

REGEX="^(?<wrapperlevel>.*?)\s+\|\s*(?<process>.*?)\s+\|\s(?<timestamp>.*?)\s\|\s(?<level>T|D|I|W|E)\s\[(?<logger>.*?)\]\s\[.*?\]:\s(?<message>.*?)$"
TARGET_FILE="${1}"
GNU_GREP="grep" (I use `ggrep` here on macOS after `brew install grep` to get GNU versions)

${GNU_GREP} -Po "${REGEX}" "${TARGET_FILE}"

I save this off to a file, call it filter-logs.sh and then chmod a+x filter-logs.sh and invoke it like:

$ ./filter-logs.sh /path/to/ignition/logs/wrapper.log > wrapper-filtered.log

This basically just filters down to the first lines of a given log and outputs to a separate file–it eliminates all of the extra stack traces. I find it easier to “see” what I’m looking for browsing through after filtering it down. You could tweak the level match in the REGEX to only include various levels, too. That script I shared is just a little utility I wrote–nothing “formal”. :slight_smile:

interesting, thanks!

@kcollins1 some additional info. The first time this happened it was after a restore in disabled state. Learned my lesson the hard way how intense it disables everything. Took a while to get things re-enabled. I’m assuming that during the power outage and subsequent power cycle, something was lingering from that disabled restore that blocked the tag historian from starting proper.

This is good to know–in 8.1.11 we added the ability to re-enable the Edge tag provider (previously uneditable in Edge, thus you couldn’t easily re-enable after a restore-disabled). I’ll explore whether there are possibly some additional artifacts here related to the Tag History Data Sync and restore-disabled.

Thank you, appreciate the deeper dive. if we lose power again and it doesnt restart properly again, i will let you know.