Cách khai thác tốt nhất nhật ký PostgreSQL

Là một RDBMS hiện đại, PostgreSQL đi kèm với nhiều tham số để tinh chỉnh. Một trong những lĩnh vực cần xem xét là PostgreSQL nên ghi nhật ký các hoạt động của nó như thế nào. Việc ghi nhật ký thường bị bỏ qua trong quản lý cơ sở dữ liệu Postgres, và nếu không được bỏ qua, thường được đặt sai. Điều này xảy ra bởi vì hầu hết thời gian, mục đích của việc ghi nhật ký là không rõ ràng. Tất nhiên, lý do cơ bản của việc ghi nhật ký là điều ai cũng biết, nhưng điều đôi khi còn thiếu là sự hiểu biết về cách các nhật ký sẽ được sử dụng.

Yêu cầu ghi nhật ký của mỗi tổ chức là duy nhất và do đó, cách định cấu hình ghi nhật ký PostgreSQL cũng sẽ khác nhau. Những gì một công ty dịch vụ tài chính cần nắm bắt trong nhật ký cơ sở dữ liệu của mình sẽ khác với những gì một công ty xử lý thông tin sức khỏe quan trọng cần ghi lại. Và trong một số trường hợp, chúng cũng có thể tương tự.

Trong bài viết này, tôi sẽ trình bày một số phương pháp cơ bản để khai thác tốt nhất các bản ghi PostgreSQL. Blog này không phải là một cuốn sách quy tắc cứng và nhanh chóng; rất hoan nghênh độc giả chia sẻ suy nghĩ của họ trong phần bình luận. Tuy nhiên, để có được giá trị tốt nhất từ nó, tôi yêu cầu người đọc suy nghĩ về cách họ muốn sử dụng nhật ký máy chủ cơ sở dữ liệu PostgreSQL của họ:

Lý do tuân thủ pháp luật trong đó thông tin cụ thể cần được thu thập
Kiểm tra bảo mật khi cần có các chi tiết sự kiện cụ thể
Khắc phục sự cố hiệu suất trong đó các truy vấn và thông số của chúng sẽ được ghi lại
Hỗ trợ hoạt động hàng ngày trong đó một số chỉ số nhất định sẽ được theo dõi

Như đã nói, hãy bắt đầu.

Không thực hiện các thay đổi thủ công đối với postgresql.conf

Mọi thay đổi trong tệp postgresql.conf phải được thực hiện bằng hệ thống quản lý cấu hình như Puppet, Ansible hoặc Chef. Điều này đảm bảo các thay đổi có thể theo dõi được và có thể quay trở lại phiên bản trước một cách an toàn nếu cần thiết. Điều này đúng khi bạn thực hiện các thay đổi đối với các thông số ghi nhật ký.

Các DBA thường tạo nhiều bản sao của tệp postgresql.conf, mỗi bản có các tham số hơi khác nhau, mỗi bản cho một mục đích khác nhau. Quản lý thủ công các tệp cấu hình khác nhau là một công việc cồng kềnh nếu không muốn nói là dễ xảy ra lỗi. Mặt khác, một hệ thống quản lý cấu hình có thể được thực hiện để đổi tên và sử dụng các phiên bản khác nhau của tệp postgresql.conf dựa trên một tham số được truyền cho nó. Tham số này sẽ xác định mục đích của phiên bản hiện tại. Khi nhu cầu được hoàn thành, tệp cấu hình cũ có thể được khôi phục lại bằng cách thay đổi cùng một tham số đầu vào.

Ví dụ:nếu bạn muốn ghi lại tất cả các câu lệnh đang chạy trên phiên bản PostgreSQL của mình, một tệp cấu hình có giá trị tham số “log_statement =all” có thể được sử dụng. Khi không cần ghi lại tất cả các câu lệnh - có thể là sau bài tập khắc phục sự cố - thì tệp cấu hình trước đó có thể được khôi phục.

