Can there be too much logging? (Front End & Back End)

Question

In a bit of a dilemma. At work we are having issues with an API service that communicates with the client side through a WebSocket. The problem so far is that the WebSocket seems to be unreliable. We have sufficient logs that tell us this, but for some reason everyone is on the boat about adding logging to the front end to see what is going on.

I have a couple of issues with this:

1. Unnecessary traffic. Logs are collected in the backend, so to log from the front end, I'd have to create a new api endpoint just to log front end code.

2. We already know the problem is with the WebSocket, why spend time and effort on logging the front end? (Other client apps also face the same issue). We're already logging when updates are being sent.

Pros:

1. I guess more clarity as to what is going on?

Note, we already log JS console errors and exceptions.

Can this be considered too much logging? Or am I not seeing something?

Answer 1

It is all about trade-offs.

• can you store client-side logs?
• for how long?
• do you scrub private data?
• can you send the complete log on error?
• does the app send requests for all actions?
• can you figure out user actions when they don't send network requests?

There are very good use cases for collecting client-side logs, especially when trying to reproduce failure scenarios. Examples:

• your app / browser crashed, would you like to send a report?
• rage shake, I think something is wrong, report error.

The number one argument for client-side logs is that not all user actions / state updates on the client result in a network request, so the server never has the whole picture.

People already do that and some libraries make it easier than others; e.g. React + Redux. If you check out redux-devtools, you will see that you can do action replay . Why? Because all state changes are handled in similar fashion.

too much logging?

I articulated the previous text around state changes. When logging some information that is not directly related to a state change, that is just fluff. The same way you remove print statements everywhere before putting it in prod, you can remove / consolidate log statements that are not essential.

• is the log record related to a state change?
• is it related to necessary implementation detail?

Answer 2

Why are you doing logging? One reason is on the backend to have forensic evidence about attackers, we can ignore this. The other reason is to find hints what is going on if something goes wrong within your software, preferably after the fact.

What you really want (and can't get obviously) is one single line in the log that tells you exactly what was going on. Second choice, which is what you should aim for, is enough logging so that you can identify a fault, but not so much that you are looking for a needle in a haystack.

Blindly logging everything isn't going to help. The frontend should have logging to help find problems with its own behaviour, and it may be useful to log when the frontend detects misbehaviour of the backend. You'd probably want to invest some effort into this. Logging "I sent request X to the backend", then "Backend responded to request X just fine" is just useless noise. You'd want to collect info locally, then if you get an incorrect reply from the backend log everything that happened on the way (because in the end, the incorrect reply could be caused by an incorrect request).