Tại sao hầu hết các tệp nhật ký sử dụng văn bản thuần túy thay vì định dạng nhị phân?

Ghi nhật ký là một cái gì đó là cần thiết nhưng (tương đối) hiếm khi được sử dụng. Vì vậy, nó có thể được thực hiện nhỏ gọn hơn nhiều về mặt lưu trữ.

Ví dụ: dữ liệu được ghi lại phổ biến nhất như ip, ngày, giờ và các dữ liệu khác có thể được biểu diễn dưới dạng một số nguyên đang được lưu trữ dưới dạng văn bản.

Nếu ghi nhật ký được lưu trữ dưới dạng dữ liệu nhị phân, rất nhiều không gian có thể được bảo tồn do đó yêu cầu ít vòng quay hơn và tăng tuổi thọ đĩa, đặc biệt là với SSD nơi ghi bị hạn chế.

Một số người có thể nói rằng đó là một vấn đề nhỏ đến mức nó không thực sự quan trọng, nhưng xem xét nỗ lực cần thiết để xây dựng cơ chế như vậy, thật vô nghĩa. Bất cứ ai cũng có thể làm điều này trong hai ngày khi rảnh rỗi, tại sao mọi người không làm điều này?

systemdnổi tiếng lưu trữ các tệp nhật ký của nó ở định dạng nhị phân. Các vấn đề chính tôi đã nghe với nó là:

1. nếu nhật ký bị hỏng thì khó phục hồi vì nó cần dụng cụ chuyên dụng
2. họ không phải con người có thể đọc được, vì vậy bạn không thể sử dụng các công cụ tiêu chuẩn như vi, grep, tailvv để phân tích chúng

Lý do chính cho việc sử dụng định dạng nhị phân (theo hiểu biết của tôi) là vì nó được coi là dễ dàng hơn để tạo các chỉ mục, v.v. để đối xử với nó giống như một tệp cơ sở dữ liệu.

Tôi sẽ lập luận rằng lợi thế không gian đĩa là tương đối nhỏ (và giảm dần) trong thực tế. Nếu bạn muốn lưu trữ một lượng lớn đăng nhập thì việc nén các bản ghi cuộn thực sự khá hiệu quả.

Về sự cân bằng, các lợi thế của công cụ và sự quen thuộc có thể sẽ sai về phía ghi nhật ký văn bản trong hầu hết các trường hợp.

Tại sao hầu hết các tệp nhật ký sử dụng văn bản thuần túy thay vì định dạng nhị phân?

Tìm kiếm từ "văn bản" trong bài viết Wikipedia về triết lý Unix , ví dụ bạn sẽ tìm thấy các câu như:

McIlroy, khi đó là người đứng đầu Bell Labs CSRC (Trung tâm nghiên cứu khoa học máy tính) và là người phát minh ra đường ống Unix, [9] đã tóm tắt triết lý Unix như sau: [10]

Đây là triết lý của Unix: Viết các chương trình làm một việc và làm tốt. Viết chương trình để làm việc cùng nhau. Viết chương trình để xử lý các luồng văn bản, bởi vì đó là một giao diện phổ quát.

Hoặc ví dụ, từ những điều cơ bản của triết lý Unix ,

Quy tắc thành phần: Thiết kế các chương trình được kết nối với các chương trình khác.

Thật khó để tránh việc lập trình quá đơn điệu nếu không có chương trình nào của bạn có thể nói chuyện với nhau.

Truyền thống Unix khuyến khích mạnh mẽ các chương trình viết đọc và viết các định dạng đơn giản, văn bản, định hướng theo luồng, độc lập với thiết bị. Trong Unix cổ điển, càng nhiều chương trình càng tốt được viết dưới dạng các bộ lọc đơn giản, lấy một luồng văn bản đơn giản trên đầu vào và xử lý nó thành một luồng văn bản đơn giản khác ở đầu ra.

Mặc dù thần thoại phổ biến, thực tế này được ưa chuộng không phải vì các lập trình viên Unix ghét giao diện người dùng đồ họa. Đó là bởi vì nếu bạn không viết các chương trình chấp nhận và phát ra các luồng văn bản đơn giản, việc kết nối các chương trình lại với nhau sẽ khó khăn hơn nhiều.

