2016-06-08 24 views
14

Như các tài liệu AWS gợi ý:Sử dụng Logging python với AWS Lambda

import logging 
logger = logging.getLogger() 
logger.setLevel(logging.INFO) 
def my_logging_handler(event, context): 
    logger.info('got event{}'.format(event)) 
    logger.error('something went wrong') 

Bây giờ tôi thực hiện:

import logging 
logging.basicConfig(level = logging.INFO) 
logging.info("Hello World!") 

Đoạn đầu tiên của bản in mã trong Cloud Watch console, nhưng thứ hai không.

Tôi không thấy bất kỳ sự khác biệt nào khi hai đoạn mã đang sử dụng trình ghi nhật ký gốc.

+0

Bạn đang bỏ lỡ "quay lại" Hello World! "" – error2007s

+0

Tại sao không làm giống như trong đoạn mã đầu tiên? Nhận nhật ký đã được khởi tạo và sau đó sử dụng trình ghi nhật ký đã nói. –

+1

@ HEADLESS_0NE: Tôi có thể dùng nắm tay. Nhưng tôi muốn hiểu lý do tại sao hành vi này. –

Trả lời

2

Có lẽ không tham chiếu cùng một trình ghi nhật ký. Trong đoạn mã đầu tiên, hãy ghi lại sự trở lại của: logging.Logger.manager.loggerDict

Nó sẽ trả lại dict nhật ký đã được khởi tạo.

Ngoài ra, từ các tài liệu logging, một lưu ý quan trọng về logging.basicConfig:

Liệu cấu hình cơ bản cho hệ thống đăng nhập bằng cách tạo ra một StreamHandler với một Formatter mặc định và thêm nó vào các logger gốc. Các hàm debug(), info(), warning(), error() và critical() sẽ gọi basicConfig() tự động nếu không có trình xử lý nào được định nghĩa cho trình ghi gốc.

Chức năng này không làm gì nếu trình ghi nhật ký gốc đã có trình xử lý được định cấu hình cho nó.

Nguồn: https://docs.python.org/2/library/logging.html#logging.basicConfig

+0

Các đoạn mã được tách riêng. Vì vậy, đoạn thứ hai không có cấu hình ghi nhật ký, do đó, nó sẽ cấu hình trình ghi nhật ký gốc. Và nếu tôi gọi logging.info, nó sẽ sử dụng trình ghi nhật ký gốc. Đối với tôi, không có sự khác biệt từ đoạn đầu tiên. –

+0

@ HEADLESS_0NE ở ngay đây. Có vẻ như trong lambda một logger đã được cấu hình. Nếu tôi làm như trên nhưng đặt mức độ DEBUG thì tôi thấy nhiều nhật ký hơn tôi đang sản xuất (tôi không tự sản xuất bất kỳ bản thân nào trong số này): '[DEBUG] \t 2016-10-29T09: 01: 28.376Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t Thu 0 [DEBUG] \t 2016-10-29T09: 01: 28.389Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t IOWriteTask ({ 'bù đắp': 0}) sắp chờ đợi cho tương lai sau [] [DEBUG] \t 2016-10-29T09: 01: 28.389Z \t 45e6c8bd-9db6-11e6-aa56-43d43acb066b \t IOWriteTask ({'offset': 0}) đang chờ đợi tương lai phụ thuộc ' –

6

Tôi đã có một vấn đề tương tự, và tôi nghi ngờ rằng container lambda đang kêu gọi logging.basicConfig thêm xử lý TRƯỚC mã lambda được nhập khẩu. Điều này có vẻ như hình thức xấu ...

Cách giải quyết là xem trình xử lý nhật ký gốc đã được định cấu hình hay chưa, hãy loại bỏ chúng, thêm trình định dạng của tôi và mức nhật ký mong muốn (sử dụng basicConfig) và khôi phục các trình xử lý.

Xem bài viết này Python logging before you run logging.basicConfig?

4

sao chép trực tiếp từ câu trả lời đầu trong câu hỏi @ liên kết câu trả lời StevenBohrer để (điều này đã làm các trick cho tôi, thay thế dòng cuối cùng với cấu hình của riêng tôi):

root = logging.getLogger() 
if root.handlers: 
    for handler in root.handlers: 
     root.removeHandler(handler) 
logging.basicConfig(format='%(asctime)s %(message)s',level=logging.DEBUG) 
+0

hoạt động như một sự quyến rũ –

0

Về cơ bản, bản vá khỉ đăng nhập AWS cần phải được xử lý theo cách rất đặc biệt, trong đó:

  1. Mức nhật ký được đặt từ cấp TOP của tập lệnh (ví dụ: ., Vào thời điểm nhập khẩu)
  2. Báo cáo log bạn quan tâm được gọi từ bên trong hàm lambda

Kể từ khi nó thường được coi là hình thức tốt không để chạy mã nhị phân bằng Python mô-đun nhập khẩu, bạn thường sẽ có thể để cơ cấu lại mã của bạn để việc nâng hạng nặng chỉ xảy ra bên trong hàm lambda.

Các vấn đề liên quan