Sử dụng các tệp nhật ký riêng biệt cho PostgreSQL

Tôi khuyên bạn nên bật trình thu thập nhật ký gốc của PostgreSQL trong các hoạt động bình thường. Để bật tính năng ghi nhật ký gốc PostgreSQL, hãy đặt thông số sau thành bật:

logging_collector = on

Có hai lý do cho nó:

Trước hết, trong các hệ thống bận rộn, hệ điều hành có thể không ghi lại các thông báo PostgreSQL một cách nhất quán trong nhật ký hệ thống (giả sử cài đặt dựa trên nix) và thường bỏ các thông báo. Với ghi nhật ký PostgreSQL gốc, một daemon riêng biệt sẽ đảm nhận việc ghi lại các sự kiện. Khi PostgreSQL bận, quá trình này sẽ trì hoãn việc ghi vào tệp nhật ký để cho phép các chuỗi truy vấn kết thúc. Điều này có thể chặn toàn bộ hệ thống cho đến khi sự kiện nhật ký được ghi. Do đó, sẽ hữu ích khi ghi lại các thông báo ít dài dòng hơn trong nhật ký (như chúng ta sẽ thấy ở phần sau) và sử dụng các tiền tố dòng nhật ký rút gọn.

Thứ hai - và như chúng ta sẽ thấy ở phần sau - nhật ký phải được thu thập, phân tích cú pháp, lập chỉ mục và phân tích bằng tiện ích Quản lý nhật ký. Để PostgreSQL ghi lại các sự kiện của nó trong nhật ký hệ thống sẽ có nghĩa là tạo thêm một lớp lọc và đối sánh mẫu trong phần Quản lý nhật ký để lọc ra tất cả các “thông báo nhiễu”. Các tệp nhật ký chuyên dụng có thể dễ dàng được phân tích cú pháp và lập chỉ mục cho các sự kiện bằng hầu hết các công cụ.

Đặt Đích nhật ký thành stderr

Hãy xem xét tham số “log_destination”. Nó có thể có bốn giá trị:

log_destination = stderr | syslog | csv | eventlog

Trừ khi có lý do chính đáng để lưu các sự kiện nhật ký ở định dạng được phân tách bằng dấu phẩy hoặc nhật ký sự kiện trong Windows, tôi khuyên bạn nên đặt tham số này thành stderr. Điều này là do với đích tệp CSV, giá trị thông số “log_line_prefix” tùy chỉnh sẽ không có bất kỳ ảnh hưởng nào, tuy nhiên, tiền tố có thể được tạo để chứa thông tin có giá trị.

Mặt khác, nhật ký CSV có thể được nhập dễ dàng vào bảng cơ sở dữ liệu và sau đó được truy vấn bằng cách sử dụng SQL chuẩn. Một số người dùng PostgreSQL thấy nó thuận tiện hơn so với việc xử lý các tệp nhật ký thô. Như chúng ta sẽ thấy ở phần sau, các giải pháp Quản lý nhật ký hiện đại có thể phân tích cú pháp nguyên bản các nhật ký PostgreSQL và tự động tạo thông tin chi tiết có ý nghĩa từ chúng. Với CSV, người dùng phải thực hiện báo cáo và hiển thị theo cách thủ công.

Cuối cùng thì nó phụ thuộc vào sự lựa chọn của bạn. Nếu bạn cảm thấy thoải mái khi tạo đường dẫn nhập dữ liệu của riêng mình để tải nhật ký CSV vào các bảng cơ sở dữ liệu, xóa và chuyển đổi dữ liệu cũng như tạo báo cáo tùy chỉnh phù hợp với nhu cầu kinh doanh của mình, thì hãy đảm bảo “log_destination” được đặt thành CSV.

Sử dụng tên tệp nhật ký có ý nghĩa