Các luồng văn bản đến các công cụ Unix như các thông điệp gửi đến các đối tượng trong một thiết lập hướng đối tượng. Sự đơn giản của giao diện luồng văn bản thực thi việc đóng gói các công cụ. Các hình thức giao tiếp giữa các quá trình phức tạp hơn, như các cuộc gọi thủ tục từ xa, cho thấy xu hướng liên quan đến các chương trình với bên trong của nhau quá nhiều.

Bất cứ ai cũng có thể làm điều này trong hai ngày khi rảnh rỗi, tại sao mọi người không làm điều này?

Lưu trữ tệp nhật ký trong nhị phân chỉ là khởi đầu (và tầm thường). Sau đó, bạn cần phải viết công cụ để:

• Hiển thị toàn bộ tệp nhật ký ( edit)
• Hiển thị phần cuối của nhật ký mà không cần đọc phần đầu của nó ( tail -f)
• Tìm kiếm nội dung trong tệp ( grep)
• Bộ lọc để chỉ hiển thị nội dung được chọn / thú vị (sử dụng biểu thức lọc phức tạp tùy ý)
• Gửi nhật ký cho người khác không có phần mềm giải mã tệp nhật ký của bạn
• Sao chép và dán một đoạn của tệp nhật ký
• Đọc tệp nhật ký trong khi chương trình (tạo tệp nhật ký) vẫn đang được phát triển và gỡ lỗi
• Đọc tệp nhật ký từ các phiên bản cũ của phần mềm (được triển khai trên các trang web của khách hàng và đang chạy).

Rõ ràng phần mềm cũng có thể và cũng sử dụng các định dạng tệp nhị phân (ví dụ: đối với cơ sở dữ liệu quan hệ) nhưng nó không có giá trị (theo nghĩa YAGNI ), thường không đáng làm, đối với các tệp nhật ký.

Có rất nhiều giả định gây tranh cãi ở đây.

Ghi nhật ký là một phần không thể thiếu của (hầu hết) mọi công việc tôi từng làm. Đó là điều cần thiết nếu bạn muốn bất kỳ loại khả năng hiển thị nào về sức khỏe của các ứng dụng của bạn. Tôi nghi ngờ rằng đó là một cách sử dụng "rìa"; hầu hết các tổ chức tôi đã tham gia với việc xem xét nhật ký rất quan trọng.

Lưu trữ nhật ký dưới dạng nhị phân có nghĩa là bạn phải giải mã chúng trước khi bạn có thể đọc chúng. Nhật ký văn bản có ưu điểm của sự đơn giản và dễ sử dụng. Nếu bạn đang dự tính tuyến đường nhị phân, bạn cũng có thể lưu trữ nhật ký trong cơ sở dữ liệu, nơi bạn có thể thẩm vấn chúng và phân tích thống kê chúng.

SSD hiện đáng tin cậy hơn so với ổ cứng hiện nay và các đối số chống lại việc ghi nhiều phần lớn là tranh luận. Nếu bạn thực sự lo lắng về điều đó, hãy lưu trữ nhật ký của bạn trên một ổ cứng thông thường.

Các tệp nhật ký là một phần quan trọng của bất kỳ ứng dụng nghiêm trọng nào: nếu việc đăng nhập trong ứng dụng là tốt, thì chúng sẽ cho bạn biết những sự kiện quan trọng nào đã xảy ra và khi nào; những lỗi đã xảy ra; và sức khỏe ứng dụng chung vượt xa mọi hoạt động giám sát đã được thiết kế. Người ta thường nghe về một vấn đề, kiểm tra chẩn đoán tích hợp của ứng dụng (bật bảng điều khiển web của nó hoặc sử dụng công cụ chẩn đoán như JMX), sau đó dùng đến để kiểm tra nhật ký tập tin.

Nếu bạn sử dụng định dạng phi văn bản, thì ngay lập tức bạn sẽ gặp phải một trở ngại: làm thế nào để bạn đọc nhật ký nhị phân? Với công cụ đọc nhật ký, không có trên các máy chủ sản xuất của bạn! Hoặc là vậy, nhưng trời ơi, chúng tôi đã thêm một lĩnh vực mới và đây là độc giả cũ. Chúng tôi đã không kiểm tra điều này? Có, nhưng không ai triển khai nó ở đây. Trong khi đó, màn hình của bạn đang bắt đầu sáng lên với những người dùng ping bạn.

