API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · บทเรียน

บันทึกการทำงานและตัวชี้วัดของ Nginx

ตั้งค่าบันทึกการเข้าถึงและบันทึกข้อผิดพลาดของ Nginx พร้อมสำรวจวิธีดึงตัวชี้วัดเพื่อนำไปเฝ้าติดตามและวิเคราะห์

บทเรียน 1 จาก 411 ขั้นตอน

บันทึกการทำงานและตัวชี้วัดของ Nginx เป็นบทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Why Nginx Logs Matter

Nginx logs are vital for understanding your server's activity and health. They record every request and any issues that occur.

Think of them as your server's diary. By reviewing these logs, you can monitor performance, troubleshoot errors, identify security threats, and gather valuable usage metrics.

Understanding Access Logs

Access logs record every request Nginx processes. Each line details a single client request, providing insights into who accessed what, and when.

  • Client IP: Who made the request.
  • Request method & URL: What was requested.
  • Status code: Was it successful (200), an error (404, 500), etc.?
  • Response size: How much data was sent back.
  • User-Agent: The client's browser/device.

Default Access Log Format

By default, Nginx uses the 'combined' log format, which includes standard information. You'll typically find your access logs in /var/log/nginx/access.log.

Here's what a common entry looks like:

192.168.1.1 - - [10/Oct/2023:14:30:00 +0000] "GET /index.html HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (...)"

Customizing Access Log Formats

Nginx allows you to define custom log formats using the log_format directive. This is powerful for tailoring logs to your specific monitoring or analysis needs.

You can include variables like $remote_addr (client IP), $request (full request line), $status (response status code), $body_bytes_sent, and many more.

Defining a Custom Log Format

Let's create a custom log format named 'my_json_format' that outputs logs in JSON. This is great for automated parsing!

Place this inside your http block in nginx.conf:

http {
    log_format my_json_format escape=json
      '{ "time_local":"$time_local",'
      '  "remote_addr":"$remote_addr",'
      '  "request":"$request",'
      '  "status":$status,'
      '  "bytes_sent":$body_bytes_sent,'
      '  "request_time":$request_time,'
      '  "http_referrer":"$http_referer",'
      '  "http_user_agent":"$http_user_agent" }';

    server {
        listen 80;
        server_name example.com;
        access_log /var/log/nginx/json_access.log my_json_format;
        # ... other server config ...
    }
}

Understanding Error Logs

Error logs record diagnostic information about issues Nginx encounters, from configuration problems to backend connection failures.

They are crucial for debugging and maintaining server stability. You'll typically find them at /var/log/nginx/error.log.

Configuring Error Log Levels

The error_log directive allows you to specify the log file and the severity level. Nginx logs messages at or above the specified level.

  • debug: Most verbose, for deep debugging.
  • info: Informational messages.
  • notice: Normal but significant conditions.
  • warn: Potentially problematic situations.
  • error: An error occurred.
  • crit: Critical conditions.
  • alert: Action must be taken immediately.
  • emerg: System is unusable.

Setting Error Log Levels

You can configure the error log level globally in the main or http block, or specifically within a server or location block.

For production, warn or error is common to keep logs manageable. For debugging, you might temporarily set it to info or debug.

http {
    error_log /var/log/nginx/error.log warn;

    server {
        listen 80;
        server_name example.com;
        # This server's errors will also be logged at 'warn' level
        # You could override it here: error_log /path/to/server_error.log info;
    }
}

Log Rotation for Production

In production, logs can grow very large, very quickly. Log rotation is the process of archiving, compressing, and deleting old log files to prevent them from filling up your disk space.

While Nginx doesn't handle rotation itself, tools like logrotate (common on Linux) are used to manage this. You configure logrotate to periodically rotate Nginx's log files.

Nginx Log Metrics

Which of the following Nginx log variables would be most useful for calculating the average response time of your web application?

Recap: Logs for Insights

You've learned that Nginx access logs track client requests, while error logs report server issues. Customizing log formats with log_format allows you to tailor output for specific metrics or tools.

Understanding log levels (e.g., warn, error) helps control verbosity, and knowing about log rotation ensures disk space management.

These logging fundamentals are essential for effective monitoring and troubleshooting of your Nginx server.

เริ่มต้นได้ฟรี

เรียนรู้ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส
12
บทเรียน
48

คำถามที่พบบ่อย

บทเรียน “บันทึกการทำงานและตัวชี้วัดของ Nginx” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “บันทึกการทำงานและตัวชี้วัดของ Nginx” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “บันทึกการทำงานและตัวชี้วัดของ Nginx”

ตั้งค่าบันทึกการเข้าถึงและบันทึกข้อผิดพลาดของ Nginx พร้อมสำรวจวิธีดึงตัวชี้วัดเพื่อนำไปเฝ้าติดตามและวิเคราะห์ คุณปฏิบัติ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “บันทึกการทำงานและตัวชี้วัดของ Nginx” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) นี้ได้ไหม

ได้ บทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. บันทึกการทำงานและตัวชี้วัดของ Nginx
  2. การปรับจูนประสิทธิภาพ Nginx
  3. Nginx ในสภาพแวดล้อมแบบคอนเทนเนอร์
  4. การโหลดใหม่โดยไม่หยุดทำงานและการทดสอบการตั้งค่า
← กลับไปที่ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)