.net

최신 정보: System.Diagnostics에 대한 확장으로 원하는 누락 된 리스너를 제공하려면 CodePlex의 Essential.Diagnostics ( http://essentialdiagnostics.codeplex.com/ )를 참조하십시오

프레임 워크

Q : 어떤 프레임 워크를 사용하십니까?

A : .NET 2.0에 내장 된 System.Diagnostics.TraceSource

응용 프로그램을위한 강력하고 유연한 고성능 로깅을 제공하지만 많은 개발자는 해당 기능을 인식하지 못하고 완전히 활용하지 못합니다.

추가 기능이 유용하거나 기능이 존재하지만 문서화가 잘되지 않은 영역이 있지만 이것이 전체 로깅 프레임 워크 (확장 가능하도록 설계됨)를 버리고 일부 대체 대안과 같이 완전히 대체해야한다는 의미는 아닙니다. (NLog, log4net, Common.Logging 및 심지어 EntLib 로깅).

로깅 문을 응용 프로그램에 추가하고 휠을 다시 발명하는 방식을 변경하는 대신 필요한 곳에서 System.Diagnostics 프레임 워크를 확장했습니다.

EntLib조차도 다른 프레임 워크는 Not Invented Here Syndrome으로 고통 받고 있으며 System.Diagnostics (예 : 로그 문 작성 방법)에서 이미 완벽하게 작동하는 기본 사항을 다시 발명하는 데 시간을 낭비했다고 생각합니다. 존재하는 몇 가지 틈새를 채우는 대신 요컨대, 사용하지 마십시오. 필요하지 않습니다.

알려지지 않은 기능 :

• 형식 문자열과 인수를 사용하는 TraceEvent 오버로드를 사용하면 Filter.ShouldTrace ()가 성공할 때까지 매개 변수가 별도의 참조로 유지되므로 성능에 도움이 될 수 있습니다. 이는 시스템에서 메시지가 실제로 기록 될 때까지 매개 변수 값에서 비싼 ToString () 호출을 의미하지 않습니다.
• Trace.CorrelationManager를 사용하면 동일한 논리 연산에 대한 로그 문을 상관시킬 수 있습니다 (아래 참조).
• VisualBasic.Logging.FileLogTraceListener는 로그 파일에 쓰기에 적합하며 파일 회전을 지원합니다. VisualBasic 네임 스페이스에서도 DLL을 포함시켜 C # (또는 다른 언어) 프로젝트에서 쉽게 사용할 수 있습니다.
• 여러 인수와 비어 있거나 널 형식 문자열로 TraceEvent를 호출하면 EventLogTraceListener를 사용할 때 현지화 된 메시지 자원을 사용하는 경우 인수가 EventLog.WriteEntry ()로 직접 전달됩니다.
• WCF의 Service Trace Viewer 도구는 WCF를 사용하지 않더라도 활동 상관 로그 파일의 그래프를 보는 데 유용합니다. 이를 통해 여러 스레드 / 활동이 관련된 복잡한 문제를 디버깅 할 수 있습니다.
• 모든 리스너를 지우거나 기본값을 제거하여 오버 헤드를 피하십시오. 그렇지 않으면 Default는 모든 것을 추적 시스템으로 전달하고 모든 ToString () 오버 헤드를 발생시킵니다.

확장하고자하는 영역 (필요한 경우) :

• 데이터베이스 추적 리스너
• 컬러 콘솔 트레이스 리스너
• MSMQ / 이메일 / WMI 추적 리스너 (필요한 경우)
• 동적 구성 변경을 위해 Trace.Refresh를 호출하도록 FileSystemWatcher를 구현하십시오.

다른 권장 사항 :

구조화 된 이벤트 ID를 사용하고 참조 목록을 유지하십시오 (예 : 열거 형으로 문서화).

시스템의 각 (중요한) 이벤트에 대해 고유 한 이벤트 ID를 갖는 것은 특정 문제를 연관시키고 찾는 데 매우 유용합니다. 이벤트 ID를 기록 / 사용하는 특정 코드를 쉽게 추적 할 수 있으며 일반적인 오류에 대한 지침을 쉽게 제공 할 수 있습니다 (예 : 오류 5178은 데이터베이스 연결 문자열이 잘못되었음을 의미합니다).

이벤트 ID는 특정 코드를 몰라도 범주별로 처리 할 수있는 일종의 구조 (이메일 및 HTTP에 사용 된 응답 코드 이론과 유사)를 따라야합니다.

예 : 첫 번째 숫자는 일반 클래스를 자세히 설명 할 수 있습니다. 1xxx는 ‘시작’작업에 사용할 수 있고, 2xxx는 정상적인 동작에 사용할 수 있으며, 3xxx는 활동 추적에 사용할 수 있으며, 4xxx는 경고에 대해, 5xxx는 오류에 대해, 8xxx는 ‘중지’작업에 대해서는, 9xxx는 치명적 오류에 사용됩니다. 기타

두 번째 숫자는 영역을 자세히 설명 할 수 있습니다 (예 : 데이터베이스 정보의 경우 21xx (데이터베이스 경고의 경우 41xx, 데이터베이스 오류의 경우 51xx), 계산 모드의 경우 22xx (계산 경고의 경우 42xx 등), 다른 모듈의 경우 23xx 등).

할당 된 구조화 된 이벤트 ID를 사용하여 필터에 사용할 수도 있습니다.

Q : 추적을 사용하는 경우 Trace.Correlation.StartLogicalOperation을 사용합니까?

A : Trace.CorrelationManager는 모든 종류의 멀티 스레드 환경에서 요일을 상관시키는 데 매우 유용합니다.

상관 시키려면 최소한 각 논리적 작업마다 ActivityId를 한 번 설정해야합니다.

그런 다음 시작 / 중지 및 LogicalOperationStack을 간단한 스택 기반 컨텍스트에 사용할 수 있습니다. 보다 복잡한 컨텍스트 (예 : 비동기 작업)의 경우 새 ActivityId에 TraceTransfer를 사용하여 (변경하기 전에) 상관 관계를 허용합니다.

서비스 추적 뷰어 도구는 WCF를 사용하지 않더라도 활동 그래프를 보는 데 유용 할 수 있습니다.

Q :이 코드를 수동으로 작성합니까, 아니면 형태 지향 프로그래밍을 사용하여 작성합니까? 코드 스 니펫을 공유 하시겠습니까?

A : (a) 생성시 컨텍스트를 설정하고 (b) 폐기시 컨텍스트를 재설정하는 범위 클래스 (예 : LogicalOperationScope)를 생성 할 수 있습니다.

이를 통해 다음과 같은 코드를 작성하여 자동 랩 조작을 수행 할 수 있습니다.

  using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
  {
    // .. do work here
  }

작성시 범위는 필요한 경우 먼저 ActivityId를 설정하고 StartLogicalOperation을 호출 한 다음 TraceEventType.Start 메시지를 로깅 할 수 있습니다. Dispose에서 Stop 메시지를 기록한 다음 StopLogicalOperation을 호출 할 수 있습니다.

Q : 미량 소스에 대해 세분화 된 형태를 제공합니까? 예를 들어 WPF TraceSources를 사용하면 다양한 수준에서 구성 할 수 있습니다.

A : 예. 시스템이 커질수록 여러 개의 추적 소스가 유용하고 중요합니다.

합리적 규모의 시스템에 대해 모든 경고 이상 또는 모든 정보 이상 메시지를 일관되게 기록하려고하지만 활동 추적 (시작, 중지 등) 및 상세 로깅의 양이 너무 많아집니다.

스위치를 하나만 켜거나 끄는 대신 한 번에 시스템의 한 섹션에 대해이 정보를 켤 수 있습니다.

이렇게하면 일반적으로 로깅 (모든 경고, 오류 등)에서 중요한 문제를 찾은 다음 원하는 섹션에서 “확대”하고 활동 추적 또는 디버그 수준으로 설정할 수 있습니다.

필요한 트레이스 소스의 수는 애플리케이션에 따라 다릅니다. 예를 들어 어셈블리 또는 애플리케이션의 주요 섹션 당 하나의 트레이스 소스가 필요할 수 있습니다.

더 세밀하게 조정 된 제어가 필요한 경우 개별 부울 스위치를 추가하여 원시 메시지 덤프와 같은 특정 대용량 추적을 설정 / 해제하십시오. 또는 WCF / WPF와 유사한 별도의 추적 소스를 사용할 수 있습니다.

Activity Tracing과 일반 (기타) 로깅에 대해 별도의 추적 소스를 고려할 수도 있는데, 원하는 방식으로 필터를 좀 더 쉽게 구성 할 수 있기 때문입니다.

다른 소스를 사용하더라도 메시지는 ActivityId를 통해 상관 될 수 있으므로 필요한만큼 사용하십시오.

청취자

Q : 어떤 로그 출력을 사용합니까?

이것은 작성중인 응용 프로그램 유형과 기록되는 내용에 따라 달라질 수 있습니다. 일반적으로 다른 것들이 다른 장소 (예 : 다중 출력)에갑니다.

일반적으로 출력을 세 그룹으로 분류합니다.

(1) 이벤트-Windows 이벤트 로그 (및 추적 파일)

예를 들어 서버 / 서비스를 작성하는 경우 Windows에서 가장 좋은 방법은 Windows 이벤트 로그를 사용하는 것입니다 (보고 할 UI가 없음).

이 경우 모든 치명적, 오류, 경고 및 (서비스 수준) 정보 이벤트는 Windows 이벤트 로그로 이동해야합니다. 정보 수준은 “서비스 시작”, “서비스 중지됨”, “Xyz에 연결됨”및 “일정이 시작됨”과 같이 이벤트 로그에 표시하려는 이러한 높은 수준의 이벤트 유형에 예약되어 있어야합니다. , “사용자 로그온”등

경우에 따라 추적 시스템을 통하지 않고 응용 프로그램의 내장 부분으로 이벤트 로그에 기록 할 수 있습니다 (예 : 이벤트 로그 항목을 직접 작성). 즉, 실수로 끌 수 없습니다. (여전히 추적 시스템에서 동일한 이벤트를 기록하여 상관시킬 수 있습니다.)

반대로 Windows GUI 응용 프로그램은 일반적으로 Windows GUI 응용 프로그램을 사용자에게보고하지만 Windows 이벤트 로그에도 기록 할 수 있습니다.

이벤트에는 관련 성능 카운터 (예 : 오류 수 / 초)가있을 수 있으며 이벤트 로그에 직접 기록, 성능 카운터, 추적 시스템에 기록 및 사용자에게보고하도록 조정하는 것이 중요 할 수 있습니다. 동시.

즉, 특정 시간에 사용자에게 오류 메시지가 표시되면 Windows 이벤트 로그에서 동일한 오류 메시지를 찾은 다음 추적 로그에서 동일한 타임 스탬프를 가진 동일한 이벤트를 다른 추적 세부 정보와 함께 찾을 수 있어야합니다.

(2) 활동-애플리케이션 로그 파일 또는 데이터베이스 테이블 (및 추적 파일)

이는 웹 페이지 제공, 주식 시장 거래 접수, 주문 접수, 계산 수행 등 시스템이 수행하는 정기적 인 활동입니다.

활동 추적 (시작, 중지 등)이 여기에서 유용합니다 (오른쪽 세분성).

또한 특정 응용 프로그램 로그 (감사 로그라고도 함)를 사용하는 것이 매우 일반적입니다. 일반적으로 이것은 데이터베이스 테이블 또는 응용 프로그램 로그 파일이며 구조화 된 데이터 (예 : 필드 집합)를 포함합니다.

응용 프로그램에 따라 여기가 약간 흐려질 수 있습니다. 각 요청을 웹 로그에 기록하는 웹 서버가 좋은 예입니다. 유사한 예는 각 작업이 응용 프로그램 별 세부 정보와 함께 기록되는 메시징 시스템 또는 계산 시스템 일 수 있습니다.

좋은 예는 주식 시장 거래 또는 판매 주문 시스템입니다. 이러한 시스템에서는 중요한 비즈니스 가치가 있으므로 이미 활동을 로깅하고 있지만 다른 작업과 연관시키는 원칙은 여전히 ​​중요합니다.

사용자 지정 응용 프로그램 로그뿐만 아니라 활동에는 종종 관련 트랜잭션 카운터 (예 : 초당 트랜잭션 수)가 있습니다.

일반적으로 성능 카운터를 늘리고 추적 시스템에 기록 할 때 서로 다른 시스템에서 활동 기록을 조정해야합니다. 즉, 응용 프로그램 로그에 기록합니다. 동시에 (또는 코드에서 서로 직접) 모두 수행하면 문제가 코드의 다른 시간 / 위치에서 발생하는 것보다 디버깅 문제가 더 쉽습니다.

(3) 디버그 추적-텍스트 파일 또는 XML 또는 데이터베이스 일 수 있습니다.

이것은 상세 레벨 이하의 정보입니다 (예 : 원시 데이터 덤프를 켜거나 끄는 사용자 정의 부울 스위치). 이것은 하위 활동 수준에서 시스템이 수행하는 작업에 대한 내장이나 세부 정보를 제공합니다.

이것은 응용 프로그램의 개별 섹션 (따라서 여러 소스)에 대해 켜거나 끌 수있는 수준입니다. 이 이벤트로 인해 Windows 이벤트 로그가 복잡 해지는 것을 원하지 않습니다. 때때로 데이터베이스가 사용되지만 특정 시간 후에 제거 된 로그 파일을 롤링 할 가능성이 높습니다.

이 정보와 응용 프로그램 로그 파일의 큰 차이점은 구조화되지 않았다는 것입니다. 응용 프로그램 로그에 To, From, Amount 등의 필드가있을 수 있지만 Verbose 디버그 추적은 프로그래머가 입력 한 모든 것 (예 : “값 X = {value}, Y = false”또는 ” 다시 시도하십시오 “

한 가지 중요한 방법은 응용 프로그램 로그 파일 또는 Windows 이벤트 로그에 넣은 내용이 동일한 세부 정보 (예 : 타임 스탬프)로 추적 시스템에 기록되도록하는 것입니다. 그러면 조사 할 때 다른 로그를 상관시킬 수 있습니다.

서비스 추적 뷰어와 같이 복잡한 상관 관계로 인해 특정 로그 뷰어를 사용하려는 경우 XML과 같은 적절한 형식을 사용해야합니다. 그렇지 않으면 간단한 텍스트 파일만으로도 충분합니다. 낮은 수준에서는 정보가 크게 구조화되어 있지 않으므로 배열 덤프, 스택 덤프 등을 찾을 수 있습니다. 더 높은 수준에서 더 구조화 된 로그와 다시 상관 관계가있을 수있는 경우 괜찮아

Q : 파일을 사용하는 경우 롤링 로그 또는 단일 파일 만 사용합니까? 사람들이 사용할 수있는 로그를 어떻게 만들 수 있습니까?

A : 파일의 경우 일반적으로 관리 효율성 관점에서 로그 파일을 롤링하려고합니다 (System.Diagnostics에서는 단순히 VisualBasic.Logging.FileLogTraceListener를 사용함).

다시 가용성은 시스템에 따라 다릅니다. 파일에 대해서만 이야기하는 경우 서버 / 서비스를 위해 필요한 경우 롤링 파일에 액세스 할 수 있습니다. Windows 이벤트 로그 또는 데이터베이스 응용 프로그램 로그에는 자체 액세스 메커니즘이 있습니다.

파일 시스템에 쉽게 액세스 할 수 없으면 데이터베이스에 대한 디버그 추적이 더 쉬울 수 있습니다. [즉, 데이터베이스 TraceListener 구현].

Windows GUI 응용 프로그램에서 본 흥미로운 솔루션 중 하나는 실행 중에 “플라이트 레코더”에 매우 자세한 추적 정보를 기록한 다음 문제가없는 경우 종료하면 파일을 삭제한다는 것입니다.

그러나 충돌이 발생하거나 문제가 발생하면 파일이 삭제되지 않은 것입니다. 오류가 발생하거나 다음에 파일을 실행할 때 파일을 확인한 후 압축 (예 : 7zip)하여 이메일로 보내거나 사용할 수있게하는 등의 조치를 취할 수 있습니다.

요즘 많은 시스템은 (예 : 개인 정보 보호 등의 이유로 사용자와 확인한 후) 중앙 서버에 자동으로 장애보고를 통합합니다.

보기

Q : 로그를보기 위해 어떤 도구를 사용합니까?

A : 다른 이유로 여러 개의 로그가있는 경우 여러 뷰어를 사용합니다.

Notepad / vi / Notepad ++ 또는 기타 텍스트 편집기는 일반 텍스트 로그의 기본입니다.

전송 작업과 같은 복잡한 작업이있는 경우 서비스 추적 뷰어와 같은 특수 도구를 사용하는 것이 분명합니다. 그러나 필요하지 않은 경우 텍스트 편집기가 더 쉽습니다.

일반적으로 높은 수준의 정보를 Windows 이벤트 로그에 기록 할 때 구조화 된 방식으로 개요를 신속하게 얻을 수있는 빠른 방법을 제공합니다 (예 : 오류 / 경고 아이콘 찾기). 최소한 로그가 시작점을 제공하지만 로그에 충분하지 않은 경우 텍스트 파일을 통한 헌팅 만 시작하면됩니다. (이 시점에서 로그가 전체를 조정했는지 확인하십시오).

일반적으로 Windows 이벤트 로그는 이러한 중요한 이벤트를 MOM 또는 OpenView와 같은 모니터링 도구에서 사용할 수 있도록합니다.

기타

데이터베이스에 로그인하면 정보를 쉽게 필터링하고 정렬 할 수 있습니다 (예 : 특정 활동 ID 확대). 텍스트 파일을 사용하면 Grep / PowerShell 또는 유사 항목을 사용하여 원하는 부분 GUID에서 필터링 할 수 있습니다.

MS Excel (또는 다른 스프레드 시트 프로그램). 다른 값이 다른 열에 들어가도록 올바른 구분 기호를 사용하여 정보를 가져올 수있는 경우 구조화 된 정보 또는 반 구조화 된 정보를 분석하는 데 유용 할 수 있습니다.

디버그 / 테스트에서 서비스를 실행할 때 일반적으로 간단하게 콘솔 응용 프로그램에서 서비스를 호스팅합니다. 컬러 콘솔 로거가 유용하다는 것을 알았습니다 (예 : 빨간색은 경고, 노란색은 경고 등). 사용자 정의 추적 리스너를 구현해야합니다.

프레임 워크에는 컬러 콘솔 로거 또는 데이터베이스 로거가 포함되어 있지 않으므로 지금 필요한 경우 작성해야합니다 (너무 어렵지는 않습니다).

여러 프레임 워크 (log4net, EntLib 등)가 바퀴를 다시 발명하고 기본 로깅, 필터링 및 텍스트 파일, Windows 이벤트 로그 및 XML 파일에 대한 로깅을 각각 자체적으로 다시 구현하는 데 시간을 낭비했다는 사실이 정말 귀찮습니다. 다른 방법 (로그 진술은 각각 다릅니다); 그런 다음 각각은 이미 존재하는 대부분의 데이터베이스 로거와 같은 자체 버전의 데이터베이스 로거를 구현했으며 필요한 것은 System.Diagnostics에 대한 추적 리스너가 몇 개 더 필요한 경우입니다. 중복 노력의 큰 낭비에 대해 이야기하십시오.

Q : ASP.NET 솔루션을 구축하는 경우 ASP.NET 상태 모니터링도 사용합니까? 상태 모니터 이벤트에 추적 출력을 포함합니까? Trace.axd는 어떻습니까?

필요에 따라 이러한 기능을 켜거나 끌 수 있습니다. Trace.axd는 서버가 특정 것에 응답하는 방법을 디버깅하는 데 매우 유용하지만 일반적으로 많이 사용되는 환경이나 장기 추적에는 유용하지 않습니다.

Q : 사용자 지정 성능 카운터는 어떻습니까?

전문적인 응용 프로그램, 특히 서버 / 서비스의 경우 성능 모니터 카운터와 Windows 이벤트 로그에 모두 기록되는 기능을 갖추기를 기대합니다. 이들은 Windows의 표준 도구이며 사용해야합니다.

사용하는 성능 카운터 및 이벤트 로그에 대한 설치 관리자를 포함해야합니다. 설치시 (관리자로 설치할 때) 작성해야합니다. 응용 프로그램이 정상적으로 실행되면 관리 권한이 없어야하므로 누락 된 로그를 만들 수 없습니다.

이것은 비 관리자로 개발하는 연습을하는 좋은 이유입니다 (서비스를 설치해야 할 때 별도의 관리자 계정이 있어야 함). 이벤트 로그에 쓰는 경우 .NET은 처음 기록 할 때 자동으로 누락 된 로그를 만듭니다. 관리자가 아닌 사람으로 개발하는 경우이를 조기에 포착하여 고객이 시스템을 설치 한 후 시스템 관리자가 실행되지 않아 사용할 수없는 경우를 피할 수 있습니다.

답변

    -클래스 호출 : com.foocorp.foopackage.FooClass : 9021
    SELECT * FROM foo;

Logger.Instance.Warn("Something to warn about");
Logger.Instance.Fatal("Something went bad!", new Exception());

try {
  var i = int.Parse("Hello World");
} catch(FormatException, ex) {
  Logger.Instance.Error(ex);
}

Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

if(Logger.DebugEnabled) Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);