Khi các tệp nhật ký PostgreSQL được lưu cục bộ, việc tuân theo một kiểu đặt tên có vẻ không cần thiết. Kiểu tên tệp mặc định là “postgresql-% Y-% m-% d_% H% M% S.log” cho các nhật ký có định dạng không phải CSV, đủ cho hầu hết các trường hợp.

Việc đặt tên trở nên quan trọng khi bạn đang lưu tệp nhật ký từ nhiều máy chủ vào một vị trí trung tâm như máy chủ nhật ký chuyên dụng, ổ đĩa NFS được gắn kết hoặc thùng S3. Tôi khuyên bạn nên sử dụng hai tham số trong trường hợp như vậy:

log_directory
log_filename

Để lưu trữ các tệp nhật ký từ nhiều phiên bản ở một nơi, trước tiên, hãy tạo một hệ thống phân cấp thư mục riêng biệt cho từng phiên bản. Đây có thể là một cái gì đó giống như sau:

/<Application_Name>/<Environment_Name>/<Instance_Name>

Sau đó, “log_directory” của từng phiên bản PostgreSQL có thể được trỏ đến thư mục được chỉ định của nó.

Sau đó, mỗi phiên bản có thể sử dụng cùng một giá trị tham số “log_filename”. Giá trị mặc định sẽ tạo một tệp như

postgresql_2020-08-25_2359.log

Để sử dụng một tên có ý nghĩa hơn, hãy đặt “log_filename” thành một cái tên như sau:

log_filename = "postgresql_%A-%d-%B_%H%M"

Các tệp nhật ký sau đó sẽ được đặt tên như sau:

postgresql_Saturday-23-August_2230

Sử dụng tiền tố dòng nhật ký có ý nghĩa

Tiền tố dòng nhật ký PostgreSQL có thể chứa thông tin có giá trị nhất bên cạnh bản thân thông báo thực tế. Tài liệu Postgres hiển thị một số ký tự thoát cho cấu hình tiền tố sự kiện nhật ký. Các trình tự thoát này được thay thế bằng các giá trị trạng thái khác nhau tại thời gian chạy. Một số ứng dụng như pgBadger yêu cầu tiền tố dòng nhật ký cụ thể.

Tôi khuyên bạn nên đưa thông tin sau vào tiền tố:

Thời gian của sự kiện (không tính mili giây):% t
Tên khách hàng từ xa hoặc địa chỉ IP:% h
Tên người dùng:% u
Cơ sở dữ liệu đã truy cập:% d
Tên ứng dụng:% a
ID quy trình:% p
Kết thúc đầu ra của quy trình không phải phiên:% q
Số dòng nhật ký cho mỗi phiên hoặc quá trình, bắt đầu từ 1:% l

Để hiểu nội dung của mỗi trường trong tiền tố, chúng ta có thể thêm một chuỗi ký tự nhỏ trước trường. Vì vậy, giá trị ID quy trình có thể được đặt trước bằng chữ “PID =”, tên cơ sở dữ liệu có thể được đặt trước bằng “db =”, v.v. Đây là một ví dụ:

log_line_prefix = 'time=%t, pid=%p %q db=%d, usr=%u, client=%h , app=%a, line=%l '

Tùy thuộc vào vị trí của sự kiện, tiền tố dòng nhật ký sẽ hiển thị các giá trị khác nhau. Cả quy trình nền và quy trình người dùng sẽ ghi lại thông điệp của chúng trong tệp nhật ký. Đối với các quy trình hệ thống, tôi đã chỉ định% q, sẽ loại bỏ bất kỳ văn bản nào sau ID quy trình (% p). Bất kỳ phiên nào khác sẽ hiển thị tên cơ sở dữ liệu, tên người dùng, địa chỉ máy khách, tên ứng dụng và một dòng được đánh số cho mỗi sự kiện.

