The activity log
What changed, who changed it, and what the application itself did.
On this page
The Logs screen answers "what happened, and who did it". It covers who signed in, what was emailed, what was loaded or harvested, every change to an asset or to the model, and what the application itself reported.
Before you start
- Everything is on Administration → Logs.
- To read it you need Read the logs (LOG_VIEW), which comes with Sysadmin, or to be named on this screen by somebody who manages access. A log records who did what and when they were at their desk, so keep the list short.
- The permission buys one more thing, and being named on this screen does not: whoever holds LOG_VIEW can ask any screen where its seconds went, which is how a slow page is diagnosed. That answer contains the SQL this build is made of and nothing out of your repository.
Find something in the log
- Pick the tab for the kind of activity (see below). The number on each tab is how many entries it holds.
- Type in Search this log to narrow the list. The search applies only to the tab you are on.
- Press Show earlier to go further back.
The newest entries are at the top. Each line shows when it happened, who did it, and what happened. Lines about problems and warnings are coloured so they stand out. A line about a harvest has every line of it →, which opens that run's own page with everything it did.
What each tab shows
| Tab | What it records |
|---|---|
| Every message KRISID sent or tried to send, and whether it went | |
| Sign-in | Sign-ins, sign-ups and changes to how sign-up works. A sign-in line says where it came from — by name, or as the masked network — while Record where people sign in from is on. See Usage analytics |
| Asset edits | Changes to assets, their attributes and their links |
| Asset model | Changes to the metamodel: types, attributes and relations |
| Access | Changes to people, teams, roles, permissions and assignments |
| Workflow | Changes to workflows and change requests |
| Migration and loads | Asset workbooks uploaded from Loading from Excel, whether they were loaded or refused |
| Cataloguing | Harvest runs bringing in things from a source: what was new, changed or no longer there |
| Lineage | Harvest runs drawing the links between things |
| Lineage received | OpenLineage events arriving from jobs such as Airflow or Spark |
| System | Things the application did itself, such as starting up or being upgraded, and changes to stored credentials: which source secret or the mail password was changed, and by whom, never the value |
| Runtime | The last lines of the server's own log file |
Cataloguing and lineage have separate tabs because they fail in different ways. Someone looking for a missing table and someone looking for a missing link need different entries. Lineage received is separate too: an event arriving shows that a job is sending correctly, while the Lineage tab shows what KRISID later made of it.
The Runtime tab shows the server's log file. It is capped at 10MB with five files kept, and invite links, session tokens and anything that looks like a password are removed before a line is written.
Choose who can read the logs
Under Who can see these:
- Through a role lists everybody who holds LOG_VIEW through one of their roles.
- And these people lets you name extra people, for example an auditor who isn't an administrator. Search for a name, pick it, and press Save. The × on a name takes it off.
Either way is enough to read the logs. Changing this list needs Manage users and roles (ACCESS_MANAGE).
How long entries are kept
The line beside the search box says how long entries are kept, for example kept 90 days by bash run.sh prune. Nothing is deleted automatically. Old entries go only when an administrator runs the prune command on the server:
bash run.sh prune
bash run.sh prune --apply
The first command says what would go and changes nothing. The second deletes it. To use a different cut-off for one run, add --days with a number, for example --days 30.
Prune trims the email log, the sign-in and other event entries, and finished sessions. It never touches History: the Asset edits, Asset model, Access and Workflow tabs come from History, and no command trims it.
Note: Each asset's page also has its own History, which shows the same changes for that one asset. See Reading an asset.
Good to know
- The log reads from where each fact is already recorded. It is not a second copy, so it can't disagree with the screens.
- On the server,
bash run.sh logsshows the tail of the runtime log file, andbash run.sh logs 500shows more.