Is it worth logging HTTP requests when they enter an API server?

Question

I'm designing an API and have reached the topic of logging. I'm going to store my logs in Elasticsearch.

I'm certainly going to do some logging at the time the HTTP response is sent back to the client, with info such as processing time, response code, user id, URL.

Is it best practice to also send a record to the logging system right when the HTTP request enters the API server?

What I have in mind here are situations when the response never materializes, e.g. because the server dies, or takes forever processing the request (e.g. due to bad business logic). If this occurred, I'd have no record at all of the client making a request.

---

Original wording below (to understand some of the answers). I tried creating a new question with the new wording and then attempted to delete this one. However, SO wouldn't let me delete this, and the new one started getting marked as a duplicate.

API logging: request, response, or both?

I'm designing a REST API and have reached the topic of logging. I'm going to store my logs in Elasticsearch.

Is it best practice to log both HTTP request and response, with some correlation id to match them in the logs? What are the advantages and challenges of doing it this way, as opposed to only logging requests or responses?

(I have some thoughts on this of my own: suspect it is best practice and see some advantages & challenges, but feel there's a lack of an expert treatment of this subject online. Hoping this question will result in one.)

Edit:

I'm NOT asking about whether to store in the logs the contents of every request and response. I'm asking whether to store some basic record for each request and response (e.g. timestamp, URL, IP, response code, some form of user id), or maybe just for requests, or maybe just for responses.

Answer 1

What is the goal of your logging? Logging request, response, and user info is perfectly valid if your goal is to build a profile of your users. Google certainly does.

If all you want to do is debug your service it's a bit much. Your focus should be on errors not recording how things went when it worked.

My 11th grade English teacher has the best advice for logging: Know your audience. Understand the needs of those that will use the log. If those people will have more than one goal you may want to create more than one log.

Answer 2

Logging all API requests can be extremely important for security and compliance. A lot of intrusions can be detected or investigated later on based just on log analysis. Without those, it's like going blind into a deep forest.

API is the first point of entry into most web applications (by definition). Application security penetration tools (the same ones used both by whitehat and blackhat researchers) rely on communication with your APIs to find potential for abuse. So this may be your best (and often the only, since everything else can be spoofed or hidden by the attacker) reliable visibility into such activity.

For this reason, logs should be stored in "read-only" form that cannot be purged by any intruder. Consider relying on Cloud provider native logging, which is designed with this purpose in mind.

Answer 3

Best practice is to log whatever you need. You should know your application well enough to know what information is required to troubleshoot issues. If you don't, then spend more time thinking about it.

Answer 4

It depends if you can afford the extra log then why not. Especially now that we have central logging solutions etc... Sometimes cases arise when your like I wish I had the request/response bodies.

One example is I have a web client that takes a response predicate to check if the response is Json. All of sudden it stopped working with an en exception indicating that the response is not JSON. So the only way to find out was to print the headers and the response body and funny enough everything checked out so there was a bug in the JSON predicate. In this case an extra log statement had to be added in the code.

If you are using any decent loging API you can pass those logs to a debug level and depending on the feature set you can maybe enable debug logs on the fly or maybe a quick config and restart and hope it happens again.

Another key where it's nice to have the logs is when you expect to have lots of API clients connect to you. You would be surprised to find out how many devs of even fortune 500 companies make mistakes even on simple things like url encoding...

Also in my logs I try to log as much as I can in a single line per request. But it adds a bit complexity to the log mechanism cause you have to keep around some variables in some sort of request context until you can log. But performance wise it's good because your still writing 1 line and not say 10 for example.

For example say you wanted to log the fact that a user logged in and called API...

Instead of having...

1- User Foo logged in... 2- API bar called 3- Request processed

You could have one line saying

1- User: Foo, API: Bar, Status: Processed

And you could save this as a JSON line for easy parsing later...

Answer 5

In my experience this is too much logging.

You should log errors and performance, which might be the path, response code, response time and count of http requests in the case of a REST api, but not query string parameters, request/response bodies etc.

Storing all that data has a cost and if your application is working you should never have occasion to look at it.

Additionally, storing the content of every message indiscriminately will fall foul of data protection laws.

Answer 6

When creating and debugging a webservice, it certainly helps to have proper logging to see if there are any issues. If there is an issue, you can easily find out the parameters passed to reproduce it.

For a production environment, you can get swarmed by log so logging just the errors/exceptions there makes sense.

A good logging framework allows you to filter the logging. Only log the 'error's for example.

We're using Dynatrace on production, it's a tool that logs all the webrequests that happen so no need for manual logging. Even better, you can see the call stack for each method. It's useful to find errors or figure out performance issues.