Ngoài ra, tôi đã bao gồm một khoảng trắng sau tiền tố dòng nhật ký. Khoảng trống này ngăn cách tiền tố sự kiện nhật ký với thông báo sự kiện thực tế. Nó không nhất thiết phải là một ký tự khoảng trắng - có thể sử dụng bất kỳ thứ gì như dấu hai chấm (::), dấu gạch ngang (-) hoặc dấu phân tách có ý nghĩa khác.

Ngoài ra, hãy đặt thông số “log_hostname” thành 1:

log_hostname = 1

Nếu không có điều này, chỉ địa chỉ IP của máy khách sẽ được hiển thị. Trong hệ thống sản xuất, đây thường sẽ là địa chỉ của proxy, bộ cân bằng tải hoặc bộ gộp kết nối. Trừ khi bạn biết thuộc lòng địa chỉ IP của các hệ thống này, nếu không thì việc ghi lại tên máy chủ của chúng có thể rất hữu ích. Tuy nhiên, việc tra cứu DNS cũng sẽ thêm thời gian để trình nền ghi nhật ký ghi vào tệp.

Một tham số khác nên được đặt cùng với “log_line_prefix” là “log_timezone”. Đặt điều này thành múi giờ địa phương của máy chủ sẽ đảm bảo các sự kiện được ghi lại dễ dàng theo dõi từ dấu thời gian của chúng thay vì chuyển đổi sang giờ địa phương trước. Trong đoạn mã bên dưới, chúng tôi đang đặt log_timzeone thành Múi giờ chuẩn miền Đông Úc:

log_timezone = 'Australia/Sydney'

Chỉ kết nối nhật ký

Hai tham số kiểm soát cách PostgreSQL ghi lại các kết nối và ngắt kết nối của máy khách. Cả hai tham số đều bị tắt theo mặc định. Dựa trên các yêu cầu bảo mật của tổ chức của bạn, bạn có thể muốn đặt một trong những thứ này thành 1 và cái kia thành 0 (trừ khi bạn đang sử dụng một công cụ như pgBadger - sẽ có thêm thông tin về điều đó sau).

log_connections = 1
log_disconnections = 0

Đặt log_connections thành 1 sẽ ghi lại tất cả các kết nối được ủy quyền cũng như đã thử kết nối. Điều này rõ ràng là tốt cho việc kiểm tra bảo mật:một cuộc tấn công vũ phu có thể dễ dàng được xác định từ các bản ghi. Tuy nhiên, với cài đặt này được bật, môi trường PostgreSQL bận rộn với hàng nghìn, thậm chí hàng trăm kết nối hợp lệ tồn tại trong thời gian ngắn có thể thấy tệp nhật ký bị ngập.

Tuy nhiên, nó cũng có thể xác định các vấn đề ứng dụng có thể không rõ ràng. Một số lượng lớn các lần thử kết nối từ nhiều địa chỉ máy khách hợp lệ khác nhau có thể cho thấy phiên bản đó cần một bộ cân bằng tải hoặc dịch vụ tổng hợp kết nối ở phía trước nó. Một số lượng lớn các lần thử kết nối từ một địa chỉ máy khách có thể phát hiện ra một ứng dụng có quá nhiều luồng cần một số loại điều chỉnh.

Chỉ ghi các hoạt động DDL và DML

Có rất nhiều tranh luận xung quanh những gì nên được ghi lại trong nhật ký Postgres - tức là giá trị của tham số “log_statement” là gì. Nó có thể có ba giá trị:

log_statement = 'off' | 'ddl' | 'mod' | 'all'

Có thể bạn muốn đặt điều này thành “tất cả” để nắm bắt mọi câu lệnh SQL đang chạy trên máy chủ, nhưng điều này có thể không phải lúc nào cũng là một ý tưởng hay trong thực tế.

Các hệ thống sản xuất bận rộn chủ yếu chạy các câu lệnh SELECT, đôi khi hàng nghìn câu lệnh đó mỗi giờ. Phiên bản có thể đang chạy hoàn toàn tốt mà không có bất kỳ vấn đề nào về hiệu suất. Đặt tham số này thành “tất cả” trong những trường hợp như vậy sẽ tạo gánh nặng cho daemon ghi nhật ký một cách không cần thiết vì nó phải ghi tất cả các câu lệnh đó vào tệp.

Tuy nhiên, những gì bạn muốn nắm bắt là bất kỳ lỗi dữ liệu nào hoặc những thay đổi trong cấu trúc cơ sở dữ liệu đã gây ra một số loại vấn đề. Thay đổi cơ sở dữ liệu không mong muốn hoặc trái phép gây ra nhiều vấn đề ứng dụng hơn là lựa chọn dữ liệu; đó là lý do tại sao tôi khuyên bạn nên đặt thông số này thành “mod”. Với cài đặt này, PostgreSQL sẽ ghi lại tất cả các thay đổi DDL và DML vào tệp nhật ký.

Nếu phiên bản PostgreSQL của bạn bận vừa phải (hàng chục truy vấn mỗi giờ), hãy đặt tham số này thành “tất cả”. Khi bạn đang khắc phục sự cố các truy vấn SELECT chạy chậm hoặc tìm kiếm quyền truy cập dữ liệu trái phép, bạn cũng có thể tạm thời đặt cài đặt này thành “tất cả”. Một số ứng dụng như pgBadger cũng yêu cầu bạn đặt điều này thành “tất cả”.

Ghi nhật ký Thông báo “Cảnh báo” và Cập nhật

Nếu tham số “log_statement” quyết định loại câu lệnh nào sẽ được ghi lại, thì hai tham số sau sẽ cho biết mức độ chi tiết của thông báo:

log_min_messages
log_min_error_statement

Mỗi sự kiện PostgreSQL có một mức thông báo liên quan. Mức độ tin nhắn có thể là bất kỳ thứ gì từ GỠ LỖI cho đến PANIC ngắn gọn. Mức độ càng thấp, thông điệp càng dài. Giá trị mặc định cho thông số “log_min_messages” là “WARNING”. Tôi khuyên bạn nên giữ nó ở mức này trừ khi bạn muốn các thư thông tin cũng được ghi vào nhật ký.

Tham số “log_min_error_statement” kiểm soát lỗi ném câu lệnh SQL nào sẽ được ghi lại. Giống như “log_min_message”, bất kỳ câu lệnh SQL nào có mức độ nghiêm trọng của lỗi bằng hoặc cao hơn giá trị được chỉ định trong “log_min_error_statement” sẽ được ghi lại. Giá trị mặc định là “ERROR” và tôi khuyên bạn nên giữ giá trị mặc định.

Giữ các thông số thời lượng nhật ký ở chế độ mặc định

Sau đó, chúng tôi có hai tham số sau:

log_duration
log_min_duration_statement

Tham số “log_duration” nhận một giá trị boolean. Khi nó được đặt thành 1, thời lượng của mọi câu lệnh đã hoàn thành sẽ được ghi lại. Nếu được đặt thành 0, thời lượng câu lệnh sẽ không được ghi lại. Đây là giá trị mặc định và tôi khuyên bạn nên giữ nó về 0 trừ khi bạn đang khắc phục sự cố hiệu suất. Tính toán và ghi lại thời lượng của câu lệnh làm cho công cụ cơ sở dữ liệu thực hiện nhiều công việc hơn (bất kể nhỏ đến mức nào) và khi nó được ngoại suy cho hàng trăm hoặc hàng nghìn truy vấn, khoản tiết kiệm có thể đáng kể.

Cuối cùng, chúng ta có tham số “log_min_duration_statement”. Khi tham số này được đặt (không có bất kỳ đơn vị nào, được tính bằng mili giây), thời lượng của bất kỳ câu lệnh nào bằng hoặc lâu hơn giá trị tham số sẽ được ghi lại. Đặt giá trị tham số này thành 0 sẽ ghi lại thời lượng của tất cả các câu lệnh đã hoàn thành. Đặt giá trị này thành -1 sẽ tắt tính năng ghi thời lượng câu lệnh. Đây là giá trị mặc định và tôi khuyên bạn nên giữ nguyên giá trị đó.

