Làm thế nào để có nhiều luồng nhật ký trong docker


21

Chúng tôi có một ứng dụng ghi ba loại nhật ký thành ba tệp riêng biệt: nhật ký truy cập, nhật ký ứng dụng chung và nhật ký hệ thống. Định dạng (và mục đích) của các bản ghi này rất khác nhau. Và chúng tôi có các logforward riêng biệt gửi chúng riêng cho hệ thống ghi nhật ký tập trung của chúng tôi.

Dựa trên các bản ghi xử lý như nguyên tắc luồng sự kiện , chúng tôi đang suy nghĩ về việc chuyển từ sử dụng tệp sang thiết bị xuất chuẩn. Mặc dù chúng tôi biết một số lợi ích của phương pháp này, điều này cũng có nghĩa là chúng tôi sẽ nhận được một luồng hợp nhất các nhật ký được định dạng khác nhau, mà chúng tôi sẽ cần phải phân tách lại trước khi chúng tôi có thể gửi chúng đến hệ thống trung tâm của mình (Kibana / Splunk / v.v.), hoặc bên trong đó.

Chúng tôi đang tự hỏi liệu có bất kỳ công cụ hoặc khuyến nghị nào về cách chúng ta nên tiếp cận tình huống này.


4
Tôi không nghĩ nó đáng giá. Tại sao làm việc chăm chỉ hơn để hợp nhất và sau đó phân chia luồng nhật ký, chỉ vì một số "nguyên tắc"? Tập tin là tốt. Tập tin làm việc. Điều này nghe có vẻ quá sức. Tôi có thể nói có thể chuyển tất cả các bản ghi vào syslog, với các thẻ khác nhau, v.v. nhưng tôi phải nói, nếu ai đó trong nhóm của tôi đề xuất điều này .. tôi sẽ .. thất vọng.
Assaf Lavie

Bởi vì việc sử dụng tệp có một số loại ác mộng quản lý khác, đặc biệt nếu chúng được tạo từ bên trong thùng chứa docker. Hiện tại có vẻ như những bất lợi từ việc chuyển sang thiết bị xuất chuẩn vượt trội hơn lợi ích cho trường hợp sử dụng của chúng tôi, nhưng chúng tôi đã gặp rắc rối với cách tiếp cận dựa trên tệp của mình
SztupY

3
Tôi không biết về "ác mộng". Tôi biết rằng đây là cách họ đã hoàn thành trong một thời gian và có rất nhiều phần mềm giúp bạn làm điều này. Các tệp nhật ký được xoay, đọc với các điểm kiểm tra - một tệp là một sự trừu tượng hóa tuyệt vời cho việc này. Tôi sẽ không mua vào một nguyên tắc bán cho tôi những cơn ác mộng mới vì sợ những mẫu cũ, quen thuộc. Các bản ghi nhật ký của bạn được ghi vào một tệp hoặc được xử lý trong bộ nhớ (ít nhất là miễn là chúng được di chuyển xung quanh trong thùng chứa). Chúc may mắn đạt được độ tin cậy của các tệp nhật ký với bộ tách & hợp nhất luồng trong bộ nhớ.
Assaf Lavie

@AssafLavie Bạn nên viết nó trong một câu trả lời có thể được nâng cấp. IMHO đó là một quan điểm hoàn toàn hợp lệ.
Dan Cornilescu

2
Tôi đến đây với cùng một câu hỏi. Một thực tế đơn giản là chức năng ghi nhật ký tích hợp của docker phụ thuộc vào mọi thứ sẽ xuất hiện trên thiết bị xuất chuẩn / stderr, do đó trình điều khiển ghi nhật ký và hệ sinh thái của các công cụ bên thứ 3 cũng được xây dựng xung quanh nó. Tôi cũng muốn bỏ tất cả các bản ghi của mình vào một khối lượng máy chủ, nhưng tôi biết rằng tôi sẽ phải tiếp tục quay lại và quản lý khi các container của tôi chuyển sang k8s hoặc openshift hoặc gke hoặc bất cứ điều gì, trong khi nếu tôi đi theo docker cách tiếp cận tuyệt vời nó sẽ mượt mà hơn nhiều. Trong khi đó tôi sẽ tiếp tục tìm câu trả lời cho câu hỏi hợp pháp này
hoàng

