답변:
필자는 귀중한 도구에 로그인하여 주로 임베디드 응용 프로그램을 수행했습니다. 최소한 코드 줄을 가리키는 충분한 정보로 오류를 기록해야합니다. 다음으로 응용 프로그램 전체의 주요 기능 포인트가됩니다. 관리자와 같은 것들이 컴퓨터에 액세스했습니다. 보다 자세한 로깅을 가능하게하는 시스템을 사용합니다. 일반적으로 개발자마다 다릅니다. 기능을 테스트하는 동안 개발자를 지원하는 데 사용되거나 고객 문제를 진단하는 데 도움이 될 수 있습니다.
내가 개발 한 모든 응용 프로그램에서 개인적으로 로깅을 사용했습니다. 항상 응용 프로그램의 흐름을 더 잘 이해하게되었습니다. 특히 고객의 손에있을 때. 사용 사례를 테스트 대상으로 제한하지 않습니다.
나는 그것이 응용 프로그램의 종류에 달려 있다고 생각하지 않습니다 : 로깅은 모든 (사소하지 않은) 응용 프로그램 에서 유용 합니다. 확실히, 그것은 다른 응용 프로그램보다 일부 응용 프로그램에서 더 유용 할 수 있지만 결코 쓸모 가 없다고 생각합니다 .
특히, 오류의 경우 스택 추적은 정확한 오류 지점 에서 프로그램 상태를 알려 주지만 오류 직전 의 상태에 대한 단서가 거의 없습니다 . 이 정보는 문제를 추적하는 데 매우 유용 할 수 있으며 로깅을 통해 유용한 정보를 얻을 수 있습니다. 나는 그것이 가장 사소한 프로그램을 제외한 모든 것이 이익을 얻을 수있는 것이라고 생각한다.
모든 프로그램에 유용하지 않은 로깅의 또 다른 사용은 통계 분석에 있습니다. 예를 들어, 웹 서버는 일반적으로 들어오는 모든 요청을 기록한 다음 해당 로그를 분석하고 가장 바쁜 시간, 가장 인기있는 페이지 등의 그래프를 생성 할 수있는 많은 도구가 있습니다. 이 데이터를 사용하여 용량 계획 ( "더 큰 서버가 필요합니까?")을 수행 할 수 있습니다.
로깅이 수행되는 두 가지 이유가 있습니다.
진단 로깅 은 이미 다른 사람들에 의해 논의되어 왔으며 요점을 더 자세히 설명하지 않겠습니다. 로그 오류가 발생하면 어떤 일이 발생하는지 강하게 생각해야한다고 말씀 드리겠습니다. 앱을 통해 예외를 발생 시키거나 다른 방법으로 관리 할만큼 충분히주의하십니까? 이것은 "의존적"이지만 로깅 정보 레벨 메시지는 생략해야합니다.
감사 로깅 은 비즈니스 요구 사항입니다. 감사 로깅은 시스템의 중요한 이벤트를 캡처하고 관리 및 합법적 독수리가 관심을 갖는 대상입니다. 이는 누군가 사인 오프 한 사람, 편집 한 사람 등입니다. 시스템 관리자 또는 시스템 문제를 해결하는 개발자는 아마 여러분 일 것입니다 이것에 약간만 관심이 있습니다. 그러나 대부분의 경우 이러한 종류의 로깅은 트랜잭션의 일부이므로 완료 할 수없는 경우 전체 트랜잭션이 실패해야합니다.
하나는 "선택적"이고 다른 하나는 필수이기 때문에 두 가지를 별도로 생각하면 도움이 될 수 있지만 요구 사항에 따라 실제로 별도로 구현해야 할 수도 있습니다. 그들이 둘 다 과일이지만 하나는 사과이고 다른 하나는 오렌지 일 수 있습니다. 일반적으로 단일 로깅 프레임 워크는 둘 다 처리 할 수 있습니다.
대부분의 서버 작업에서 관리자는 일반적으로 상황이 발생하지 않기 때문에 로깅이 중요하므로 사후 점검이 필요합니다.
그러나 Google 직원은 서버 프로세스가 로깅을 수행하지 않는다고 한 번 말했습니다. 대신, 그들은 '악기'입니다; 즉, 모든 프로세스에는 다른 프로세스가 매개 변수 및 통계를 요청하기 위해 래치 할 수있는 후크 또는 포트가 있습니다 (기계를 지정하지 않았습니다). 로그에 많은 것을 저장하는 것은 모니터링 프로세스입니다. 이점은 그들이 얻는 정보가 "파일 열기", "쓰기", "가져 오기"가 아니라는 것입니다. "45,453 개 파일 열기", "653 개의 서비스 클라이언트 X", "쿼리 Y에 대한 평균 344ms"
확실히 다른 접근 방식이며, 시스템이 약간 더 작더라도 시스템을 보모하면서 염두에 두는 경향이 있습니다.
나는 모든 것을 기록한 winforms N-Tiered 애플리케이션에서 나왔습니다.
별로 유용하지 않았습니다.
물론 예외 로깅은 훌륭합니다. 그러나 개발자 팀에게 예외를 이메일로 보낼 수 있는데 왜 클라이언트의 컴퓨터에 기록합니까?
정보 기록은 쉽게 가치가 거의없는 중독으로 바뀝니다. 무료로 로그인 할 수있는 모든 상황에 대해 대상 정보를 수집하여 필요한 곳으로 보내는 것이 좋습니다.
예외 정보를 캡처하는 것은 어느 정도 도움이 될 수 있으므로 필수입니다. 그러나 응용 프로그램 사용자 / 클라이언트가 적절한 정보로 오류를보고 할 수없는 경우 특히 예외 정보가 충분하지 않은 경우가 있습니다.
로깅은 오류 정보 캡처로만 제한됩니까?
필자의 경우 (웹 응용 프로그램) 항상 방문한 페이지, 클릭 한 시간, 클릭 한 위치, IP 및 브라우저 등을 기록합니다. 각 페이지 방문에 대한 총로드 시간도 기록하므로 느린 페이지를 알 수 있습니다 최적화가 필요합니다. 가능한 한 많이 기록한다고 말할 수 있습니다.
처음에는 그것이 얼마나 중요한지 전혀 몰랐습니다. 그러나 분명히 그것은 디버깅 이외의 많은 것들에 매우 도움이됩니다.
통계 정보를 파는 것을 좋아한다면 로깅이 더 중요해질 수 있다고 생각합니다.
저는 제품을 해외에 배포 한 회사의 개발자입니다. 지원 팀이 문제 정의에 관해 질문 할 때 진단을위한 유일한 도구는 내 로그 파일과 고객 데이터베이스의 사본입니다. 데이터베이스와 개발 환경을 사용하면 들어오는 데이터를 모듈 및 관련 작업에 기록하기 때문에 잘못된 사례를 재현 할 수 있습니다. 수집 한 데이터를 사용하여 오류를 재현 할 수 있으면 디버깅으로 수정할 수 있습니다. 로그 파일이 없으면 고객 또는 지원 팀이 어떤 경우에 어떤 일이 발생하는지에 대한 설명 (오해의 소지가있을 가능성이 높음)에 의존해야합니다.
둘째, 로깅을 통해 배포 된 사이트에서 모듈의 병목 현상을 감지 할 수 있습니다. 특정 작업의 날짜 및 시간을 기록한 다음 어떤 작업이 얼마나 많은 시간을 소비하는지 확인할 수 있기 때문입니다.
또한 솔루션이 6 개의 모듈로 구성되어 있고 데이터베이스 시간 초과에 대한 로그 파일에 오류 로그가 있다고 가정합니다. 이러한 오류가 다른 모듈 중 5 개에도 기록되면 이것이 SQL Server 관련 문제 일 가능성이 더 커집니다. 이것이 내 모듈에만 기록되면 쿼리가 버그 일 가능성이 커집니다. 이런 종류의 것들이 유용한 지표라고 생각합니다.
로그 파일에 어떤 종류의 데이터가 표시되는지는 로그 수준의 구성에 따라 다릅니다. 이 제품이 새로운 제품이라면 가능한 많은 데이터를 수집하기 위해 로그 수준을 "모두"로 설정했습니다. 그러나 제품을 개선 할 때 정보 수준 로그 등이 아닌 오류 만 기록하려면 로그 수준을 "오류"로 유지하는 것이 좋습니다.
로깅은 다른 프로그램으로는 얻을 수없는 정보에 유용합니다.
참고 : 최소한 두 개의 로그 파일이 필요합니다.
정보 하나는 항상 켜져 있습니다. 필요할 때 DEBUG가 켜집니다.
언젠가는 모든 것이 로그 파일 인 상황을 디버그해야한다고 예상하는 로깅 코드를 작성하십시오. 올바르게 수행하는 것은 해고와 승격의 차이 일 수 있습니다.
추가 마일을 얻으려면 모든 함수 호출에서 매개 변수를 Java의 스택 추적에 추가하십시오.
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
이 접근 방식은 본질적으로 매개 변수 값으로 호출 스택을 향상 시키며 스택 추적만으로 상황을 분석하고 로그 파일을 볼 필요가 없습니다.
그것은 확실히 당신이 만드는 시스템의 유형에 달려 있습니다.
워드 프로세서와 같은 독립 실행 형 데스크톱 응용 프로그램을 작성하는 경우 로깅이 필요하지 않을 수 있습니다.
임베디드 시스템을 작성하는 경우 로깅 없이는 살 수 없습니다. 그렇지 않으면 내장 장치가 멈출 때 이유를 모릅니다. 또한 시스템에 여러 프로세스 또는 여러 물리적 시스템이 서로 통신 할 때마다 로깅이 필요합니다. 다시 말하지만, 시스템이 정지되면 언제, 왜 어떤 부분이 사망했는지 알아야합니다. 데이터가 한 프로세스에서 다른 프로세스로 전달되는지 여부를 판별하려면 로그를 비교할 수 있어야합니다. 마찬가지로, 직접적인 사용자 상호 작용없이 시스템을 장시간 실행할 때마다 로깅이 필요합니다.