Lần duy nhất bạn muốn đặt tham số này thành 0 là khi bạn muốn tạo đường cơ sở hiệu suất cho các truy vấn thường xuyên chạy. Tuy nhiên, hãy nhớ rằng, nếu tham số “log_statement” được đặt, các câu lệnh được ghi sẽ không được lặp lại trong các thông báo nhật ký hiển thị thời lượng. Vì vậy, bạn sẽ cần tải các tệp nhật ký trong bảng cơ sở dữ liệu, sau đó kết hợp các giá trị ID quá trình và ID phiên từ tiền tố dòng nhật ký để xác định các câu lệnh liên quan và thời lượng của chúng.

Dù có nghĩa là gì, khi bạn đã có đường cơ sở cho mỗi truy vấn thường chạy, bạn có thể đặt thông số “log_min_duration_statement” thành giá trị cao nhất trong số các giá trị đường cơ sở. Bây giờ, bất kỳ truy vấn nào chạy lâu hơn giá trị cơ sở cao nhất sẽ là một ứng cử viên để tinh chỉnh.

Giữ độ dài thông báo lỗi ở chế độ mặc định

Tham số “log_error_verbosity” có thể có ba giá trị có thể có:

log_error_verbosity = terse | standard | verbose

Tham số này kiểm soát lượng thông tin PostgreSQL sẽ ghi lại cho mỗi sự kiện được ghi trong tệp nhật ký. Trừ khi gỡ lỗi một ứng dụng cơ sở dữ liệu, thông số này tốt nhất nên giữ ở “mặc định”. Chế độ tiết sẽ hữu ích khi bạn cần nắm bắt tệp hoặc tên hàm và số dòng ở đó đã tạo ra lỗi. Đặt giá trị này thành “terse” sẽ ngăn chặn việc ghi nhật ký truy vấn, điều này cũng có thể không hữu ích.

Tìm Chính sách xoay vòng nhật ký phù hợp với Của bạn Trường hợp sử dụng

Tôi khuyên bạn nên tạo chính sách xoay vòng nhật ký dựa trên kích thước hoặc tuổi của tệp nhật ký, chứ không phải cả hai. Hai tham số cấu hình PostgreSQL chỉ định cách các bản ghi cũ được lưu trữ và các bản ghi mới được tạo:

log_rotation_age = <number of minutes>
log_rotation_size = <number of kilobytes>

Giá trị mặc định cho “log_rotration_age” là 24 giờ và giá trị mặc định cho “log_rotation_size” là 10 megabyte.

Trong hầu hết các trường hợp, việc có chính sách xoay vòng kích thước không phải lúc nào cũng đảm bảo thông báo nhật ký cuối cùng trong tệp nhật ký đã lưu trữ hoàn toàn chỉ được chứa trong tệp đó.

Nếu “log_rotation_age” được giữ ở giá trị mặc định là 24 giờ, thì mỗi tệp có thể dễ dàng được xác định và kiểm tra riêng, vì mỗi tệp sẽ chứa các sự kiện trong ngày. Tuy nhiên, điều này cũng không đảm bảo rằng mỗi tệp sẽ là một đơn vị nhật ký độc lập trong 24 giờ qua. Đôi khi một truy vấn hoạt động chậm có thể mất hơn 24 giờ để hoàn thành; các sự kiện có thể xảy ra khi tệp cũ bị đóng và tệp mới được tạo. Điều này có thể xảy ra khi thực hiện công việc hàng loạt hàng đêm, dẫn đến một số phần của truy vấn được ghi lại trong một tệp và phần còn lại trong tệp khác.