Hoặc có lẽ đây không phải là ứng dụng của bạn, nhưng bạn đang hỗ trợ và bạn nghĩ rằng bạn biết đây là hệ thống khác và WTF? các bản ghi ở định dạng nhị phân? Ok, bắt đầu đọc các trang wiki, và bạn bắt đầu từ đâu? Bây giờ tôi đã sao chép chúng qua máy cục bộ của mình, nhưng - chúng bị hỏng? Tôi đã thực hiện một số loại chuyển giao không nhị phân? Hoặc là công cụ đọc nhật ký bị rối?

Nói tóm lại, các công cụ đọc văn bản là đa nền tảng và có mặt khắp nơi, và nhật ký thường tồn tại lâu dài và đôi khi cần phải đọc vội vàng . Nếu bạn phát minh ra một định dạng nhị phân, thì bạn sẽ bị cắt khỏi cả một thế giới các công cụ dễ hiểu và dễ sử dụng. Mất nghiêm trọng chức năng chỉ khi bạn cần nó.

Hầu hết các môi trường ghi nhật ký đều thỏa hiệp: giữ cho các bản ghi hiện tại có thể đọc và hiện tại, và nén các bản ghi cũ hơn. Điều đó có nghĩa là bạn có được lợi ích của việc nén - trên thực tế, vì định dạng nhị phân sẽ không thu hẹp các thông điệp tường trình. Đồng thời, bạn có thể sử dụng ít hơn và grep và như vậy.

Vì vậy, những lợi ích có thể có thể phát sinh từ việc sử dụng nhị phân? Một lượng nhỏ hiệu quả không gian - ngày càng không quan trọng. Ít hơn (hoặc nhỏ hơn) viết? Chà, có lẽ - thực ra, số lần ghi sẽ liên quan đến số lần xác nhận đĩa, do đó, nếu các dòng nhật ký nhỏ hơn đáng kể so với kích thước khối của đĩa, thì SSD sẽ được gán các khối mới nhiều lần. Vì vậy, nhị phân là một lựa chọn thích hợp nếu:

• bạn đang viết một lượng lớn dữ liệu có cấu trúc
• các bản ghi phải được tạo ra đặc biệt nhanh chóng
• bạn không cần phải phân tích chúng trong "điều kiện hỗ trợ"

nhưng điều này nghe có vẻ ít giống như đăng nhập ứng dụng; đây là các tập tin đầu ra hoặc hồ sơ hoạt động. Đặt chúng vào một tệp có lẽ chỉ còn một bước nữa là ghi chúng vào cơ sở dữ liệu.

BIÊN TẬP

Tôi nghĩ rằng có một sự nhầm lẫn chung ở đây giữa "nhật ký chương trình" (theo khung ghi nhật ký) so với "bản ghi" (như trong nhật ký truy cập, hồ sơ đăng nhập, v.v.). Tôi nghi ngờ câu hỏi liên quan chặt chẽ nhất đến câu hỏi sau, và trong trường hợp đó, vấn đề ít được xác định rõ hơn. Hoàn toàn có thể chấp nhận được đối với bản ghi thông báo hoặc nhật ký hoạt động ở định dạng nhỏ gọn, đặc biệt là nó có thể được xác định rõ và được sử dụng để phân tích thay vì xử lý sự cố. Các công cụ thực hiện việc này bao gồm tcpdumpvà trình giám sát hệ thống Unix sar. Mặt khác, nhật ký chương trình có xu hướng đặc biệt hơn nhiều.

Một ví dụ về nhật ký nhị phân có phần phổ biến rộng rãi: nhật ký sự kiện Windows. Về mặt chuyên nghiệp, điều này cho phép các thông điệp tường trình khá dài dòng (và do đó hy vọng sẽ hữu ích) mà hầu như không mất phí, có thể là một cái gì đó như

