프로그래머 로그의 품질을 향상시키는 5가지 방법

프로그래머 로그 품질을 향상시키는 5가지 방법
최근 Scribe 및 Logstash와 같은 오픈 소스 프로젝트는 물론 Splunk와 같은 선불 도구, 호스팅 서비스 등 프로그래머가 로그를 이해하는 데 도움이 되는 다양한 새로운 도구가 등장했습니다. SumoLogic 및 PaperTrail. 이러한 도구의 공통점은 로그 데이터를 정리하고 대량의 로그에서 더 가치 있는 파일을 추출한다는 것입니다.
로그 품질을 향상하기 위한 5가지 팁
하지만 이러한 도구는 실제로 입력한 로그 데이터에 전적으로 의존하기 때문에 도움이 되지 않는 한 가지가 있으며, 데이터의 품질과 양을 보장하는 방법은 다음과 같습니다. 사용자. 따라서 중요한 순간에 부분적이거나 누락된 로그를 기반으로 코드를 디버깅해야 하는 경우 상황이 까다로워질 수 있습니다.
이런 일이 발생할 가능성을 줄이기 위해 저널링 시 명심해야 할 5가지 팁은 다음과 같습니다.
1. 안녕하세요, 제 (스레드) 이름은
Ringo로서 스레드 이름 속성은 가장 중요한 것 중 하나입니다. Java의 과소평가된 메소드 그 이유는 스레드 이름이 대부분 설명적이기 때문입니다. 그러나 여기에서도 문제가 발생합니다. 사람들 자신과 마찬가지로 이름을 지을 때 일반적으로 특정 의미를 부여합니다. 멀티스레드 로그에서는 스레드 이름도 중요한 역할을 합니다. 일반적으로 대부분의 로깅 프레임워크는 호출되는 스레드의 이름을 기록합니다. 안타깝게도 우리는 일반적으로 스레드 풀이나 컨테이너에 의해 단순히 할당된 http-nio-8080-exec-3과 같은 이름을 봅니다.
어떤 이유로 우리는 이러한 오해를 여러 번 들었습니다. 스레드 이름은 변경할 수 없습니다. 반면 로그에서는 스레드 이름이 기본적인 역할을 하므로 올바르게 사용해야 합니다. 예를 들어 서블릿 이름, 작업 관련 또는 사용자나 메시지 ID와 같은 일부 동적 컨텍스트와 같은 특정 컨텍스트와 결합합니다.
이 경우 코드 인터페이스는 다음과 같아야 합니다.
Thread.currentThread().setName(ProcessTask.class.getName() + “: “+ message.getID);
고급 버전 현재 스레드의 스레드 로컬 변수에 로드되고, 로그 어펜더를 구성하고, 이를 자동으로 로그 항목에 추가합니다.
이 기능은 여러 스레드가 서버 로그에 기록 중일 때 유용하지만 단일 스레드에 집중해야 합니다. 분산/SOA 환경에서 실행하는 경우 고유한 이점도 확인할 수 있습니다.
2. 분산 식별자
SOA 또는 메시지 기반 아키텍처에서는 작업 실행이 여러 시스템에 걸쳐 있을 가능성이 높습니다. 이러한 환경에서 장애를 처리할 때 관련 기계와 그 상태를 연결하는 것이 상황을 이해하는 데 핵심이 됩니다. 대부분의 로그 분석기는 이러한 로그 메시지를 그룹화하므로 사용자가 고유 식별자를 제공한다고 가정하면 실제 로그 메시지의 일부가 될 수 있습니다.
설계 관점에서 이는 시스템 진입부터 작업 완료까지 각 인바운드 작업에 고유한 ID가 있어야 함을 의미합니다. 사용자 ID와 같은 영구 식별자는 좋은 컨테이너가 아닐 수도 있습니다. 로그 파일을 기록하는 과정에서 사용자는 여러 작업을 수행할 수 있으며 이로 인해 특정 흐름을 격리하는 것이 더 어려워집니다. UUID가 좋은 선택일 수 있습니다. 해당 값은 실제 스레드 이름에 로드되거나 TLS 스레드에 대한 로컬 저장소로 로드될 수 있습니다.
3. 텍스트 + 드라이브를 사용하지 말고 로그 + 루프를 사용하지 마세요.
코드 조각이 긴밀한 루프에서 실행되고 해당 로그 작업을 수행하는 것을 여러 번 볼 수 있습니다. 기본 가정은 코드가 제한된 횟수만큼 실행될 수 있다는 것입니다.
아마 아주 잘 돌아가고 있을 겁니다. 그러나 코드가 예상치 못한 입력을 받으면 루프가 중단되지 않을 수 있습니다. 이 경우 무한 루프(비록 그것만으로도 충분히 나쁘지만)를 처리하는 것이 아니라 무한한 양의 데이터를 디스크나 네트워크에 쓰는 코드를 처리하는 것입니다.
독립형 시나리오에서는 서버 충돌이 발생할 수 있지만 분산형 시나리오에서는 전체 클러스터가 영향을 받습니다. 따라서 가능하다면 긴밀한 루프에 로그인하지 마십시오. 오류를 포착할 때 특히 그렇습니다.
다음 예제는 while 루프에서 예외를 기록합니다.
void read() {
while (hasNext()) {
try {
readData()
} catch { 예외 e) {
// 이는 권장되지 않습니다
logger.error(“error reading data“, e)
}
}
}
readData가 예외를 발생시키는 경우 발생하고 hasNext의 반환 값이 true이면 여기에 무제한 로그 데이터가 기록됩니다. 이 문제를 해결하는 방법은 다음 중 아무것도 기록되지 않도록 하는 것입니다.
void read() {
int 예외 발생 = 0
while (hasNext()) {
try {
readData( );
} catch {Exception e) {
if (ExceptionsThrown < THRESHOLD) {
logger.error("error reading data", e)
ExceptionsThrown++; else {
// 이제 오류로 인해 시스템이 중단되지는 않습니다.
}
}
}
}
또 다른 방법은 루프에서 로그 기록을 제거하고 1/마지막 예외 개체이며 다른 곳에 기록되었습니다.
4. 잡히지 않은 핸들러
Westeros에는 마지막 방어벽이 있고 Thread.uncaughtExceptionHandler가 있습니다. 따라서 가능한 한 많이 사용하십시오. 이러한 핸들러를 설치하지 않으면 예외가 발생했을 때 귀중한 컨텍스트를 거의 얻을 수 없으며 예외가 끝나기 전에 로그한 위치를 제어할 수 없습니다.
(종료된) 스레드의 변수에 액세스할 수 있는 방법이 없는 것처럼 보이는 포착되지 않은 예외 핸들러에서도 실제 스레드 개체에 대한 참조를 계속 얻을 수 있습니다. 1단계를 고수하면 여전히 기록할 의미 있는 thread.getName() 값을 얻게 됩니다.
5. 외부 호출 캡처
외부 API가 호출될 때마다 JVM 예외 확률이 크게 높아집니다. 여기에는 웹 서비스, HTTP, DB, 파일 시스템, 운영 체제 및 기타 JNI 호출이 포함됩니다. 언제든지 폭발할 수 있으므로 모든 통화를 진지하게 받아들이십시오. "동일한 시점에 발생할 가능성이 매우 높습니다."
대부분 외부 API 실패의 원인은 예상치 못한 입력이며, 이를 로그에 기록하는 것이 코드 수정의 핵심입니다.
이 시점에서 오류를 기록하지 않고 예외를 발생시키도록 선택할 수 있습니다. 이 경우 호출의 관련 매개변수를 수집하여 예외 오류 정보로 구문 분석하면 됩니다.
더 높은 수준의 스택 호출에서 예외가 포착되고 기록되는지 확인하세요.
LAMP Brothers의 원본 PHP 비디오 튜토리얼 CD/"Essential PHP in Detail"을 무료로 받으세요. 자세한 내용은 공식 웹사이트 고객 서비스에 문의하세요:
http://www.lampbrother.net
[Brothers IT 교육] PHP, Linux, HTML5, UI, Android 및 기타 비디오 튜토리얼(코스웨어 + 노트 + 비디오)을 배우십시오!
네트워크 디스크 튜토리얼 다운로드: http://pan.baidu.com/s/1mg8ANMg

위 내용은 내용의 측면을 포함하여 프로그래머 로그의 품질을 향상시키는 5가지 방법을 소개합니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.