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

formalize logging of sign content and generate tags #817

Merged
merged 2 commits into from
Sep 16, 2024

Conversation

panentheos
Copy link
Collaborator

Summary of changes

Asana Ticket: Improve RTS and SCU message logging

This adds audio, visual, and tag fields to RTS message logs, with JSON-parseable visual data.

  • Splunk should be able to parse the visual page data, allowing us to transform it easily in dashboards. (We'll want to deploy to dev-green and test in splunk to make sure this works as expected.)
  • Legacy audio message logs now contain a human-readable representation of what was played. Note that for legacy stations (all of them currently), this data isn't exactly what's played, but it should be semantically equivalent. After migration, these logs will show exactly what was played.
  • The random tag is not helpful for legacy stations, but after migration, SCUs will log this tag in their own output, allowing us to trace message playback.

@panentheos panentheos requested a review from a team as a code owner September 12, 2024 19:48
Copy link
Contributor

@cmaddox5 cmaddox5 left a comment

Choose a reason for hiding this comment

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

Looks good!

@@ -23,20 +23,26 @@ defmodule PaEss.Updater do
_ -> nil
end

log_meta = [sign_id: id, current_config: log_config]
visual = zip_pages(top, bottom) |> format_pages()
tag = create_tag()
Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, a question came to mind while working on the dashboard. Is it possible to default tag to nil for legacy? It would make it easier to tell legacy and migrated messages apart and would allow me to display N/A in the playback column.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Instead of that, how about another explicit field that specifies whether it's legacy? Part of the goal here is to start unifying the shape of the logs as much as possible, so I wanted to start exposing this data so we can build dashboards to that spec (but yeah, we still need a way to differentiate legacy messages)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yea I like that better. Much less likely to cause confusion way down the line.

@panentheos panentheos merged commit 2028ce1 into main Sep 16, 2024
2 checks passed
@panentheos panentheos deleted the bhw/formalize-logging branch September 16, 2024 20:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants