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
Make catalog logging a little quieter where entities are erroring #23022
Conversation
Signed-off-by: Brian Fletcher <brian@roadie.io>
Changed Packages
|
Uffizzi Cluster |
For a long time while I was at Keyloop we had no access to the database, I think this is true for other adopters as well. Also, for early Adopters these are errors they will run into first as they learn. I feel like moving them to That said, happy to go with what every the Maintainer decide on this 👍 |
@awanlin The errors are shown in the application in a few places:
|
My concern here is this makes integrating with log based tooling a lot more difficult. We use logs to generate both metrics and alerting, and while this would be possible by enabling debug logging, that would also generate a lot of noise and cost when it comes to storing those logs. |
Can you elaborate a little? Which metrics and alerts are you triggering from this log line? |
Sure! We use this to generate metrics and alert around total number of erroring entities. Seeing a steep uptick in this is often indicative of a new automation generating invalid entities, and has helped us proactively reached out to catalog users. Also as a large number of erroring entities can negatively impact processing times it has allowed us to head off incidents related to that. |
@mikeyhc I suppose what we could do to satisfy both concerns is to emit an event on the event broker and then make a configurable event subscriber that writes a log line or a produces a metric or something.. Then if you dont want the log line, dont configure the subscriber. If you do want the log line, configure the subscriber. Something like that. Would that work? |
Signed-off-by: Brian Fletcher <brian@roadie.io>
Signed-off-by: Brian Fletcher <brian@roadie.io>
Signed-off-by: Brian Fletcher <brian@roadie.io>
@punkle sounds good to me |
@mikeyhc Ive implemented that suggestion in the latest version of this pull request. Let me know if you have any feedback on the specifics. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM and really appreciate the comprehensive changeset!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
not stale |
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
not stale |
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
Not stale |
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
Signed-off-by: Brian Fletcher <brian@roadie.io>
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
Thank you for contributing to Backstage! The changes in this pull request will be part of the |
yay, thank you! |
Hey, I just made a Pull Request!
When an error is raised by a url reader or any other processor in the catalog, those errors are logged to the application logs with a warning level as well as written to the refresh_state table for retrieval later.
Given that these errors are already visible at the application layer via the refresh state table, I would argue that the log line is superfluous. The log line can be useful in some cases so I have made it possible to re-enable the log line.
In the end this change makes the catalog logging a little quieter where entities are erroring.
I dont feel terribly strongly about this, and am happy to close this if there is any contention.
✔️ Checklist
Signed-off-by
line in the message. (more info)