예외에 대한 오류 로깅을 관리하는 가장 좋은 방법은 무엇입니까?

소개

웹 사이트 나 시스템에서 오류가 발생하면이를 기록하고 사용자에게 오류에 대한 참조 코드가 포함 된 예의 메시지를 표시하는 것이 좋습니다.

그리고 시스템이 많으면이 정보가 점으로 표시되는 것을 원하지 않습니다. 단일화 된 중앙 위치를 갖는 것이 좋습니다.

가장 간단한 수준에서 필요한 것은 증분 ID와 오류 세부 정보의 직렬화 된 덤프입니다. (그리고 아마도 "중앙 장소"는 이메일받은 편지함 일 것입니다.)

스펙트럼의 다른 쪽 끝은 아마도 완전히 정규화 된 데이터베이스 일 것입니다. 또한 버튼을 누르고 하루에 오류 그래프를 보거나 시스템 X에서 가장 일반적인 오류 유형을 식별 할 수 있습니다. 서버 A에 더 많은 데이터베이스가 있는지 여부 서버 B보다 연결 오류 등이 있습니다.

여기서 말하는 것은 Jira, Trac 등의 "인간 기반"문제 추적이 아닌 원격 시스템에 의한 코드 수준 오류 / 예외를 로깅하는 것입니다.

질문

이 유형의 시스템을 사용한 개발자, 특히 다음과 관련하여 개발자의 생각을 찾고 있습니다.

• 없이는 할 수 없었던 필수 기능은 무엇입니까?
• 시간을 절약 할 수있는 기능을 갖추면 좋은 점은 무엇입니까?
• 어떤 기능이 좋은 생각처럼 보이지만 실제로는 유용하지 않습니까?

예를 들어, 오류가 여러 번 발생하는 것을 식별하는 "중복 표시"기능이 매우 중요하다고 말하고 싶습니다 ( '중요하지 않은'세부 사항에 대한 걱정없이).
"[이 오류에 대해 [Jira / etc]에 문제를 만드는" "버튼은 시간 절약에 도움이됩니다.

다시 말하지만, 내가 겪고있는 것은 그러한 시스템을 사용하는 사람들의 실용적인 경험이며 , 기능이 왜 끔찍하고 끔찍한 지에 따라 백업하는 것이 좋습니다 .
(어쨌든 이론을 쓰려고한다면 최소한 답변을 표시하십시오.)

Microsoft Enterprise library를 사용하여 클라이언트 오류가 기록 된 프로젝트에 있었습니다. 메일 박스로 보내는 모든 예외. 메일 제목에 중복 메시지를 피하기 위해 직렬화 된 오류의 해시 코드를 추가했습니다. 물론 직렬화 된 메시지를 데이터베이스 등에 저장할 수 있습니다.

Microsoft Enterprise 라이브러리 및 Log4Net 을 확인하는 것이 좋습니다 .

Log4Net의 일부 기능

• 여러 프레임 워크 지원
• 여러 로깅 대상으로 출력
• 계층 적 로깅 아키텍처
• XML 구성
• 동적 구성
• 로깅 컨텍스트
• 입증 된 아키텍처
• 모듈 식 및 확장 가능한 설계 • 유연성을 갖춘 고성능

데이터베이스 응용 프로그램의 경우 <TABLE>:<PrimaryKeyID>예외가 발생한 범위와 관련된 데이터베이스의 레코드를 추적 할 수 있는 일종의 ID (예 :)가 있습니다.

Oracle 및 PL / SQL을 사용하여 예외 처리기에서 응용 프로그램 내 데이터베이스 테이블에 ID를 기록했습니다.

Amir Rezaei가 지적한 것처럼 대부분의 설명 (즉, 로깅 특정 부분)은 엔터프라이즈 라이브러리에서 구현됩니다. 다른 모든 것들은 더 많은 분석 부분 인 것 같습니다 (즉, 나중에 로그로 무엇을 해야할지).

필자의 경우 작은 응용 프로그램과 SQL 스크립트를 만들어 일부 작업을 쉽게했습니다. 내가 정말 좋아했던 것들 중 일부는 다음과 같습니다.

