# Paper Trail - Event History ## General Defination (Non-Technical Term) A series of documents providing written evidence of a sequence of events or the activities of a person or organization. ## Solarwind's Papertrail #### There's a company called 'Papertrail' that manages logging. - https://www.papertrail.com/ - https://github.com/solarwinds/papertrail-go [Papertrail Alternatives](https://www.g2.com/products/solarwinds-papertrail/competitors/alternatives) #### Setup For System Logs - [Unix and BSD system logs](https://www.papertrail.com/help/configuring-remote-syslog-from-unixlinux-and-bsdos-x/) - [Unix and BSD text log files (remote_syslog2)](https://www.papertrail.com/help/configuring-centralized-logging-from-text-log-files-in-unix/) #### Sending From Golang - [Logging using Go](https://www.papertrail.com/help/go-logging/) ## How Logging Helps Logging is a crucial part of a system to detect issues, errors or even monitor. All though logging is not event history but they are closely related. ## Ways to store logging - Files - Faster Read/Write - Difficult to search - Databases - Compared to files slower - Easier to search ## How is logging and event history different ? Let's say, if a database operation failed, there will be a log for it, also for success, but the event is what triggered the operation. Example : - Event : Store User (lets say from web ui, user wants to store) - Logging Could Be - User storing failed. ## Points to history storing - Need proper Events/Or Trigger points defined - Example : - Install Nginx - Fetch Repository. - Add Repository. - Install Repository. - Add To Installed Packages Record. - Decide whether to store it generally or specifically - General Example : - Stored user `userx` - Installed Package `nginx` - Specific : - Install History - Installed `nginx` ... - Installed `powerdns` ... - User History - Updated `userx` ... - Deleted `usery` ... - Decide storing parameters - Example : - `EventX` was triggered from `Web` by `UserX` at `Sunday, 22 December` and was `successful` ## History Flow ![](https://i.imgur.com/5AoZkYG.png) Depending on the system design, after storing any history it could be returned to the original caller. ## Key Features - Should be one way data flow (immutable) - Should be easier to go through times (let's say history of previous month) to debug or analysis. - Should be clear and specific - Should have proper identifier to target an exact event that caused problems.... - Should have versioning - Example - If there's logic changed or model, rather than updating the current history structure, the history should be upgraded to a higher version with structure changes. - Can have chaining system. - Example - Suppose if `userX` wants to install `nginx`, before installing the system checks if `nginx` is already installed or not. - Event 1 : Check if `nginx` installed by system with id `123` - Event 2 : install `nginx` requested by user , related history : historyId : `123` - Should have snapshot feature - ## References - [Paper Trail](https://www.papertrail.com/help/papertrail-documentation/) - [Event Sourcing](https://www.eventstore.com/event-sourcing) - [Plumbr](https://plumbr.io/blog/programming/storing-and-querying-trillions-of-events)