Câu trả lời:


13

Tôi vẫn đang tìm kiếm một cách tiếp cận hợp nhất / tách bản thân mình, nhưng trong khi đó phương pháp này được tài liệu Kubernetes đề xuất có vẻ giống như một giải pháp âm thanh: Sử dụng thùng chứa sidecar cho mỗi bản ghi riêng biệt của bạn .

"Sidecar" là bất kỳ bộ chứa docker nào mà bạn sử dụng cùng với bộ chứa docker khác để làm việc với nó theo một cách nào đó. Trong trường hợp này cho mỗi ba bản ghi của bạn, bạn sẽ có một thùng chứa riêng biệt để quét hoặc theo dõi các bản ghi và đầu ra thành thiết bị xuất chuẩn.

Bằng cách này, mỗi container log-sidecar của bạn có docker-log riêng từ thiết bị xuất chuẩn của chính nó. Tách biệt như thế này, bạn có thể sử dụng các thực hành docker tiêu chuẩn (và kubernetes, v.v.) để phân tách hoặc tổng hợp. Đây là những gì trang Kubernetes nói:

Cách tiếp cận này cho phép bạn tách một số luồng nhật ký khỏi các phần khác nhau trong ứng dụng của bạn, một số trong đó có thể thiếu hỗ trợ để ghi vào thiết bị xuất chuẩn hoặc thiết bị xuất chuẩn. Logic đằng sau các bản ghi chuyển hướng là tối thiểu, do đó, nó hầu như không phải là một chi phí đáng kể. Ngoài ra, vì thiết bị xuất chuẩn và thiết bị xuất chuẩn được xử lý bởi kubelet, bạn có thể sử dụng các công cụ tích hợp như nhật ký kubectl.

"Luồng nhật ký riêng biệt" xuất phát từ việc gắn thẻ tích hợp mà docker áp dụng cho các bản ghi từ các container khác nhau, được mô tả trong tài liệu về docker tại đây:

Tùy chọn nhật ký thẻ chỉ định cách định dạng thẻ xác định thông điệp nhật ký của người chứa. Theo mặc định, hệ thống sử dụng 12 ký tự đầu tiên của id container. Để ghi đè hành vi này, chỉ định một tùy chọn thẻ


Điều đáng nói là nhược điểm của phương pháp tiếp cận thùng chứa log-sidecar này, trích dẫn: "Lưu ý rằng mặc dù sử dụng CPU và bộ nhớ thấp, việc ghi nhật ký vào một tệp và sau đó truyền chúng tới thiết bị xuất chuẩn có thể tăng gấp đôi mức sử dụng đĩa". Tôi tự hỏi nếu có ai thử phương pháp này trong thực tế.
yusong

8

Ý tưởng hợp nhất chúng thành một luồng chỉ để phân chia chúng sau này nghe có vẻ đau đớn. Tôi không có lý do để tự làm việc này, nhưng đây là nơi tôi bắt đầu:

  • Khi bạn chạy bộ chứa docker, hãy tạo một âm lượng sao cho dễ xem / gửi nhật ký từ máy chủ.
  • Sử dụng một cái gì đó như remote_syslog2 để gửi nhật ký đến trình thu thập nhật ký của bạn

Bạn cảm thấy hơi kém lịch sự khi phải thực hiện một số thiết lập trên máy chủ, nhưng nếu bạn sử dụng một cái gì đó giống như nơi bạn có thể chạy một cuốn sách và thiết lập nó trong khi triển khai vào hộp thì cũng không nên xấu.


Giải pháp này có thể được kết hợp với các đường ống được đặt tên, vấn đề duy nhất với các đường ống được đặt tên là chúng không hoạt động trên tất cả các hệ thống ngay bây giờ. Họ không làm việc trên Mac
Jens
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.