문제

내가 일하는 회사에서는 ASP.NET 응용 프로그램에서 오류를 처리하기 위해 오류 로깅 클래스를 만들었습니다. 서버 (NLOG, LOG4NET 등)에 추가 소프트웨어를 설치할 수 없기 때문에 사용자 정의 클래스입니다.

나는 현재 두 개의 프로젝트에서 그것을 사용하고 있으며 좋은 결과를 보았습니다. 지금은 페이지와 응용 프로그램 오류를 일으키는 오류를 갇히고 있습니다. 오류 메시지와 모든 내부 예외를 보내고 저장합니다.

내가 지금 가지고있는 문제는, 나는 어떻게 재생산 해야하는지 잘 모르는 오류를 받고 있다는 것입니다. 내 사용자의 오류 보고서를 듣지 못했습니다. 나는 그들이 무엇을하고 있는지 또는 그들이 이것을 오류로보고 있는지 확실하지 않습니다.

각 페이지에서 이벤트 로그를 작성하거나 추가 정보를 원하는 이벤트 로그를 작성하려고 생각합니다. 페이지의 세션 변수로 유지하고 이벤트를 작성합니다 (함수의 시작/끝, 변수 변경 등). 그런 다음 오류 메시지와 함께 전송을하도록 오류가 호출 된 경우에만 진행되는 일에 대한 더 나은 그림을 제공하는지 확인하십시오. 이런 식으로 수행하면 모든 사용자가 응용 프로그램에 액세스 할 때 수많은 이벤트 로그를 제공하지 않기를 바랍니다. 한 사용자와 오류가 발생하기 직전에 진행되기를 원합니다.

내가 방법으로 감시해야 할 함정을 알고 있습니까?

찾아야 할 것에 대한 조언이 있습니까?

업데이트:

@Saret : 나는 당신이 그 응답을 가지고 어디에서 왔는지 이해하고 동의합니다. 나는이 회사를 처음 접했지만 여전히 그들이 어떻게하는지 배워야합니다. 과거에는 동료들과 대화를 나누었습니다.이 제품을 보유 하거나이 오픈 소스 프로젝트를 사용하는 것이 얼마나 좋을지 문제는 안전한 시스템을 연구하고 이러한 것들을 얻기 위해 승인을 얻는 데 많은 시간이 걸리고, 상단 덮개 및 모든 빨간 테이프를 다루는 데 승인을 얻는다. 나는 좋은 오류 로깅 시스템을 갖추고 있다고 생각하기 때문에 상황을 더 살펴볼 것입니다. 현재 아무것도 사용중인 것이 없습니다.

@Jim Blizard : 나는 돌아와서 오류를 일으킨 상황에 무엇이 중요한지 알아 내기 위해 모든 곳을 로깅/저장하는 것을 피하고 싶었습니다. 나는 Roberto Barros가 링크 한 Artical에서 이야기하는 정보의 과부하에 빠지고 싶지 않았습니다. 내 현재 사고 방법은 각 페이지에 문자열을 메모리에 유지하는 것입니다. 오류가 발생하면 페이지 _error 이벤트 페이지에서 해당 문자열을 잡고 기록 된 예외에 첨부하십시오. 그렇게하면 발생한 오류/예외 만 기록하고 해당 오류로 이벤트 로그를 저장하고 있습니다. 아무 일도 일어나지 않으면 생성 된 로그는 다시는 볼 수없는 비트 버킷에 떨어집니다.

@Roberto Barros : 그 링크에 감사드립니다. 어딘가에 읽은 것을 기억하지만 저장하는 것을 잊었습니다.

도움이 되었습니까?

해결책

이것은 당신이 찾고있는 정확한 답이 아닐 수도 있지만, 이러한 모든 주요 문제를 처리하는 강력한 도구 (언급)가있을 때 자신만의 오류 로깅 메커니즘을 개발하는 이유는 무엇입니까?

추가 소프트웨어를 설치할 수는 없지만 사용자 정의 코드와 같은 클래스 만 로깅하지 않습니까? 근본적인 차이는 어디에 있습니까? 로깅 프레임 워크 구현에 대해 걱정하는 데 소요되는 시간은 괜찮은 로깅 솔루션을위한 비즈니스 사례를 옹호하고 만드는 데 더 잘 소비 될 수 있습니다.

