저는 현재 해외에 배포 할 다소 큰 멀티 티어 응용 프로그램을 개발 중입니다. 나는 그것이 넘어지지 않거나 한번 불경 해지기를 희망하지만 나는 이것에 대해 100 % 확신 할 수 없다. 그러므로 로그 파일을 요청할 수 있다는 사실을 알게되면 좋을 것입니다.로깅, 언제 그리고 무엇?
기본적으로 제목에서 알 수 있듯이 로그 할시기를 알고 싶습니다. 내 응용 프로그램이 넘어지면 어떤 일이 발생했는지 쉽게 확인할 수있는 포괄적 인 로그 파일이 있는지 확인하려면이 사실을 알고 싶습니다.
1 - 단일 로그를 표준화 된 형식으로 만듭니다. 그것이 무엇인지는 중요하지 않지만, 엔트리에는 동일한 기본 필드가 있는지 확인하십시오. 그냥 "printf"라고 쓰면 아마 자르지 않을 것입니다. (System.err.println 또는 다른 것으로 대체하십시오)
2 - 적어도 하나의 필드가 임의의 문자열이 될 수 있습니다 ... 개발자가 당신을 잘 알 것입니다. 무엇이 거기에 있어야합니다.
3 - 각 항목에 고해상도 타임 스탬프를 포함하십시오. 너는 결국 그것을 필요로 할 것이다. 나를 믿어 라.
4 - 가능한 경우 오류의 원본 파일과 줄 번호를 포함하십시오. 그것은 C에서 쉽고, Java에서 약간의 고통입니다. 하지만 나중에 이라는 메시지가 매우 유용합니다. 특히 사람들이 오류 메시지를 포함하여 코드를 잘라내 기 시작할 때 유용합니다.
5 - 로그의 코드 수준에서 사용할 수 있는지 확인하십시오.
6 - "기본"은 "문제가 있음을 감지 한 사람"을 의미하는 "기본"및 "보조"오류 태그를 자주 사용했습니다. "보조"는 "함수를 호출했습니다. "오류를보고했다. 따라서 문제의 원인 ("주 : 파일을 찾을 수 없음")을 쉽게 찾고 오류의 의미를보고 할 수 있습니다 ("2 차 : 보정 표를로드 할 수 없음").
7 - 오류가 아닌 오류도 기록 할 수있는 기능을 포함합니다.
가장 어려운 부분은 오류가 반드시 오류는 아닙니다. 파일로 함수를 호출하고 그 파일이 존재하지 않는다면, 그 오류는 기록되어야 하는가 그렇지 않은가? 때때로 그것은 중대한 실패이며 때로는 예상됩니다. 그것은 함수의 API에 달려 있습니다. 함수에 오류를 반환하는 방법이있는 경우 일반적으로 로깅없이 오류를 반환합니다. 오류를보고해야하는지 또는 예상되는지를 결정하는 것이 상위 수준 코드의 작업입니다.
성능 향상에 많은 비용을 지불하지 않는 한 로깅이 중요합니다.
필자가 기록하기를 바라는 가장 중요한 일은 화창한 날씨 시나리오를 코딩하는 동안 무시하는 경향이있는 경고, 웁스, 온 전성 검사 실패, 비오일 시나리오 등입니다. "우리는 여기에 도착해서는 안됩니다."등의 인쇄물로 인쇄물을 인쇄합니다. 이러한 것들은 테스트 중에 나타나지 않고 배치 중에 갑자기 나타나기 시작하는 경향이 있습니다.
원격으로 결과를 읽으려는 경우 정확한 시간 소인, 위치 및 일종의 세션 ID를 캡처해야합니다 (여러 인스턴스가 동시에 실행되고 로그 파일에 기록하는 경우). 하나의 실행에 어떤 메시지가 포함되어 있는지 확인하는 것이 더 쉬울수록 좋습니다.
오류 수준 및 유형도 중요합니다. 여러 위치에서 동일한 메시지를 쓰지 않거나 추적이 어려울 수 있는지 확인하기 위해 검색을 수행하는 것도 중요합니다.
마지막으로 Mac OS X 사용자가 Mac OS X을 실행하는 경우 로깅 오류에 매우주의해야합니다. Leopard 에서조차 기본 로깅 메커니즘이 처리되어 많은 CPU를 소비 할 수 있습니다.
먼저 특정 언어는 언급하지 않았지만 Apache log4j를 기반으로하는 프레임 워크는 안전한 방법이 될 것입니다. 가장 중요한 것은 프레임 워크가 다양한 수준의 자세한 표시 (디버그 메시지, 경고, 오류 메시지)를 지원한다는 것입니다. 로거는 실제로 쓸 메시지와 로깅을 사용하기 위해 바퀴를 다시 발명 할 필요가없는 지점에 대해 런타임에 구성 할 수 있습니다.
원본에 로깅 프레임 워크를 구현하십시오. 최소한 응용 프로그램에서 발생할 수있는 예외 사항을 기록한 다음 "값을 추가"해야합니다. 스택 추적을 로그 파일에 작성하는 것은 모두 훌륭하지만 좋은 방법이지만, 문제를 진단 할 수있는 경우는 드물기 때문에 catch 매개 변수의 값과 같은 정보를 로깅하는 것이 좋습니다.
더 높은 수준에서 다양한 수준의 자세한 표시 기능을 활용하여 응용 프로그램에서 발생하는 상황을 기록 할 수 있습니다. 이는 원격 디버거를 연결할 수없는 프로덕션 시스템에서만 오류가 발생하는 경우 특히 유용합니다. 로그 프레임 워크 구성 파일에서 자세한 정보 수준을 높이고 모든 디버그를 관찰 할 수 있습니다 ("매개 변수가있는 메소드 호출 X Y ") 메시지가 로그에 나타납니다.
클라이언트를 통해 보낸 로그를 통해 문제를 조사하고, 배포 한 후에 만 로그에 기록 할 수있는 좋은 방법이 제공되는 대규모 미션 크리티컬 애플리케이션에 작은 비트를 추가하고 싶습니다. (성숙도는 응용 프로그램이 한 곳에서 배포되고 사용되는 시간 및 다른 클라이언트/위치에서의 다른 배포 횟수와 직접 관련이 있습니다).
전 세계에서 사용되는 대형 전화 기반 시스템을 개발하고 수년간 자체 로깅 시스템을 응용 프로그램에 사용했습니다. 디버그 수준은 매우 중요하며 우리의 응용 프로그램은 "오류 전용"으로 설정된 디버그를 제공하며 대부분의 시간에 민감하지만 대부분의 경우에 파일에 로그가 활성화됩니다. 우리는 또한 출력을 디버그 추적 시스템으로 전환하는 것을 지원합니다 (이것은 Windows이므로 OutputDebugString에 대한 간단한 호출이며 엔지니어는 DBWIN32라는 디버거 포수에 액세스 할 수 있습니다). 어떤 종류의 버그 때문에 직렬화 된 여러 개의 앱에서 출력물을 볼 수 있어야하기 때문에 이것은 중요합니다. 나는이 기술을 적용하여 심각하게 까다로운 다중 앱 상호 작용 버그를 해결했다. 앱은 일반적으로 사람이 읽을 수있는 태그를 출력에 추가하므로이 시나리오에서는 어떤 앱에서 어떤 라인이 왔는지 알 수 있습니다.
우리가 사용하는 레벨은 일반적으로 꺼짐, 오류 만, 기본, 상세, "자세한 정보"입니다 (자세한 내용은 설문 결과, 사용자 작업, 메시지 내용 등 여러 가지를 암시하는 자리 표시 자입니다 - 저자가 중요하다고 생각하는 모든 것) .
아, 앱이 로그 파일에 쓰는 첫 번째 항목은 버전 리소스를 제공하는 헤더입니다. 따라서 우리는 사용자 또는 지역 엔지니어가 알기를 신뢰하지 않습니다. -)
AOP는 비 침입 로깅에 정말 유용합니다. 예를 들어 AOP를 사용하여 각 메소드에 로깅 문을 실제로 추가하지 않고 매개 변수 값을 기록하고 모든 메소드 호출의 값을 반환 할 수 있습니다.
이 작업을 수행하는 방법에 대한 구체적인 내용은 명시 적으로 대상 언어 및 플랫폼 (지정하지 않은 항목)에 따라 다릅니다. 이러한 로거를 Java Spring 기반 애플리케이션에 추가하는 방법에 대한 예제는 here을 참조하십시오.