Cảnh báo: Hàng foobars cần làm đã tăng thêm 517 mục trong 90 giây qua. Nếu điều này xảy ra khoảng một lần mỗi ngày, không có gì phải lo lắng. Nếu nó xảy ra thường xuyên hơn hoặc liên tiếp nhanh chóng, bạn có thể muốn kiểm tra dung lượng RAM có sẵn cho ứng dụng foobar. Tuy nhiên, nếu nó xảy ra cùng với sự kiện 12345, có vẻ như bạn đang sử dụng cơ sở dữ liệu lỗi thời và bạn nên gọi hỗ trợ theo số + 1-555-12345 để tránh mất dữ liệu.

Phần chính của thông báo này chỉ tồn tại một lần dưới dạng tài nguyên được cài đặt cùng với ứng dụng. Tuy nhiên, nếu tài nguyên này không được cài đặt đúng cách (ví dụ: vì trong khi đó, phiên bản mới hơn đã được cài đặt không còn hỗ trợ thông báo lỗi thời này), tất cả những gì bạn thấy trong nhật ký sự kiện là một thông điệp tiêu chuẩn chỉ là từ ngữ ưa thích cho

Dunno, một cái gì đó với "517" và "90".

và không còn hữu ích trong bất kỳ cách nào.

Hai câu hỏi chính bạn muốn hỏi trước khi chọn giữa văn bản và nhị phân là:

• Khán giả của tôi là ai
• Tôi cần truyền tải nội dung gì?

Một ý kiến ​​phổ biến là khán giả của một thông điệp tường trình là một con người. Đây rõ ràng không phải là một giả định hoàn hảo, bởi vì có rất nhiều kịch bản thu thập dữ liệu nhật ký ngoài kia, nhưng nó là một phổ biến. Trong trường hợp này, việc truyền đạt thông tin trong một phương tiện mà con người cảm thấy thoải mái là điều hợp lý. Văn bản có một truyền thống lâu đời là phương tiện này.

Đối với nội dung, xem xét rằng một bản ghi nhị phân phải có định dạng được xác định rõ. Định dạng phải được xác định rõ, đủ để người khác viết phần mềm hoạt động trên các nhật ký đó. Một số nhật ký có cấu trúc khá tốt (câu hỏi của bạn liệt kê một số). Các nhật ký khác cần khả năng truyền đạt nội dung dưới dạng ngôn ngữ tự nhiên ít được xác định rõ. Các trường hợp ngôn ngữ tự nhiên như vậy là một kết hợp kém cho các định dạng nhị phân.

Đối với các bản ghi có thể được mô tả tốt trong nhị phân, bạn phải đưa ra lựa chọn. Bởi vì văn bản hoạt động cho tất cả mọi người, nó thường được xem là lựa chọn mặc định. Nếu bạn đăng nhập kết quả của bạn bằng văn bản, mọi người có thể làm việc với nhật ký của bạn. Nó đã được chứng minh hàng ngàn lần. Các tệp nhị phân là khó khăn hơn. Kết quả là, có thể các nhà phát triển xuất văn bản đơn giản vì mọi người đều biết những gì sẽ hành xử như thế nào.

TL; DR: Kích thước không thực sự quan trọng, nhưng sự tiện lợi khi sử dụng

Trước hết, trong khi so sánh các lợi thế tương ứng của định dạng văn bản và nhị phân cho lưu trữ nhật ký ngắn hạn là một câu hỏi quan trọng, kích thước không thực sự quan trọng. Hai lý do cho điều này là:

1. Nhật ký là thông tin dư thừa sẽ nén rất tốt: theo kinh nghiệm của tôi, không hiếm khi thấy các tệp nhật ký nén có kích thước bằng 5% hoặc nhỏ hơn kích thước của tệp gốc. Do đó, sử dụng văn bản hoặc định dạng nhị phân sẽ không có bất kỳ tác động có thể đo lường nào đối với việc lưu trữ nhật ký trong thời gian dài.

2. Dù chúng tôi chọn định dạng nào, nhật ký sẽ nhanh chóng lấp đầy đĩa máy chủ nếu chúng tôi không triển khai tệp nhật ký của hệ thống chìm, có thể nén và gửi tệp nhật ký tới nền tảng lưu trữ dài hạn. Sử dụng định dạng nhị phân có thể làm chậm điều này một chút nhưng ngay cả thay đổi theo hệ số 10 cũng không thành vấn đề.