다른 팁

나는 한때 순전히 내 자신의 코드 나 (끔찍한) COM 객체가 아닌 것을 설치하지 못하는 대행사를 위해 일했습니다. 이 유형의 제한이있는 경우 Log4Net 소스를 잡고 프로젝트에 포함시킬 수 있는지 확인하십시오.

로깅과 관련하여 현재 LOG4NET보다 더 좋은 것은 없습니다.

ASP.NET 응용 프로그램에서 로깅 오류 (및 로그 오류 만)에 대한 다음과 같은 접근 방식을 개인적으로 수행했습니다.

  • 사용 protected void Application_Error(object sender, EventArgs e) { Server.Transfer("~/Support/ServerErrorSupport.aspx", true); } (나는한다 Server.Transfer 모든 게시물 데이터를 보존하려면)

  • 이 오류에 대해 고유 한 오류 ID를 생성합니다 (따라서 동일한 오류에 대한 후속 반복을 그룹화 할 수 있음). ID는 파일, 메소드, linenr 및 error.message로 구성된 연결된 문자열에서 계산 된 해시입니다. StackTrace의 Regex를 통해 파일, 메소드 및 Linenr 값을 얻습니다.

  • 다음 모든 데이터를 XML 구조에 기록합니다 (데이터 유형에 따라 값을 다르게 저장합니다.

    1. machineName : application.server.machineName
    2. PhysicalRoot : application.server.mappath ( "~/")
    3. requestUrl : application.request.url.toString ()
    4. ApplicationSettings : WebConfigurationManager.AppSettings
    5. ConnectionSettings : webConfigurationManager.connectionStrings
    6. QueryString : application.request.querystring
    7. formpost : application.request.form
    8. 세션 : application.session
    9. httpheaders : application.request.headers
  • XML 구조를 오류 ID와 타임 스탬프를 포함하는 로컬 파일로 저장하십시오. 나는이 접근법을 선택했다.

    • 나는 관계 (XML-File)를 내 자신에게 우편으로 보내 드릴 수 있습니다 (테스트/디버깅 중에 매우 쉽게).
    • 생산 중에 로컬 또는 데이터베이스에 보관하십시오
    • 파일은 단지 (덤프로 HD) 저장이므로 오류 보고서 (서버 연결, DB 문제 등)를 작성하는 동안 잘못 될 수 없습니다. 쓰기 권한이 있는지 확인하십시오.
    • 또한 ServerErrorsupport.aspx 페이지에서 XML 파일을 저장 한 후 사용자는 추가 정보를 포함하고 이메일을 추가하여 버그와 관련하여 진행 상황을 계속 업데이트 할 수있는 옵션을 얻습니다. 이것은 XML 문서에 추가됩니다.
    • XSLT 파일을 사용하여 NICE 오류 보고서에서 오류 데이터 (XML)를 포맷합니다.

오류의 경우, 나는 많은 로그인을 좋아하는 팬입니다. 일이 잘못되면 정보는 매우 가치가 있습니다. 관련 이벤트를 함께 그룹화하기 위해 세션 식별자와 함께 전체 로그를 한 위치 (텍스트 파일 또는 데이터베이스 테이블)로 유지합니다.

내가 로그인하고 싶은 것은 다음과 같습니다.

  • 오류/디버그 레벨 (정보, 디버그, 문제, 충돌 등 ...)
  • 시각
  • 설명 텍스트 (보통 한 줄)
  • 스택 추적 (가능한 경우)
  • 데이터 (사용자, 세션, 가변 값 등 ...)

가장 간단한 방법은 텍스트 파일에 쓰는 것이지만 데이터베이스에 넣는 것이 좋을 수 있습니다. Windows 이벤트 로그를 사용할 수도 있습니다. 조심해야 할 것들. 흠 ... 로그를 주기적으로 정리해야합니다.

재미있는 스토리 : 한 번은 데이터베이스에 로그인 한 오류 로거가 있었지만 데이터베이스 자격 증명이 잘못되었으며 오류가 발생하여 로그인되었습니다. 재귀 (IIRC)에서 스택 오버 플로우를 얻었습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top