メインコンテンツへ移動

เนื้อหาภาษาไทย / タイ語のコンテンツ

システムガイド 内容確認済み

การ Config Logging สำหรับ Production

บทความนี้กล่าวถึงความสำคัญของการ Config Logging สำหรับ Production ซึ่งแตกต่างจากการ Logging ในช่วง Development โดยเน้นที่การกำหนด Log Levels ที่เหมาะสม, การใช้...

การ Config Logging สำหรับ Production

ในบทก่อนหน้านี้ เราได้เรียนรู้เกี่ยวกับการใช้ Static Analysis Tools เพื่อตรวจสอบโค้ดของเราก่อนที่จะนำไปใช้งานจริง ในบทนี้ เราจะมาพูดถึงอีกหนึ่งแนวทางปฏิบัติที่สำคัญสำหรับการใช้งานจริง นั่นคือการ Config Logging ให้เหมาะสมกับสภาพแวดล้อม Production เพื่อให้เราสามารถติดตามและแก้ไขปัญหาที่อาจเกิดขึ้นได้อย่างมีประสิทธิภาพ

Logging ใน Production มีความแตกต่างจากการ Logging ในช่วงพัฒนา (Development) อย่างมาก ในช่วง Development เราอาจต้องการ Log ทุกสิ่งเพื่อทำความเข้าใจการทำงานของโค้ด แต่ใน Production เราต้องระมัดระวังมากขึ้นเพื่อไม่ให้ Log ไฟล์มีขนาดใหญ่เกินไป หรือเปิดเผยข้อมูลสำคัญโดยไม่จำเป็น

Log Levels

หัวใจสำคัญของการ Config Logging ใน Production คือการกำหนด Log Levels ที่เหมาะสม Log Levels คือระดับความสำคัญของ Log Message ที่จะถูกบันทึก โดย Monolog มี Log Levels ดังนี้ (เรียงจากความสำคัญน้อยไปมาก):

  • DEBUG: ข้อมูลที่ใช้สำหรับการ Debug เท่านั้น (ไม่ควรใช้ใน Production)
  • INFO: ข้อมูลทั่วไปเกี่ยวกับการทำงานของระบบ
  • NOTICE: เหตุการณ์ที่น่าสนใจ แต่ไม่จำเป็นต้องเป็น Error
  • WARNING: เหตุการณ์ที่อาจเป็นปัญหาในอนาคต
  • ERROR: ข้อผิดพลาดที่เกิดขึ้น แต่ระบบยังสามารถทำงานต่อไปได้
  • CRITICAL: ข้อผิดพลาดร้ายแรงที่อาจทำให้ระบบหยุดทำงาน
  • ALERT: ต้องดำเนินการแก้ไขโดยด่วน
  • EMERGENCY: ระบบไม่สามารถใช้งานได้

ใน Production โดยทั่วไป เราจะตั้งค่า Log Level ให้สูงกว่า DEBUG เพื่อลดปริมาณ Log ที่ถูกบันทึก ระดับที่เหมาะสมมักจะเป็น INFO, WARNING หรือ ERROR ขึ้นอยู่กับความต้องการของระบบ

Trade-off: การตั้ง Log Level สูงเกินไป (เช่น ERROR) อาจทำให้เราพลาดข้อมูลสำคัญที่ช่วยในการแก้ไขปัญหา การตั้ง Log Level ต่ำเกินไป (เช่น DEBUG) อาจทำให้ Log ไฟล์มีขนาดใหญ่เกินไปและยากต่อการวิเคราะห์

แนวปฏิบัติที่ดี: ควรเริ่มจากการตั้ง Log Level ที่สูง (เช่น WARNING) และค่อยๆ ลดระดับลงหากจำเป็น เมื่อพบปัญหาที่ต้องใช้ข้อมูลเพิ่มเติมในการ Debug

use Monolog\Logger;
use Monolog\Handler\StreamHandler;

// สร้าง Logger
$logger = new Logger('production');

// กำหนด Handler ให้บันทึก Log Level ตั้งแต่ WARNING ขึ้นไป
$handler = new StreamHandler('path/to/your/production.log', Logger::WARNING);
$logger->pushHandler($handler);

// บันทึก Log
$logger->info('This will not be logged in production');
$logger->warning('This is a warning message');
$logger->error('This is an error message');

Rotating Files

เมื่อระบบทำงานไปเรื่อยๆ Log ไฟล์จะค่อยๆ มีขนาดใหญ่ขึ้นเรื่อยๆ ซึ่งอาจทำให้เกิดปัญหาในการบริหารจัดการไฟล์ และยากต่อการวิเคราะห์ข้อมูล ดังนั้นเราจึงควรใช้ Rotating Files เพื่อแบ่ง Log ไฟล์ออกเป็นไฟล์เล็กๆ ตามช่วงเวลา หรือขนาดที่กำหนด