Văn bản so với định dạng nhật ký nhị phân

Lời hứa của các hệ thống Unix là, nếu chúng ta học cách sử dụng bộ công cụ tiêu chuẩn làm việc trên các tệp văn bản có cấu trúc theo dòng - chẳng hạn như grep , sort , tham gia , sed và awk - chúng ta sẽ có thể sử dụng chúng để nhanh chóng lắp ráp các nguyên mẫu thực hiện bất kỳ công việc nào chúng tôi muốn, mặc dù chậm và thô lỗ. Khi nguyên mẫu đã chứng minh tính hữu dụng của nó, chúng ta có thể chọn biến nó trong một phần mềm thực sự được thiết kế để đạt được hiệu suất hoặc thêm các tính năng hữu ích khác. Điều này, ít nhất là theo sự hiểu biết của tôi, bản chất của triết lý Unix.

Nói cách khác, nếu chúng ta có thể cần phải thực hiện các phương pháp điều trị và phân tích thì ngày nay chúng ta không thể tìm ra, nếu chúng ta không biết ai nên thực hiện phân tích này, v.v. thì chúng ta đang ở giai đoạn sử dụng các nguyên mẫu và định dạng văn bản cho Nhật ký có lẽ là tối ưu. Nếu chúng ta cần liên tục thực hiện một tập hợp nhỏ các phương pháp điều trị được xác định rõ, thì chúng ta sẽ gặp phải tình huống nên thiết kế một hệ thống phần mềm lâu năm để thực hiện phân tích và định dạng nhị phân hoặc cấu trúc này cho các bản ghi, chẳng hạn như cơ sở dữ liệu quan hệ, có khả năng tối ưu.

(Cách đây một thời gian, tôi đã viết một bài đăng trên blog về điều này.)

Các tệp nhật ký có định dạng văn bản vì chúng có thể dễ dàng đọc bằng bất kỳ loại trình soạn thảo văn bản nào hoặc bằng cách hiển thị nội dung thông qua lệnh console.

Tuy nhiên, một số tệp nhật ký ở định dạng nhị phân nếu có nhiều dữ liệu. Ví dụ: sản phẩm tôi đang làm việc trên các cửa hàng có tối đa 15000 hồ sơ. Để lưu trữ các bản ghi trong số lượng phòng ít nhất, chúng được lưu trữ trong hệ nhị phân. Tuy nhiên, một ứng dụng đặc biệt phải được viết để xem các bản ghi hoặc chuyển đổi chúng sang định dạng có thể được sử dụng (ví dụ: bảng tính).

Tóm lại, không phải tất cả các tệp nhật ký đều ở định dạng văn bản. Định dạng văn bản có một lợi thế là không cần các công cụ tùy chỉnh để xem nội dung. Khi có nhiều dữ liệu, tệp có thể ở định dạng nhị phân . Định dạng nhị phân sẽ cần một ứng dụng (tùy chỉnh) để đọc dữ liệu và hiển thị ở định dạng có thể đọc được. Nhiều dữ liệu có thể được đóng gói thành một định dạng nhị phân. Việc sử dụng định dạng văn bản hay định dạng nhị phân là một quyết định dựa trên lượng dữ liệu và dễ dàng xem nội dung.

Trong các hệ thống nhúng mà tôi có thể không có sẵn kênh đầu ra trong thời gian chạy, ứng dụng không đủ khả năng đạt được tốc độ do áp dụng ghi nhật ký, hoặc việc ghi nhật ký sẽ thay đổi hoặc che giấu hiệu ứng tôi đang cố gắng ghi lại, tôi thường xuyên đã dùng đến việc nhồi dữ liệu nhị phân vào một mảng hoặc bộ đệm vòng và in printf () vào cuối quá trình chạy thử hoặc bỏ dữ liệu thô và viết một trình thông dịch để in nó thành có thể đọc được. Dù bằng cách nào, tôi muốn kết thúc với dữ liệu có thể đọc được.

Trong các hệ thống có nhiều tài nguyên hơn, tại sao lại phát minh ra các kế hoạch để tối ưu hóa những gì không cần tối ưu hóa?

