Lỗi tổng hợp Sentry như thế nào?

Question

Tôi đang sử dụng Sentry (trong một dự án django), và tôi muốn biết làm thế nào tôi có thể nhận được các lỗi để tổng hợp đúng cách. Tôi đang ghi nhật ký hành động người dùng nhất định dưới dạng lỗi, vì vậy không có ngoại lệ hệ thống cơ bản và đang sử dụng thuộc tính culprit để đặt tên lỗi thân thiện. Thư được tạo mẫu và chứa thông báo chung ("Người dùng 'x' không thể thực hiện hành động vì 'y'"), nhưng không bao giờ giống nhau (người dùng khác nhau, các điều kiện khác nhau).

Sentry sử dụng rõ ràng một số thuộc tính trong mui xe để xác định xem có tổng hợp lỗi như ngoại lệ không, nhưng mặc dù đã xem xét mã, tôi không thể tìm ra cách.

Có ai có thể cắt ngắn việc phải đào sâu thêm vào mã và cho tôi biết những thuộc tính nào cần thiết để quản lý tập hợp như tôi muốn không?

[UPDATE 1: Sự kiện nhóm]

dòng này xuất hiện trong sentry.models.Group:

class Group(MessageBase): 
    """ 
    Aggregated message which summarizes a set of Events. 
    """ 
    ... 

    class Meta: 
     unique_together = (('project', 'logger', 'culprit', 'checksum'),) 
    ... 

nào có ý nghĩa - dự án, logger và thủ phạm tôi đang thiết vào lúc này - vấn đề là checksum. Tôi sẽ điều tra thêm, tuy nhiên 'checksum' cho thấy rằng nhị phân tương đương, mà không bao giờ sẽ làm việc - nó phải có thể nhóm các trường hợp của cùng một ngoại lệ, với các thuộc tính differenct?

[UPDATE 2: checksums kiện]

Các checksum sự kiện xuất phát từ phương pháp sentry.manager.get_checksum_from_event:

def get_checksum_from_event(event): 
    for interface in event.interfaces.itervalues(): 
     result = interface.get_hash() 
     if result: 
      hash = hashlib.md5() 
      for r in result: 
       hash.update(to_string(r)) 
      return hash.hexdigest() 
    return hashlib.md5(to_string(event.message)).hexdigest() 

Điểm dừng tiếp theo - nơi làm sự kiện interfaces đến từ đâu?

[UPDATE 3: sự kiện giao diện]

Tôi đã làm việc ra rằng interfaces tham khảo các cơ chế tiêu chuẩn để mô tả dữ liệu được truyền vào các sự kiện lính gác, và rằng tôi đang sử dụng các tiêu chuẩn sentry.interfaces.Message và sentry.interfaces.User giao diện.

Cả hai dữ liệu này sẽ chứa dữ liệu khác nhau tùy thuộc vào trường hợp ngoại lệ - và do đó tổng kiểm tra sẽ không bao giờ khớp. Có cách nào để tôi có thể loại trừ chúng khỏi tính toán kiểm tra không? (Hoặc ít nhất giá trị giao diện User, vì điều đó có thể khác nhau - giá trị giao diện Message tôi có thể chuẩn hóa.)

[UPDATE 4: Giải pháp]

Dưới đây là hai get_hash chức năng cho Message và User giao diện tương ứng:

# sentry.interfaces.Message 
def get_hash(self): 
    return [self.message] 

# sentry.interfaces.User 
def get_hash(self): 
    return [] 

Nhìn vào hai, chỉ có giao diện Message.get_hash sẽ trả về một giá trị được chọn của các phương pháp get_checksum_for_event, và vì vậy đây là một trong đó sẽ được trả lại (băm, vv) Th hiệu ứng ròng của điều này là checksum được đánh giá trên tin nhắn một mình - mà trong lý thuyết có nghĩa là tôi có thể chuẩn hóa thông điệp và giữ cho định nghĩa người dùng duy nhất.

Tôi đã trả lời câu hỏi của riêng mình ở đây, nhưng hy vọng điều tra của tôi sẽ được sử dụng cho những người khác có cùng vấn đề.(Là một sang một bên, tôi cũng đã gửi một yêu cầu kéo đối với tài liệu Sentry như một phần của điều này ;-))

(Lưu ý cho bất kỳ ai sử dụng/mở rộng Sentry với giao diện tùy chỉnh - nếu bạn muốn tránh giao diện của mình sử dụng để nhóm các ngoại lệ, trả về một danh sách trống.)

Answer 1

Xem bản cập nhật cuối cùng của tôi trong chính câu hỏi. Các sự kiện được tổng hợp dựa trên sự kết hợp các thuộc tính 'project', 'logger', 'culprit' và 'checksum'. Ba cái đầu tiên trong số này tương đối dễ kiểm soát - thứ tư, 'checksum' là một hàm của kiểu dữ liệu được gửi như một phần của sự kiện. Sentry sử dụng khái niệm 'giao diện' để kiểm soát cấu trúc của dữ liệu được truyền vào, và mỗi giao diện đi kèm với việc thực hiện get_hash, được sử dụng để trả về giá trị băm cho dữ liệu được truyền. Sentry đi kèm với một số các giao diện chuẩn ('Thư', 'Người dùng', 'HTTP', 'Stacktrace', 'Truy vấn', 'Ngoại lệ') và mỗi giao diện này có cách thực hiện riêng của chúng là get_hash. Mặc định (được thừa hưởng từ lớp cơ sở Giao diện) là một danh sách trống, danh sách này sẽ không ảnh hưởng đến tổng kiểm tra.

Trong trường hợp không có bất kỳ giao diện hợp lệ nào, bản thân thông báo sự kiện được băm và trả về làm tổng kiểm tra, có nghĩa là thông báo sẽ cần phải là duy nhất cho sự kiện được nhóm lại.

Answer 2

Tôi gặp sự cố thường gặp với Ngoại lệ. Hiện tại hệ thống của chúng tôi chỉ ghi lại ngoại lệ và tôi đã nhầm lẫn lý do tại sao một số trong số này được hợp nhất thành một lỗi duy nhất, một số khác thì không. Với thông tin của bạn ở trên, tôi đã loại bỏ các phương thức "get_hash" và cố gắng tìm ra sự khác biệt "nâng cao" lỗi của tôi. Những gì tôi phát hiện ra là tất cả các lỗi nhóm đều đến từ một kiểu ngoại lệ tự viết có giá trị Exception.message rỗng.

get_hash đầu ra:

[<class 'StorageException'>, StorageException()] 

và nhiều sai sót xuất phát từ một lớp ngoại lệ mà có một giá trị thông điệp đầy (jinja mẫu động cơ)

[<class 'jinja2.exceptions.UndefinedError'>, UndefinedError('dict object has no attribute LISTza_*XYZ*',)] 

thông điệp ngoại lệ khác nhau kích hoạt báo cáo khác nhau, trong tôi trường hợp hợp nhất được gây ra do thiếu giá trị Exception.message.

Thực hiện:

class StorageException(Exception): 

def __init__(self, value): 
    Exception.__init__(self) 
    self.value = value