Đề xuất của chúng tôi là tìm khoảng thời gian xoay vòng nhật ký phù hợp với của bạn ca sử dụng. Kiểm tra chênh lệch thời gian giữa hai khoảng thời gian liên tiếp có hoạt động thấp nhất (ví dụ:từ thứ Bảy đến thứ Bảy tiếp theo). Sau đó, bạn có thể đặt giá trị “log_rotation_age” thành chênh lệch thời gian đó và trong một trong những khoảng thời gian đó, hãy khởi động lại dịch vụ PostgreSQL. Bằng cách đó, PostgreSQL sẽ xoay tệp nhật ký hiện tại khi giai đoạn tạm lắng tiếp theo xảy ra. Tuy nhiên, nếu bạn cần khởi động lại dịch vụ giữa các khoảng thời gian này, vòng quay nhật ký sẽ lại bị lệch. Bạn sẽ phải lặp lại quá trình này sau đó. Nhưng giống như nhiều thứ khác trong PostgreSQL, thử và sai sẽ quyết định giá trị tốt nhất. Ngoài ra, nếu bạn đang sử dụng tiện ích quản lý nhật ký, tuổi hoặc kích thước xoay vòng nhật ký sẽ không thành vấn đề vì tác nhân quản lý nhật ký sẽ nhập từng sự kiện từ tệp khi nó được thêm vào.

Sử dụng các công cụ như pgBadger

pgBadger là một trình phân tích nhật ký PostgreSQL mạnh mẽ có thể tạo thông tin chi tiết rất hữu ích từ các tệp nhật ký Postgres. Nó là một công cụ mã nguồn mở được viết bằng Perl với một dấu ấn rất nhỏ trong cỗ máy mà nó chạy. Công cụ này được chạy từ dòng lệnh và đi kèm với một số lượng lớn các tùy chọn. Nó sẽ lấy một hoặc nhiều nhật ký làm đầu vào và có thể tạo báo cáo HTML với số liệu thống kê chi tiết về:

Các truy vấn chờ đợi thường xuyên nhất.
Các truy vấn tạo ra hầu hết các tệp tạm thời hoặc các tệp tạm thời lớn nhất
Các truy vấn chạy chậm nhất
Thời lượng truy vấn trung bình
Các truy vấn thường chạy nhất
Các lỗi thường gặp nhất trong các truy vấn
Người dùng và ứng dụng chạy truy vấn
Số liệu thống kê về điểm kiểm tra.
Autovacuum và tự động phân tích thống kê.
Khóa thống kê
Sự kiện lỗi (hoảng sợ, chết người, lỗi và cảnh báo).
Cấu hình kết nối và phiên (theo cơ sở dữ liệu, người dùng, ứng dụng)
Hồ sơ phiên
Cấu hình truy vấn (loại truy vấn, truy vấn theo cơ sở dữ liệu / ứng dụng)
Thống kê I / O
v.v.

Như tôi đã đề cập trước đây, một số thông số cấu hình liên quan đến nhật ký phải được kích hoạt để nắm bắt tất cả các sự kiện nhật ký để pgBadger có thể phân tích hiệu quả các nhật ký đó. Vì điều này có thể tạo ra các tệp nhật ký lớn với nhiều sự kiện, pgBadger chỉ nên được sử dụng để tạo điểm chuẩn hoặc khắc phục sự cố hiệu suất. Sau khi tạo nhật ký chi tiết, các thông số cấu hình có thể được thay đổi trở lại giá trị ban đầu của chúng. Để phân tích nhật ký liên tục, tốt nhất là sử dụng ứng dụng quản lý nhật ký chuyên dụng.

Nếu bạn cảm thấy thoải mái hơn khi thực hiện mọi việc trong dấu nhắc lệnh và sử dụng chế độ xem hệ thống, bạn sẽ muốn sử dụng pg_stat_statements. Trên thực tế, điều này nên được bật trong bất kỳ cài đặt PostgreSQL sản xuất nào.