Các tệp nhật ký được dự định để hỗ trợ gỡ lỗi các vấn đề. Thông thường, không gian ổ cứng rẻ hơn nhiều so với thời gian kỹ thuật. Các tệp nhật ký sử dụng văn bản vì có nhiều công cụ để làm việc với văn bản (chẳng hạn như tail -f). Ngay cả HTTP cũng sử dụng văn bản thuần túy (xem thêm tại sao chúng tôi không gửi nhị phân xung quanh thay vì văn bản trên http ).

Ngoài ra, rẻ hơn để phát triển hệ thống ghi nhật ký văn bản đơn giản và xác minh rằng nó hoạt động, dễ gỡ lỗi hơn nếu gặp sự cố và dễ dàng khôi phục bất kỳ thông tin hữu ích nào trong trường hợp hệ thống bị lỗi và làm hỏng một phần nhật ký.

Một tệp văn bản bị hỏng vẫn có thể đọc được xung quanh phần bị hỏng. Một tệp nhị phân bị hỏng có thể đáng nhớ, nhưng nó cũng có thể không. Ngay cả khi nó là đáng yêu, nó sẽ đòi hỏi nhiều công việc hơn một chút. Lý do khác là định dạng ghi nhật ký nhị phân làm cho ít có khả năng trong quá trình vội vàng tạo ra "sửa lỗi tạm thời" (hay còn gọi là "sửa lỗi vĩnh viễn nhất"), giải pháp ghi nhật ký sẽ được sử dụng thay vì một thứ có thể được tạo nhanh hơn.

Chúng tôi tin tưởng vào thử nghiệm đơn vị để đạt được và duy trì sự mạnh mẽ của phần mềm của chúng tôi. (Hầu hết các mã của chúng tôi chạy trong một máy chủ, không đầu; phân tích hậu kỳ của các tệp nhật ký là một chiến lược chính.). Gần như tất cả các lớp trong việc thực hiện của chúng tôi làm một số đăng nhập. Một phần quan trọng trong thử nghiệm đơn vị của chúng tôi là việc sử dụng các logger 'giả' được sử dụng khi thử nghiệm đơn vị. Một thử nghiệm đơn vị tạo ra một logger giả và cung cấp nó cho vật phẩm đang được thử nghiệm. Sau đó (khi hữu ích / phù hợp) sẽ phân tích những gì đã ghi (đặc biệt là lỗi và cảnh báo). Sử dụng định dạng nhật ký dựa trên văn bản giúp việc này dễ dàng hơn nhiều vì nhiều lý do tương tự như phân tích được thực hiện trên nhật ký 'thực': có nhiều công cụ theo ý của bạn nhanh chóng sử dụng và thích nghi.

Trong lịch sử, Nhật ký là bản ghi chính thức, viết tay và tuần tự các sự kiện. Khi máy móc có khả năng ghi lại các sự kiện, chúng được ghi vào một thiết bị đầu ra sao chép cứng như máy in teletype, tạo ra một bản ghi tuần tự vĩnh viễn nhưng chỉ có thể xử lý văn bản và đôi khi đổ chuông ...

Quay lại thời kỳ máy tính lớn của tôi, chúng tôi đã sử dụng định dạng nhật ký nhị phân được thiết kế tùy chỉnh. Lý do chính không phải để tiết kiệm không gian, đó là vì chúng tôi muốn nhật ký chiếm không gian hữu hạn bằng cách ghi đè các mục cũ bằng mục mới; điều cuối cùng chúng tôi muốn là không thể chẩn đoán các vấn đề gây ra bởi các đĩa đã đầy (trong năm 1980 không gian đĩa được sử dụng để tiêu tốn 1000 đô la / Mb, vì vậy mọi người không mua nhiều hơn mức cần thiết).

Bây giờ tôi vẫn thích ý tưởng về một tệp nhật ký tròn, và nếu các hệ điều hành cung cấp một con thú như vậy, tôi sẽ sử dụng nó mà không do dự. Nhưng nhị phân là một ý tưởng tồi. Bạn thực sự không muốn lãng phí thời gian để tìm đúng lệnh để giải mã tệp nhật ký khi bạn gặp vấn đề nghiêm trọng cần giải quyết.