New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce abstractions for loggable events #75
Comments
A possible attribute implementation: https://godbolt.org/z/4j4bMr1bc |
kuhar
pushed a commit
that referenced
this issue
Oct 11, 2022
Currently, the logging mechanism is unstructured. Various log functions with different interfaces are used to generate the logs. All these functions receive a series of inputs, combine them in a string with csv format, and write them in the standard output or a file. `The`Event` class unifies the interface for creating logs. It provides these two functionalities: 1) Using the same interface for creating all the logs to replace the current ad-hoc event logging functions. 2) Allowing log generation for different formats other than csv. Each `Event` has a name and a set of attributes. Attributes contain the value and its name. The name is a string telling what the attribute is (e.g, duration, timestamp, etc). The current log functions use only a limited set of types; string, int64, and vector. Hence, right now, `Attribute` has three implementations covering the mentioned types. This PR also contains the implementation for Event, an event-to-csv generator, and simple unit tests to check if they work as expected. Issue: #75
I consider this completed. @miladHakimi updated all layers to use the new abstractions for CSV logging |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The existing event logging is rather ad-hoc. Examples:
This form of logging is unstructured and does not allow for emitting logs in different output formats. All the event data is converted to strings and concatenated before we can decide which logging format to use.
This task is to come up with a more structured abstraction for logged events that will allow for multiple output formats (e.g., csv and json).
The generic interface should provide the following functions:
getEventName()
getLogLevel()
-- decides the 'verbosity level', e.g., whether to log to CSV or to the common log filegetNumAttributes
-- returns the number of data entries (or 'columns' / tuple elements / etc)getAttributes()
We want to support a few data entry types:
All of this combines as follows:
A concrete layer-specific event definition could look something like this:
(This is just an example for inspiration. Better ideas welcome!)
The text was updated successfully, but these errors were encountered: