Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add basic optional sentry.io integration #4632
I've found sentry.io quite useful to see what errors synapse is producing on jki.re, so I think its worth adding. This is very bare-bones, but is enough to be useful.
By default, sentry will upload all records logged at
@@ Coverage Diff @@ ## develop #4632 +/- ## =========================================== + Coverage 75.28% 75.29% +0.01% =========================================== Files 338 338 Lines 34579 34793 +214 Branches 5655 5722 +67 =========================================== + Hits 26032 26198 +166 - Misses 6957 6989 +32 - Partials 1590 1606 +16
michaelkaye left a comment
So the code will work, but I think we need to be much more verbose about the impact this has on private data - there are no known issues sending data from an application to a sentry instance or within the sentry instance; but it does have issues if there are notifications on from a sentry instance to email.
If we attach too much data to these requests, that data may leak onwards, and we may end up with credentials in unencrypted email histories, which would be bad.
https://docs.sentry.io/data-management/sensitive-data/ provides their information on scrubbing, but we should not depend on server-side scrubbing to make this safe (we do not know that every synapse admin will be using sentry correctly) - so we should prevent the flow of information out from synapse in the first place.
I think this is fair to merge as is, for the limited use cases when the administrator is aware of what they're doing, and takes responsibility for correctly configuring their sentry instance; but i'd give it a lot of health warnings for those without that experience until we perform the filtering required to limit the sending of data.
(We also need to commit to ensuring we continue to update those filters as required to prevent any new sensitive information from being leaked)
I am very in favour of deploying this as it's an amazing tool to help diagnose issues in production systems - we just need to make sure the filters are correct to only expose what's going on, so we can get "lots of errors at line 621 when you set the