Replies: 1 comment
-
So logging on the frontend is not very useful for request tracing, since it is the starting point. With opentelemetry you can export logs from the frontend SPA to the backend collector, but I prefer to have the frontend monitored by tools like https://sentry.io because it's a different way of looking at the data. Sentry and other similar tools look at the data like this: "How long does the document take to load?", "What navigation did the user perform on the page?", "What are the exceptions and from what components?", etc... but with request tracing , you look at the data as isolated backend commands "CreateOrder", "DeleteWebHook", etc... With a single responsibility... And you need to keep logs in similar pattern because you will have problem to merge all this data together.. You usually don't wanna connect user behavior with requests.. This are separate concepts... It's true that logging is only for the backend (API and infrastructure - read monitoring, there are logs exported from Docker and external apps) Currently you can collect logs from the frontend by this 2 options:
Be careful with the setting, as the frontend can generate unexpectedly many logs. That's why I prefer a separate, isolated solution to monitor the frontend from the user's point of view and o requests (data) point of view. This solutions also have a threshold value where you collects only lets say 50% of users to create data profile (to reduce amount of data).. Usually is real value 0 -1.0.. I will consider if there is a reason to add logging from SPA, if so I will extend it... |
Beta Was this translation helpful? Give feedback.
-
Maybe I missed it, but it seems the logging details focus more on the API parts.
And tracing is being touched in the SPA and API parts.
Is there a general usage for logging in SPA's too? Maybe pushed to a central log too?
Beta Was this translation helpful? Give feedback.
All reactions