Logging is a good thing. Logging such that you maximize the value you get out of them is a better thing.
So, stop thinking of logs as files; instead think of them as output of your application that is going to be collected and aggregated into some kind of time series database for storage and accessing. Once you run infrastructure with many servers, docker containers, lambdas, etc. that each produce logging output, metrics, and other noise, centralized infrastructure for this is the only sane way to stay on top of this stuff. SSH access to production servers to be able to grep through logs is not (or should not) be a thing in most responsibly run setups. Access for developers to all that is even less desirable. So, think about where your logs go and how they get to the logging cluster, what should be in them, etc.
Logging clusters (e.g. Elasticsearch with Kibana as UI) treat logs as timeseries data. Basically, data with at least a timestamp and probably some kind of message or other data. There are lots of examples of different types of things with a timestamp beyond log messages (auditing events, metrics, kpis, etc.) and many specialized systems exist for storing, graphing, querying, etc. each of them.
Once you start aggregating time series data, the next thing you'll want to do is add meta data to facilitate finding things back, breaking things down, and creating nice dashboards. You'll easily end up with millions of events in a very short time frame. Good meta data is key for this. Without that you just have a lot of noise sorted by time.
So, stop thinking as logs as stuff that you print to a console that ends up in a file. Instead start thinking of it as structured data that gets aggregated to a logging cluster and think about what strucutured data you want to make more sense of this stuff.
For example, with most java/kotlin backend projects, people tend to set up a logging framework with formatted output. The whole point of formatting the output is that some other program can parse it and do things with it. The bit of software that is responsible for getting logs to your logging cluster does this. There are many solutions for this; some with decades of history.
But. why not make that job easier and just log serialized JSON messages to your console. Each message is a JSON object with a few fields (timestamp, message, level, etc.). In Java you don't even have to do this manually, there are logging plugins that do this for you.
A relatively unknown feature in that is something called the MDC (mapped diagnostic context) which allows you to add context to your logs. If you set things up properly, this stuff can be picked up by your logging cluster and provide you with an easy way to slice and dice your logs. So when a request comes in to our server we add meta data about the request (url, method, user agent string, user id, server ip, service name, logger name, etc.). All this gets sent to our logging cluster where we have nice pie diagrams with the logs broken down by in several ways. Now when we catch an exception and log an error, all of that gets sent along.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Logging is a good thing. Logging such that you maximize the value you get out of them is a better thing.
So, stop thinking of logs as files; instead think of them as output of your application that is going to be collected and aggregated into some kind of time series database for storage and accessing. Once you run infrastructure with many servers, docker containers, lambdas, etc. that each produce logging output, metrics, and other noise, centralized infrastructure for this is the only sane way to stay on top of this stuff. SSH access to production servers to be able to grep through logs is not (or should not) be a thing in most responsibly run setups. Access for developers to all that is even less desirable. So, think about where your logs go and how they get to the logging cluster, what should be in them, etc.
Logging clusters (e.g. Elasticsearch with Kibana as UI) treat logs as timeseries data. Basically, data with at least a timestamp and probably some kind of message or other data. There are lots of examples of different types of things with a timestamp beyond log messages (auditing events, metrics, kpis, etc.) and many specialized systems exist for storing, graphing, querying, etc. each of them.
Once you start aggregating time series data, the next thing you'll want to do is add meta data to facilitate finding things back, breaking things down, and creating nice dashboards. You'll easily end up with millions of events in a very short time frame. Good meta data is key for this. Without that you just have a lot of noise sorted by time.
So, stop thinking as logs as stuff that you print to a console that ends up in a file. Instead start thinking of it as structured data that gets aggregated to a logging cluster and think about what strucutured data you want to make more sense of this stuff.
For example, with most java/kotlin backend projects, people tend to set up a logging framework with formatted output. The whole point of formatting the output is that some other program can parse it and do things with it. The bit of software that is responsible for getting logs to your logging cluster does this. There are many solutions for this; some with decades of history.
But. why not make that job easier and just log serialized JSON messages to your console. Each message is a JSON object with a few fields (timestamp, message, level, etc.). In Java you don't even have to do this manually, there are logging plugins that do this for you.
A relatively unknown feature in that is something called the MDC (mapped diagnostic context) which allows you to add context to your logs. If you set things up properly, this stuff can be picked up by your logging cluster and provide you with an easy way to slice and dice your logs. So when a request comes in to our server we add meta data about the request (url, method, user agent string, user id, server ip, service name, logger name, etc.). All this gets sent to our logging cluster where we have nice pie diagrams with the logs broken down by in several ways. Now when we catch an exception and log an error, all of that gets sent along.