Monolog มี Handler หลายประเภทที่รองรับ Rotating Files เช่น RotatingFileHandler ซึ่งจะสร้าง Log ไฟล์ใหม่ทุกวัน หรือเมื่อไฟล์มีขนาดเกินที่กำหนด

use Monolog\Logger;
use Monolog\Handler\RotatingFileHandler;

// สร้าง Logger
$logger = new Logger('production');

// กำหนด Handler ให้สร้าง Log ไฟล์ใหม่ทุกวัน และเก็บ Log ไว้ 7 วัน
$handler = new RotatingFileHandler('path/to/your/production.log', 7, Logger::WARNING);
$logger->pushHandler($handler);

// บันทึก Log
$logger->warning('This is a warning message');

Trade-off: การใช้ Rotating Files ช่วยให้ Log ไฟล์มีขนาดเล็กลงและง่ายต่อการบริหารจัดการ แต่ก็อาจทำให้การค้นหาข้อมูลใน Log ไฟล์ทั้งหมดทำได้ยากขึ้น

แนวปฏิบัติที่ดี: ควรเลือกรูปแบบการ Rotating Files ที่เหมาะสมกับความต้องการของระบบ และกำหนดระยะเวลาในการเก็บ Log ไฟล์ให้สอดคล้องกับนโยบายการเก็บรักษาข้อมูล

Remote Logging

ในบางกรณี เราอาจต้องการส่ง Log ไปยัง Server กลางเพื่อรวบรวมและวิเคราะห์ข้อมูลจากหลายๆ ระบบ การทำ Remote Logging ช่วยให้เราสามารถตรวจสอบสถานะของระบบทั้งหมดได้จากที่เดียว และช่วยให้การ Debug ทำได้ง่ายขึ้น

Monolog รองรับการทำ Remote Logging ผ่าน Handler หลายประเภท เช่น SyslogHandler, SocketHandler และ GelfHandler

SyslogHandler: ส่ง Log ไปยัง Syslog Server

use Monolog\Logger;
use Monolog\Handler\SyslogHandler;

// สร้าง Logger
$logger = new Logger('production');

// กำหนด Handler ให้ส่ง Log ไปยัง Syslog Server
$handler = new SyslogHandler('my_app', LOG_USER, Logger::WARNING);
$logger->pushHandler($handler);

// บันทึก Log
$logger->warning('This is a warning message');

SocketHandler: ส่ง Log ไปยัง Server ผ่าน Socket

use Monolog\Logger;
use Monolog\Handler\SocketHandler;

// สร้าง Logger
$logger = new Logger('production');

// กำหนด Handler ให้ส่ง Log ไปยัง Server ผ่าน Socket
$handler = new SocketHandler('tcp://localhost:12345', Logger::WARNING);
$logger->pushHandler($handler);

// บันทึก Log
$logger->warning('This is a warning message');

GelfHandler: ส่ง Log ไปยัง Graylog Server (Graylog เป็น Open Source Log Management System)

use Monolog\Logger;
use Monolog\Handler\GelfHandler;
use Gelf\Publisher;
use Gelf\Transport\UdpTransport;

// สร้าง Logger
$logger = new Logger('production');

// กำหนด Handler ให้ส่ง Log ไปยัง Graylog Server
$transport = new UdpTransport("localhost", 12201, UdpTransport::CHUNK_SIZE_WAN);
$publisher = new Publisher($transport);
$handler = new GelfHandler($publisher, Logger::WARNING);
$logger->pushHandler($handler);

// บันทึก Log
$logger->warning('This is a warning message');

Trade-off: การทำ Remote Logging ช่วยให้การบริหารจัดการ Log ทำได้ง่ายขึ้น แต่ก็อาจเพิ่มความซับซ้อนในการ Config และอาจมีปัญหาเรื่อง Network Latency

แนวปฏิบัติที่ดี: ควรเลือก Protocol และ Server ที่เหมาะสมกับความต้องการของระบบ และควรมีการเข้ารหัสข้อมูลเพื่อป้องกันการดักฟังข้อมูล

สรุป: การ Config Logging สำหรับ Production เป็นสิ่งสำคัญที่ช่วยให้เราสามารถติดตามและแก้ไขปัญหาที่อาจเกิดขึ้นในระบบได้อย่างมีประสิทธิภาพ การเลือก Log Levels ที่เหมาะสม, การใช้ Rotating Files, และการทำ Remote Logging เป็นแนวทางปฏิบัติที่ดีที่ควรนำไปพิจารณา

Office.in.th Custom Service

この構成をもとにシステムを開発・カスタマイズしたいですか?

Office.in.th は、エンタープライズ Web アプリケーション、API 連携、官民の業務管理システムの設計・開発を承り、長期的なサポートも提供します。

ソフトウェア開発サービスを見る