Tìm kiếm bài viết

Tìm hiểu cơ bản về các loại log trên Linux - Unix

06.01.2020

0/5 (0 Reviews)

Syslog là một giao thức client/server là giao thức dùng để chuyển log và thông điệp đến máy nhận log. Syslog còn là một gói phần mềm trong hệ thống Linux nhằm để ghi bản tin log của hệ thống trong quá trình hoạt động như của kernel, deamon, cron

    Log là gì? Log để làm gì?

    Trước hết Bạn là người quản trị mạng của một doanh nghiệp, trong hệ thống mạng của bạn có một máy chủ chứa dữ liệu rất quan trọng. Một buổi tối bạn để máy chủ đó chạy suốt đêm nhưng khi về đến nhà bạn truy cập vào máy chủ thì báo lỗi từ chối dịch vụ do không thể kết nối, buổi sáng bạn vội vã đến xem xét tình hình thì thấy một số dữ liệu đã bị mất và vấn đề lúc này là xem ai đã gây ra vấn đề trên.

    Tìm hiểu cơ bản về các loại log trên Linux - Unix

    Vậy phải làm thế nào để điều tra xử lý, hay đơn giản là tìm nguyên nhân để khắc phục hậu quả vừa xảy ra. Log sẽ giúp bạn làm việc này.

    Syslog là gì? Giới thiệu về Syslog

    Syslog là một giao thức client/server là giao thức dùng để chuyển log và thông điệp đến máy nhận log. Máy nhận log thường được gọi là syslogd, syslog daemon hoặc syslog server. Syslog có thể gửi qua UDP hoặc TCP. Các dữ liệu được gửi dạng cleartext. Syslog dùng cổng 514.

    Ngoài ra Syslog còn là một gói phần mềm trong hệ thống Linux nhằm để ghi bản tin log của hệ thống trong quá trình hoạt động như của kernel, deamon, cron, auth, hoặc các ứng dụng chạy trên hệ thống như http, dns, dhcp, ntp,..

    Syslog được phát triển năm 1980 bởi Eric Allman, nó là một phần của dự án Sendmail, và ban đầu chỉ được sử dụng duy nhất cho Sendmail. Nó đã thể hiện giá trị của mình và các ứng dụng khác cũng bắt đầu sử dụng nó. Syslog hiện nay trở thành giải pháp khai thác log tiêu chuẩn trên Unix-Linux cũng như trên hàng loạt các hệ điều hành khác và thường được tìm thấy trong các thiết bị mạng như router Trong năm 2009, Internet Engineering Task Forec (IETF) đưa ra chuẩn syslog trong RFC 5424.

    Syslog ban đầu sử dụng UDP, điều này là không đảm bảo cho việc truyền tin. Tuy nhiên sau đó IETF đã ban hành RFC 3195 (Đảm bảo tin cậy cho syslog) và RFC 6587 (Truyền tải thông báo syslog qua TCP). Điều này có nghĩa là ngoài UDP thì giờ đây syslog cũng đã sử dụng TCP để đảm bảo an toàn cho quá trình truyền tin.

    Trong chuẩn syslog, mỗi thông báo đều được dán nhãn và được gán các mức độ nghiêm trọng khác nhau. Các loại phần mềm sau có thể sinh ra thông báo: auth, authPriv, daemon, cron, ftp, dhcp, kern, mail, syslog, user,... Với các mức độ nghiêm trọng từ cao nhất trở xuống Emergency, Alert, Critical, Error, Warning, Notice, Info, and Debug.

     

    Nguồn sinh ra log

    Facility NumberNguồn tạo logÝ nghĩa
    0kernelNhững log mà do kernel sinh ra
    1userLog ghi lại cấp độ người dùng
    2mailLog của hệ thống mail
    3daemonLog của các tiến trình trên hệ thống
    4authLog từ quá trình đăng nhập hệ hoặc xác thực hệ thống
    5syslogLog từ chương trình syslogd
    6lprLog từ quá trình in ấn
    7newsThông tin từ hệ thống
    8uucpLog UUCP subsystem
    9 Clock deamon
    10authprivQuá trình đăng nhập hoặc xác thực hệ thống
    11ftpLog của FTP deamon
    12 Log từ dịch vụ NTP của các subserver
    13 Kiểm tra đăng nhập
    14 Log cảnh báo hệ thống
    15cronLog từ clock daemon
    16 - 23local 0 -local 7Log dự trữ cho sử dụng nội bộ

    Mức độ cảnh bảo

    CodeMức cảnh báoÝ nghĩa
    0emergThông báo tình trạng khẩn cấp
    1alertHệ thống cần can thiệp ngay
    2critTình trạng nguy kịch
    3errorThông báo lỗi đối với hệ thống
    4warnMức cảnh báo đối với hệ thống
    5noticeChú ý đối với hệ thống
    6infoThông tin của hệ thống
    7debugQuá trình kiểm tra hệ thống

    Định dạng chung của một gói tin syslog.

    Định dạng hoàn chỉnh của một thông báo syslog gồm có 3 phần chính như sau, và độ dài một thông báo không được vượt quá 1024 bytes:

    <PRI> HEADER MSG

    PRI

    Phần PRI hay Priority là một số được đặt trong ngoặc nhọn, thể hiện cơ sở sinh ra log hoặc mức độ nghiêm trọng, là một số gồm 8 bit:

    • 3 bit đầu tiên thể hiện cho tính nghiêm trọng của thông báo.
    • 5 bit còn lại đại diện cho sơ sở sinh ra thông báo.

    Giá trị Priority được tính như sau: Cơ sở sinh ra log x 8 + Mức độ nghiêm trọng.

    Ví dụ, thông báo từ kernel (Facility = 0) với mức độ nghiêm trọng (Severity =0) thì giá trị Priority = 0x8 +0 = 0.

    Trường hợp khác, với "local use 4" (Facility =20) mức độ nghiêm trọng (Severity =5) thì số Priority là 20 x 8 + 5 = 165.

    Vậy biết một số Priority thì làm thế nào để biết nguồn sinh log và mức độ nghiêm trọng của nó. Ta xét 1 ví dụ sau:

    Priority = 191 Lấy 191:8 = 23.875 -> Facility = 23 ("local 7") -> Severity = 191 - (23 * 8 ) = 7 (debug)

    HEADER

    Phần HEADER thì gồm các phần chính sau:

    • Time stamp - Thời gian mà thông báo được tạo ra. Thời gian này được lấy từ thời gian hệ thống ( Chú ý nếu như thời gian của server và thời gian của client khác nhau thì thông báo ghi trên log được gửi lên server là thời gian của máy client)
    • Hostname hoặc IP

    MSG

    Phần Message hay MSG chứa một số thông tin về quá trình tạo ra thông điệp đó. Gồm 2 phần chính:

    • Tag field
    • Content field

    Tag field là tên chương trình tạo ra thông báo. Content field chứa các chi tiết của thông báo

    Các câu lệnh hỗ trợ xem syslog

    Đối với các file ghi log các bạn có thể dùng một số lệnh sau để giúp cho việc xem log

    Câu lệnhCú phápÝ nghĩaGhi chú thêm
    moremore [file]Dùng xem toàn bộ nội dung của thư mucĐối với câu lênh này nôi dung được xem theo từng trang. Bạn dung dấu "cách" để chuyển trang
    tailtail [file]In ra 10 dòng cuối cùng nội dung của filethêm tùy chọn -n [số dòng] sẽ in ra số dòng theo yêu cầu
    headhead [file]In ra 10 dòng đầu tiên của nôi dụng file 
    tail -ftail -f [file]Dùng để xem ngay lâp tức khi có log đếnĐây là câu lệnh dùng phổ biến nhất nó giúp ta có thể xem ngay lập tức log mới đến, và nó sẽ in ra 10 dong cuối cùng trong nội dung file đó

    Chi tiết file cấu hình của syslog

    File cấu hình của syslog
    • Trong CENTOS, file cấu hình là /etc/rsyslog.conf . File này chứa cả các rule về log
    • Trong UBUNTU file cấu hình là /etc/rsyslog.conf nhưng các rule được định nghĩa riêng trong /etc/rsyslog.d/50-defaul.conf . File rule này được khai báo include từ file cấu hình /etc/rsyslog.conf

    Nâng cao với syslog

    Qua tìm hiểu chúng tôi nhận thức được kiến thức nâng cao hơn về phần syslog này như:

    • Chỉnh sửa bản tin log đầu ra để đáp ứng yêu cầu công việc
    • Cấu hình trên máy chủ log sao nó nó ghi thông tin đối với từng máy client một các riêng biệt và khoa học phục nhằm phục vụ cho việc kiểm tra log sau này
    • Dùng chức năng rotating log tốt
    • Ghi log lại đối với các dịch vụ như http, mysql, ntp,..
    • Có thể ghi log vào hăn một cơ sở dữ liệu để tiện cho quá trình xem log
    • Cơ chế mã hóa ssl đối với bạn tin log khi truyền trên mạng internet tránh trường hợp bị bắt gói tin -...

    Nhưng trong phạm vi bài viết này, chúng tôi chỉ giới hạn ở mức độ sơ khai nhất, các vấn đề nêu trên chúng tôi sẽ sớm làm rõ và đưa ra trong loạt các bài viết sau này về syslog.

    Rsyslog là gì

    Rsyslog - "The rocket-fast system for log processing" được bắt đầu phát triển từ năm 2004 bởi Rainer Gerhards rsyslog là một phần mềm mã nguồn mở sử dụng trên Linux dùng để chuyển tiếp các log message đến một địa chỉ trên mạng (log receiver, log server) Nó thực hiện giao thức syslog cơ bản, đặc biệt là sử dụng TCP cho việc truyền tải log từ client tới server. Hiện nay rsyslog là phần mềm được cài đặt sẵn trên hầu hết hệ thống Unix và các bản phân phối của Linux như : Fedora, openSUSE, Debian, Ubuntu, Red Hat Enterprise Linux, FreeBSD…

    Log tập trung

    Để quản lý log một cách tốt hơn, xu thế hiện nay sẽ sử dụng log tập trung. Vậy log tập trung là gì? Tác dụng của nó thế nào?

    Tác dụng của log là vô cùng to lớn vậy làm thế nào để quản lý log tốt hơn?

    Hiểu một cách đơn giản : Log tâp trung là quá trình tập trung, thu thập, phân tích... các log cần thiết từ nhiều nguồn khác nhau về một nơi an toàn để thuận lợi cho việc phân tích, theo dõi hệ thống.

    Tại sao lại phải sử dụng log tập trung?

    • Do có nhiều nguồn sinh log

      • Có nhiều nguồn sinh ra log, log nằm trên nhiều máy chủ khác nhau nên khó quản lý.
      • Nội dung log không đồng nhất (Giả sử log từ nguồn 1 có có ghi thông tin về ip mà không ghi thông tin về user name đăng nhập mà log từ nguồn 2 lại có) -> khó khăn trong việc kết hợp các log với nhau để xử lý vấn đề gặp phải.
      • Định dạng log cũng không đồng nhất -> khó khăn trong việc chuẩn hóa
    • Đảm bảo tính toàn vẹn, bí mật, sẵn sàng của log.

      • Do có nhiều các rootkit được thiết kế để xóa bỏ logs.
      • Do log mới được ghi đè lên log cũ -> Log phải được lưu trữ ở một nơi an toàn và phải có kênh truyền đủ đảm bảo tính an toàn và sẵn sàng sử dụng để phân tích hệ thống.

    Do đó lợi ích của log tập trung đem lại là

    • Giúp quản trị viên có cái nhìn chi tiết về hệ thống -> có định hướng tốt hơn về hướng giải quyết
    • Mọi hoạt động của hệ thống được ghi lại và lưu trữ ở một nơi an toàn (log server) -> đảm bảo tính toàn vẹn phục vụ cho quá trình phân tích điều tra các cuộc tấn công vào hệ thống
    • Log tập trung kết hợp với các ứng dụng thu thập và phân tích log khác nữa giúp cho việc phân tích log trở nên thuận lợi hơn -> giảm thiểu nguồn nhân lực.
     
    CÓ THỂ BẠN QUAN TÂM

    Bài Viết Cùng Chuyên Mục

    XEM THÊM
    thumbnail

    Kubernetes bài 6 - Vận hành k8s Day-Two Operations và Quản trị bằng GitOps

    22.05.2026

    Khi cụm Kubernetes của bạn đã được bảo mật cấu hình, tối ưu tài nguyên và thiết lập tự phục hồi, câu hỏi đặt ra là làm sao để duy trì sự ổn định đó trong nhiều năm tiếp theo mà không bị phụ thuộc

    thumbnail

    Kubernetes bài 5 - bảo mật Cloud Native và chuẩn DevSecOps cho K8s

    22.05.2026

    Việc siết chặt an ninh (Hardening) không phải là cấu hình một vài thông số rồi bỏ đó, mà là một tư duy phòng thủ chiều sâu.

    thumbnail

    Kubernetes bài 4 - Tối ưu Resource Auto-Healing và Scale Zero-Downtime

    22.05.2026

    Bài viết này sẽ đi sâu vào các cơ chế ở tầng Kernel giúp hệ thống tự phục hồi, chống lại các đợt tấn công cạn kiệt tài nguyên và cập nhật phiên bản mới mà người dùng không hề hay biết.

    thumbnail

    Kubernetes bài 3 - Bảo mật cấu hình k8s và config Security trên Production

    22.05.2026

    Kubernetes giải quyết bài toán này bằng hai đối tượng chuyên biệt nhưng nếu không hiểu rõ bản chất bảo mật ở tầng dưới, bạn đang tự tay dâng toàn bộ chìa khóa hệ thống cho hacker.

    thumbnail

    Kubernetes bài 2 - Mạng lưới k8s và luồng Traffic ở Packet Level

    22.05.2026

    Pod không chỉ là một container: Rất nhiều người nhầm lẫn Pod 1-1 với Container. Thực chất, Pod là đơn vị triển khai nhỏ nhất, có thể chứa một hoặc nhiều container

    Mục lục bài viết