Skip to content
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

Logging README #4395

Merged
merged 5 commits into from
Dec 2, 2021
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 18 additions & 1 deletion core/dbt/events/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,24 @@ The Events module is the implmentation for structured logging. These events repr
The event module provides types that represent what is happening in dbt in `events.types`. These types are intended to represent an exhaustive list of all things happening within dbt that will need to be logged, streamed, or printed. To fire an event, `events.functions::fire_event` is the entry point to the module from everywhere in dbt.

# Adding a New Event
In `events.types` add a new class that represents the new event. This may be a simple class with no values, or it may be a dataclass with some values to construct downstream messaging. Only include the data necessary to construct this message within this class. You must extend all destinations (e.g. - if your log message belongs on the cli, extend `CliEventABC`) as well as the loglevel this event belongs to.
In `events.types` add a new class that represents the new event. All events must be a dataclass with, at minimum, a code. You may also include some other values to construct downstream messaging. Only include the data necessary to construct this message within this class. You must extend all destinations (e.g. - if your log message belongs on the cli, extend `Cli`) as well as the loglevel this event belongs to.
nathaniel-may marked this conversation as resolved.
Show resolved Hide resolved

## Required for Every Event

- A unique `code` that indicates the type
- a loglevel
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd follow suit with the 4th bullet and mention extending the class with an example.

- a message()
- extend `File` and/or `Cli` based on where it should output

## Optional (based on your event)

- Events associated with node status changes must have `report_node_data` passed in and be extended with `Cache`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should mention extending the NodeInfo class if that's right.

- define `fields_to_json` if your data is not serializable
nathaniel-may marked this conversation as resolved.
Show resolved Hide resolved


All values other than `code` and `report_node_data` will be included in the `data` node of the json log output.

Once your event has been added, add a dummy call to your new event at the bottom of `types.py` and also add your new Event to the list `sample_values` in `test/unit/test_events.py'.
nathaniel-may marked this conversation as resolved.
Show resolved Hide resolved

# Adapter Maintainers
To integrate existing log messages from adapters, you likely have a line of code like this in your adapter already:
Expand Down