.Net Log의 여러 로그 관리 방법은
애플리케이션의 필수적인 부분입니다. 이는 애플리케이션의 실행 상태를 기록할 수 있을 뿐만 아니라 애플리케이션의 업데이트 및 수정을 용이하게 하기 위해 일부 BUG도 기록할 수 있습니다.
.Net에서 로그를 관리하는 방법에는 여러 가지가 있습니다.
1. 데이터베이스 로그.
2. 텍스트 로그.
3. 시스템 이벤트 로그.
우선, 데이터베이스 로그에 사용하는 것이 간단하고 편리합니다. 여기에서는 데이터 관련 프로젝트를 작성하는 사람이라면 누구나 데이터를 사용하여 로그를 기록할 것이라고 믿습니다. 그러나 유일한 단점은 먼저 데이터베이스 링크가 올바른지 확인해야 한다는 것입니다.
그러나 이 보장은 불가피한 것이 아니므로 여기서는 다른 두 가지 상황인 텍스트 로그와 시스템 이벤트 로그에 대해 설명하겠습니다.
텍스트 로그:
사용법도 간단하고 보기도 쉽습니다. 단점은 로그를 대량으로 만드는 것이 불편하고, 로그 내용을 보고 분석하는 것이 불편하다는 점이다. 그러나 데이터베이스 로깅이 적합하지 않은 일부 장소에서는 여전히 사용할 수 있습니다. 예를 들어 일부 테스트 메시지의 출력, 일부 독립 구성 요소의 소량 로그 등이 있습니다.
일반적인 상황에서는 관리를 용이하게 하기 위해 로그 파일을 일 단위로 분류합니다. 이런 방식으로 파일을 쉽게 관리할 수 있습니다. 예를 들어, 이 로그가 파일 이름으로 언제인지 알 수 있으며, 데이터베이스와 유사한 쿼리를 간단히 만들 수 있으며 관리도 편리합니다. 결국 텍스트는 시스템에 있어서 매우 단순합니다.
.Net에는 듣기 형식으로 Trace 및 Debug에 텍스트를 추가할 수 있는 진단 클래스가 있습니다. 이러한 방식으로 Trace 및 Degug에 대한 모든 출력이 파일에 기록됩니다. 이것은 아주 좋은 방법입니다.
System.Diagnostics 사용;
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out))
또는:
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
차이점은 다음과 같습니다. Trace는 Release에서 사용할 수 있는 반면 Debug는 Debug에서만 사용할 수 있습니다.
모든 텍스트 로그 중에서 위의 방법이 가장 유용하다고 생각합니다. 다른 로그 관리 클래스만 만들면 됩니다.
물론, 24시간 후에는 모니터를 업데이트해야 한다는 점에도 유의해야 합니다. 현재 모니터를 정리하고 새 모니터를 추가해야 합니다. 또한 간단합니다.
또 다른 방법은 관리를 위해 텍스트를 직접 작성하는 것입니다. 이 방법은 조금 더 번거롭기는 하지만 어렵지는 않습니다.
하지만 텍스트 로그는 많은 로깅 작업을 하기에는 불편할 뿐만 아니라 프로세스 충돌이라는 치명적인 문제도 안고 있습니다!
텍스트 로깅은 작성 중인 텍스트 파일을 잠그기 때문에 파일에 쓰려는 다른 프로그램에 오류가 발생합니다. 일반적인 상황에서는 실행 중인 프로그램의 복사본이 하나만 있고 로그가 전역 정적 개체로 처리되면 큰 문제가 없습니다. 그러나 파일을 열 수 없기 때문에 프로그램의 두 번째 복사본이 시작되지 않습니다.
이는 해결할 수 없는 문제가 아니며 프로그램 사본이 있는지 확인하십시오. 보장되지 않으면 조금 복잡하므로 여기서는 더 이상 논의하지 않겠습니다. 다음에 기회가 되면 이 문제에 대해 논의하겠습니다.
위의 문제에 대해서는 일시적으로 텍스트 로그를 버리고 시스템 이벤트 로그를 활용하여 처리하고자 합니다.
시스템 이벤트 로그:
.net 아래에는 시스템의 이벤트 로그와 직접 연결된 EventLog 클래스가 있습니다.
간단한 것:
EventLog.WriteEntry("LogSource","테스트 로그입니다.");
시스템에 이벤트를 쓸 수 있습니다.
그러나 잘 사용하는 것은 다소 까다로울 수 있습니다. 먼저 위의 방법은 시스템의 응용 프로그램 아래에 이벤트 로그를 작성하며 기본값은 정보 유형입니다. 이는 관리에 도움이 되지 않습니다. 관리 도구에서 로그를 찾아보면, 직접 작성한 작은 로그는 찾아보기가 불가능합니다.
그러나 .Net은 로그를 더 잘 관리할 수 있는 여러 가지 방법을 제공합니다.
1. 새로운 LogSource를 추가합니다.
로그소스란 무엇입니까? 실제로 간단히 말하면 로그의 분류 표시입니다. 예를 들어 LogSource가 지정된 내용인 로그를 한 번에 검색할 수 있습니다. 이런 방식으로 소스 이름만 기억하면 로그를 읽고 분류할 수 있습니다.
기본적으로 EventLog의 정적 기능을 사용하여 직접 로그를 작성할 때는 LogSource를 지정해야 하며, LogSource가 없으면 자동으로 Application 아래에 생성되므로 LogSource를 만드는 것은 그만큼 간단합니다.
2. 새로운 로그를 추가하세요.
로그란 무엇입니까? 여기서 로그는 시스템 이벤트 로그의 대규모 로그 분류를 의미합니다. 일반적으로 시스템에는 애플리케이션, 시스템, 서비스의 세 가지 로그가 있으며 각각 다른 소스를 가지고 있어 로그 시스템을 구성합니다.
.NET에서는 로그를 생성하는 방법을 제공하지 않으므로 로그를 독립적으로 생성할 수 없으며 CreateEventSource(string, string) 함수만 사용할 수 있습니다.
소스를 생성하려면 다음과 같이 하십시오: CreateEventSource("MySource", "MyLog");
로그 관리자에 추가 MyLog 클래스가 표시되고 다음과 같이 로그를 작성합니다.
EventLog.WriteEntry("MySource","테스트 로그입니다.");
마이로그 카테고리에 기록을 남길 수 있어, 나만의 로그를 잘 관리할 수 있습니다.
설명해야 할 것은 다음과 같습니다.
소스가 이미 존재하는 경우 생성이 실패합니다. 참고: 소스의 이름이 이미 존재하는 한 소스의 로그에 관계없이 생성이 실패합니다. 예: 애플리케이션에 "Source1"이라는 로그가 있으면 다른 로그에 "Source1"이라는 로그를 생성할 수 없습니다. 또한, 프로그램을 사용하여 생성한 로그는 로그 관리자에서 삭제할 수 없습니다. (메시지는 삭제할 수 있지만 로그 카테고리는 삭제할 수 없습니다.) 방법은 여전히 프로그램을 사용하여 삭제하거나 레지스트리에서 삭제할 수 있다는 것입니다. 해당 위치: [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlog]
레지스트리를 살펴보면 아마도 뭔가를 이해할 수 있을 것입니다.
마지막 단계는 로그 인스턴스 개체를 사용하여 로그를 작성하는 것입니다. 로그 이름과 소스 이름을 지정하여 로그를 작성할 수 있지만 로그와 소스가 일치해야 합니다. 그렇지 않으면 오류가 발생합니다. 이는 정적 메서드를 사용하여 직접 로깅하는 것보다 조금 더 복잡하지만 더 자유롭게 사용할 수 있습니다.
시스템 이벤트 로그의 단점은 로그가 3개월 동안만 저장되고 관리가 어렵다는 점입니다. 서버를 직접 관리하거나 로컬에서 실행할 수 있으면 더 좋을 것입니다. 그렇지 않으면 로그를 직접 관리하기 위해 일부 코드를 작성해야 합니다. 물론 일부 중요한 로그를 다른 파일로 내보낼 수도 있습니다.
그 이점은 많습니다:
1. 데이터베이스에 연결할 필요가 없으며 효율성이 높아지고 데이터베이스 액세스 실패 문제가 없습니다.
2. 프로세스 충돌이 발생하지 않습니다. 어떤 애플리케이션이든 로그를 작성할 수 있습니다.
3. 전역적으로 사용 가능하며 로그는 어디에 있든 직접 작성할 수 있고 읽을 수 있습니다. 따라서 메시징 커뮤니케이션 플랫폼이라고 볼 수 있습니다. (물론 뇌에 문제가 있는 사람만이 할 수도 있습니다.) 그러나 설명하고 싶은 것은 프로세스 A가 작성한 로그를 프로세스 B가 직접 읽을 수 있다는 것입니다.
좋아요, 이번에는 로그에 관한 모든 것입니다.
http://www.cnblogs.com/WuCountry/archive/2006/08/22/483090.html