ULS 로깅 팁(2부)

ULS 로깅 팁(2부)

ULS 로깅 팁 1부(https://blogs.msdn.com/b/sharepoint_ko/archive/2011/03/21/uls.aspx)에서는 사용자 지정 ULS 로깅 Area를 추가하는 몇 가지 코드를 소개하고, 프로젝트 내에서 이러한 코드를 사용하는 방법에 대해 설명했습니다. 이 코드를 사용해 본 결과, 다음과 같은 몇 가지 사항이 확인되었습니다.

1. 일부 코드는 최신 SDK에 적합하지 않습니다. 즉, SDK에는 필요하지 않다고 나와 있는 일부 코드 조각이 구현되었으며, 일부 코드의 경우에는 SDK의 예제와 약간 다른 방식으로 사용되었습니다. 이러한 코드의 경우에는 업데이트가 필요하며, 해당 작업은 별도로 진행할 예정입니다.

2. TraceSeverity를 Medium으로 설정해야 로깅이 수행되며, 레이어를 다른 추적 수준으로 설정할 수 있는 효율적인 방법이 없습니다.

3. 가장 번거로운 문제입니다. 사용자 지정 Area에 필요한 사용자 지정 클래스를 호출할 때 POST 작업 중에 로깅을 시도하면 호출이 실패합니다. 즉, AllowUnsafeUpdates 속성을 true로 설정하지 않으면 POST 중에 SPWeb으로 업데이트할 수 없다는 일반 오류가 너무 많이 트리거됩니다. 그러나 단순히 로그 이벤트를 작동시키기 위해 로그 이벤트 중에 SPWeb에서 해당 속성을 설정하는 것은 적절치 못하므로 보다 효율적인 방법을 찾아야 할 것입니다.

이 게시물에서는 이전 예제에 비해 개선된 예제를 추가로 제공합니다. 자세하게는 다음과 같은 사항이 제공됩니다.

1. 사용자 지정 Area에 대한 개선된 클래스. 이 버전에서는 클래스가 보다 간단해졌습니다.

2. 중앙 관리의 모니터링 섹션에 있는 진단 로깅 구성과의 통합. 이 통합으로 인해 사용자 지정 Area 및 Category에 대한 추적 수준 구성을 더욱 폭넓게 지원할 수 있을 것입니다.

3. 등록 정보. 이 정보가 있으면 사용자 지정 ULS 로깅 클래스를 매우 간단하게 등록하고 등록을 취소할 수 있으므로 해당 클래스를 중앙 관리와 통합하고 중앙 관리에서 제거할 수 있습니다.

먼저, 간소화된 새 클래스 버전을 살펴보겠습니다. 이 버전과 첫 번째 게시물의 버전은 비슷한 부분도 많지만 이 버전이 좀 더 간단하고 단순합니다. 새 버전의 클래스는 다음과 같습니다.

    [Guid("833B687D-0DD1-4F17-BF6A-B64FBC1AC6A8")]

    public class SteveDiagnosticService : SPDiagnosticsServiceBase

    {

        private const string LOG_AREA = "Steve Area";

        public enum LogCategories

        {

            SteveCategory

        }

        public SteveDiagnosticService()

        {

        }

        public SteveDiagnosticService(string name, SPFarm parent)

            : base(name, parent)

        {

        }

        public static SteveDiagnosticService Local

        {

            get

            {

                return SPDiagnosticsServiceBase.GetLocal<SteveDiagnosticService>();

            }

        }

        public void LogMessage(ushort id, LogCategories LogCategory,

TraceSeverity traceSeverity, string message,

params object[] data)

        {

            if (traceSeverity != TraceSeverity.None)

            {

                SPDiagnosticsCategory category

                 = Local.Areas[LOG_AREA].Categories[LogCategory.ToString()];

                Local.WriteTrace(id, category, traceSeverity, message, data);

            }

     }

        protected override IEnumerable<SPDiagnosticsArea> ProvideAreas()

        {

yield return new SPDiagnosticsArea(LOG_AREA, 0, 0, false,

new List<SPDiagnosticsCategory>()

{

new

SPDiagnosticsCategory(LogCategories.AzureConfig.ToString(),

                     TraceSeverity.Medium, EventSeverity.Information, 1,

                     Log.LOG_ID)

                });

        }

    }

 

첫 번째 버전에서 변경된 중요한 부분은 다음과 같습니다.

1.  클래스에 GUID 특성을 추가했습니다.

[Guid("833B687D-0DD1-4F17-BF6A-B64FBC1AC6A8")]

 

GUID 특성이 클래스에 추가되었습니다. SharePoint가 구성 데이터베이스에서 클래스를 고유하게 식별하려면 GUID 특성이 필요합니다.

2. 기본 생성자가 변경되었습니다.

        public SteveDiagnosticService()

        {

        }

 

이 항목은 빈 표준 생성자입니다. 이전에는 서비스와 SPFarm의 이름을 가져오는 생성자의 다른 오버로드를 호출했습니다. 그에 비해 코드가 다소 줄어들었을 뿐이지만 경우에 따라서는 코드가 짧은 것도 큰 도움이 됩니다.

3. HasAdditionalUpdateAccess 재정의가 삭제되었습니다. 이 재정의는 이전 버전에서 실제로 사용되지 않았기 때문에 코드가 간소화되도록 제거했습니다.

 

4. ProvideAreas 메서드가 크게 축소되어 이제는 SDK에서 사용되는 패턴과 일치합니다.

 

yield return new SPDiagnosticsArea(LOG_AREA, 0, 0, false,

new List<SPDiagnosticsCategory>()

{

new

SPDiagnosticsCategory(LogCategories.AzureConfig.ToString(),

                     TraceSeverity.Medium, EventSeverity.Information, 1,

                     Log.LOG_ID)

                });

이와 같이 코드가 다소 깔끔해졌으므로 위에서 설명한 1번 문제는 해결되었습니다. 또 다른 문제인 추적 수준 부족, POST 중에 로깅할 때 발생하는 예외, 그리고 중앙 관리와의 통합 등은 코드를 조금 더 실행하고 등록하는 것으로 모두 해결되었습니다. SDK의 예제는 현재 이러한 측면에서는 다소 취약하지만 어쨌든 해당 예제를 통해 필요한 작업을 할 수 있었습니다. 작업을 간소화하기 위해 위에서 설명한 사용자 지정 ULS 클래스가 포함된 새로운 기능을 어셈블리용으로 만들었습니다. 기능 수신기와 해당 기능을 추가하고 FeatureInstalled 이벤트 중에 사용자 지정 ULS 어셈블리를 등록한 다음 FeatureUninstalling 이벤트 중에 해당 어셈블리의 등록을 취소합니다. 여기서는 이러한 솔루션을 사용하는 것이 효율적입니다. 작성되는 기능이 Farm 범위 기능이므로 솔루션 추가 및 배포 시 자동으로 활성화되기 때문입니다. 이 등록 및 등록 취소를 수행하는 코드는 다음과 같이 매우 간단합니다.

public override void FeatureInstalled(SPFeatureReceiverProperties properties)

{

try

       {

SteveDiagnosticsService.Local.Update();

}

catch (Exception ex)

       {

throw new Exception("Error installing feature: " + ex.Message);

}

}

public override void FeatureUninstalling(SPFeatureReceiverProperties properties)

{

try

       {

SteveDiagnosticsService.Local.Delete();

}

catch (Exception ex)

{

throw new Exception("Error uninstalling feature: " + ex.Message);

}

}

또한 여기서는 a) 기능을 패키지한 프로젝트에서 사용자 지정 로깅 클래스를 사용하여 어셈블리에 대한 참조를 추가했으며, b) 사용자 지정 로깅 클래스를 사용하여 어셈블리에 대한 기능 수신기 클래스에 대한 사용 문을 추가했기 때문에 “SteveDiagnosticService”를 참조할 수 있습니다.