pg_stat_statements là một phần mở rộng PostgreSQL và có cài đặt mặc định ngay bây giờ. Để bật tính năng này, thông số cấu hình “shared_preload_libraries” phải có pg_stat_statements là một trong các giá trị của nó. Sau đó, nó có thể được cài đặt giống như bất kỳ tiện ích mở rộng nào khác bằng lệnh “TẠO MỞ RỘNG”. Tiện ích mở rộng tạo ra chế độ xem pg_stat_statement cung cấp thông tin có giá trị liên quan đến truy vấn.

Sử dụng ứng dụng quản lý nhật ký để có được thông tin chi tiết

Có rất nhiều tiện ích quản lý nhật ký trên thị trường và ngày nay hầu hết các tổ chức đều sử dụng một hoặc nhiều tiện ích. Dù có công cụ nào đi chăng nữa, tôi khuyên bạn nên sử dụng nó để thu thập và quản lý nhật ký PostgreSQL.

Có một số lý do cho nó:

Việc phân tích cú pháp, phân tích và lọc tạp âm từ các tệp nhật ký dễ dàng hơn nhiều bằng một công cụ tự động. Đôi khi, một sự kiện có thể kéo dài nhiều tệp nhật ký dựa trên thời lượng của sự kiện và tuổi hoặc kích thước xoay vòng nhật ký. Việc có trình quản lý nhật ký giúp việc trình bày toàn bộ thông tin này trở nên đơn giản hơn nhiều.

Các giải pháp quản lý nhật ký ngày nay thường đi kèm với khả năng phân tích cú pháp các nhật ký PostgreSQL tích hợp sẵn. Một số cũng đi kèm với trang tổng quan có thể hiển thị các chỉ số phổ biến nhất được trích xuất từ các nhật ký này.

Hầu hết các ứng dụng quản lý nhật ký hiện đại cũng cung cấp các tính năng tìm kiếm, bộ lọc, đối sánh mẫu, tương quan sự kiện và phân tích xu hướng hỗ trợ AI mạnh mẽ. Những gì mắt thường không thể nhìn thấy có thể dễ dàng hiển thị bằng những công cụ này.

Cuối cùng, việc sử dụng trình quản lý nhật ký để lưu trữ nhật ký PostgreSQL cũng có nghĩa là các sự kiện sẽ được lưu lại cho hậu thế, ngay cả khi các tệp gốc bị xóa vô tình hoặc độc hại.

Mặc dù có những lợi thế rõ ràng khi sử dụng ứng dụng quản lý nhật ký, nhưng nhiều tổ chức có những hạn chế về đâu nhật ký của họ có thể sống. Đây là trường hợp điển hình với các giải pháp dựa trên SaaS trong đó nhật ký thường được lưu bên ngoài ranh giới địa lý của tổ chức - điều có thể không tuân thủ các yêu cầu quy định.

Trong những trường hợp như vậy, tôi khuyên bạn nên chọn nhà cung cấp có sự hiện diện của trung tâm dữ liệu cục bộ - nếu có thể - hoặc sử dụng trình quản lý nhật ký tự quản lý được lưu trữ trong mạng của tổ chức, chẳng hạn như ngăn xếp ELK.

Lời cuối cùng

Nhật ký máy chủ PostgreSQL có thể là một mỏ vàng thông tin khi được định cấu hình thích hợp. Bí quyết là xác định những gì cần ghi và số lượng cần ghi, và quan trọng hơn, kiểm tra xem các bản ghi có thể cung cấp thông tin phù hợp khi cần thiết hay không. Nó sẽ là một vấn đề thử và sai, nhưng những gì tôi đã thảo luận ở đây hôm nay sẽ cho một khởi đầu khá tốt. Như tôi đã nói ở phần đầu, tôi rất vui khi biết kinh nghiệm của bạn về việc định cấu hình ghi nhật ký PostgreSQL để có kết quả tối ưu.