Linux Labs

Observability: metrics, alerts, logs / Stage 8 of 9

Investigating with logs

Not running Starting usually ~20 s
Leave the lesson

Step 1 of 6 · on a machine · 4 min

The site answers 500

What you will learn

  • Tell what nginx's access.log and error.log record, and find the cause of a 500 answer in the application's journal by the request time.
  • Read journal record fields in journalctl -o json and pick the ones you need with jq.
  • Match nginx answers, service records and kernel messages by time.

The shop's users complain: the order list will not open. nginx stands in front of the shop — it takes requests and passes /orders addresses to the lab-shop application, while serving the home page itself. Request the orders and look at nginx's logs: access.log and error.log.

Exercise · look

Request the orders

Request /orders and look at nginx's logs: the whole access.log and error.log.

First, predict

access.log shows 500 for /orders. What will nginx's error.log show?

Now start the exercise, run the command and compare your prediction with the output.

Sign in and start The machine is available after signing in
Check yourself 1 question

access.log shows 500 for /orders, and nginx's error.log is empty. What follows from this?

  • The file belongs to www-data — the user nginx runs as. It is empty because nginx had no failures of its own.

  • Without the application nginx would answer 502 and write the failure to error.log. A 500 code is the answer of whoever got the request.

  • nginx would have written its own error to error.log, and it is empty. Besides, the home page answers 200 in the same seconds.

The application gave the 500 answer, and nginx only passed it on.

Ubuntu 24.04
Loading…