• 동일한 오류를 함께 그룹화합니다 (예 : 100 명의 사용자가 동시에 같은 버그를 경험 한 횟수는 1 건의 버그 보고서이며 발생 횟수를 기록합니다)
• 사례 추적기에서 티켓 자동 정리 ( '버튼 클릭시'로 만들지 않았지만 항상 원했던 경우)
• 소프트웨어 사용자의 사용자 이름 (대부분의 로거에서 사용 가능한 시스템뿐만 아니라) 어떤 경우에는 자동화 된 사용자 계정으로 인해 문제가 발생하는 반면 다른 경우에는 특정 사용자로 인해 문제가 발생했습니다. "마이크가 어떤 일을하는 것을 지켜봐야합니다. 그는 계속해서 특정한 오류를 일으 킵니다."
• "사용자 작업"-사용자가 수행 한대로 모든 실행 가능한 클릭 / 버튼 누름을 추적하고 오류 로그를 추적하는 전역 스택이 있습니다. 오류를 재현하는 것은 종종 해당 추적을 수행하고 사용자와 동일한 단계를 수행하는 경우였습니다 (추적을 구문 분석하고 단계를 자동으로 수행하지만 결코 수행하지 않은 CodedUI 테스트 생성기를 구축하고 싶었습니다)

때때로 로그 정보가 너무 커서 디스크에 저장하기에는 너무 방대합니다. 내가 본 한 가지 접근법은 로깅 항목을 firehose (예 : perl)에 다음과 같이 작성하는 것입니다.

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

그런 다음 분석가는보고 싶은 내용을 파악할 수 있습니다.

우리 응용 프로그램의 오류 모니터링에서 배운 것들이 있습니다.

• 롤링 로그 파일을 테일링 할 수있는 경우 (일반적으로 응용 프로그램에 로그인 할 때 log4net / log4j를 사용 하고 로그를 따르기 위해 BareTail 을 사용함 )는 시스템의 현재 상태를 확인할 수있는 데 정말 유용합니다
• 문제가 발생한시기와 문제가 발생하는 비율을 확인하려면 보고서를 실행할 수있는 타임 스탬프가있는 데이터베이스에 문제가있는 것이 좋습니다.
• 전자 메일 / SMS / 음성 경고를 보내는 기능은 시스템을 최신 상태로 유지하는 데 매우 유용하지만 경고하는 오류 유형을 쉽게 사용자 지정할 수 있어야합니다. 하루에 800 개의 오류 이메일을 수신하는 경우 "아, 데이터 센터가 작동하지 않습니다"라는 이메일을 놓치게됩니다.

log4net은 여러 위치에 쉽게 로그인하고 로깅 구성을 쉽게 변경할 수 있기 때문에 훌륭한 결과를 얻었습니다.

elmah는 ASP.NET 앱용 오픈 소스 오류 로깅 시스템이며 기존 시스템 (NuGet http://nuget.codeplex.com/ 사용 )에 빠르고 쉽게 추가 할 수 있습니다. 다양한 백엔드 및 알림 기능을 지원합니다.

웹 사이트로 실행될 때 데스크톱 앱에 추가 한 사람은 알지 못하지만 웹 사이트를 통해 서비스로 실행하고 예외를 게시하지 못하게하는 것은 없습니다.

http://code.google.com/p/elmah/

ELMAH (Error Logging Modules and Handlers)는 완전히 플러그 가능한 응용 프로그램 전체의 오류 로깅 기능입니다. 다시 컴파일하거나 다시 배포 할 필요없이 실행중인 ASP.NET 웹 응용 프로그램 또는 컴퓨터의 모든 ASP.NET 웹 응용 프로그램에 동적으로 추가 할 수 있습니다 .

ELMAH가 실행중인 웹 응용 프로그램에 삭제되고 적절하게 구성되면 코드 한 줄을 변경하지 않고도 다음 기능을 사용할 수 있습니다.

• 처리되지 않은 거의 모든 예외 기록
• 레코딩 된 예외의 전체 로그를 원격으로 볼 수있는 웹 페이지입니다.
• 컬러 스택 추적을 포함하여 로그 된 예외 하나의 전체 세부 사항을 원격으로 볼 수있는 웹 페이지.
• 대부분의 경우, 모드가 꺼져 있어도 ASP.NET이 특정 예외에 대해 생성 한 원래의 노란색 죽음 화면을 검토 할 수 있습니다 customErrors.
• 각 오류 발생시 이메일 알림.
• 로그에서 마지막 15 개 오류의 RSS 피드 ...