사용자 지정 ULS 로깅 클래스를 등록하는 경우 다음과 같은 몇 가지 이점이 있습니다.

· POST 중에 ULS 로그에 쓸 때 SPWeb 문제 업데이트와 관련된 오류가 더 이상 발생하지 않습니다.

· 사용자 지정 로깅 Area 및 Category가 중앙 관리에 표시되므로 진단 로깅 구성으로 이동하여 추적 및 이벤트 수준을 변경할 수 있습니다. 예를 들어 추적이 기본 수준인 Medium으로 설정되어 있는 경우 로그에 쓰는 ULS 항목 중 TracingSeverity.Medium 상태인 항목은 모두 로그에 기록되지만 TracingSeverity.Verbose 상태인 항목은 기록되지 않습니다. TracingSeverity.Verbose 상태의 항목이 로그에 표시되도록 하려면 진단 로깅 구성으로 이동하여 추적 수준을 Verbose로 변경하면 됩니다.

이 솔루션은 전반적으로 훨씬 간단하고 기능성이 뛰어납니다. 여러 가지 면에서 이전 버전보다 효율성이 향상되었다고 생각됩니다.

P.S. 이 게시물에서 Portland Trailblazers 소속 LaMarcus Aldridge의 올스타팀 탈락 항의 투표를 진행하고자 합니다. 서부 컨퍼런스 NBA 올스타 팀에서 LaMarcus가 탈락하다니, 말도 안 되잖아요. 흠, 개인적인 얘기는 이 정도로 하죠. 이 블로그를 방문하시는 분들은 유용한 정보를 원하실 테니까요. 이 게시물이 도움이 되셨길 바랍니다.

이 문서는 현지화된 블로그 게시물입니다. 원본 문서는 Tips for ULS Logging Part 2를 참조하십시오.