앱에 어떤 로깅이 좋은 로깅인가요?

Question

그래서 우리는 제 직장에서의 로그인 통과에 대해 논의했습니다. 여기 계신 여러분 중 일부가 여러분의 접근 방식에 대한 아이디어를 제게 주실 수 있는지 궁금합니다.

일반적으로 우리의 시나리오는 실제로 로깅이 전혀 없으며 대부분 .NET 앱, winforms/WPF 클라이언트가 웹 서비스를 통해 또는 db로 직접 통신하는 것입니다.

그렇다면 실제 질문은 어디에 또는 무엇을 기록할 것인가입니다.현재 사용자가 오류 메시지를 보고하고 있으므로 로그 시작/종료, 예외 등을 가정하겠습니다.

웹 서비스 또는 DB에 대한 호출에 사용합니까?페이지 로드?

당시 사용자가 무엇을 하려고 했는지 어떻게 알 수 있나요?

여러 번의 시도/일에 걸쳐 모든 것을 기록하는 것이 더 낫습니까, 아니면 필요한 것만 기록하는 것이 더 낫습니까(HDD가 저렴하다고 가정할 때).

몇 가지 질문인 것 같지만, 더 큰 매장에서 실제 관행이 무엇인지에 대해 더 많은 아이디어를 얻고 싶었습니다!

Answer 1

로깅의 핵심은 좋은 계획입니다.엔터프라이즈 라이브러리 예외 및 로깅 응용 프로그램 블록(http://msdn.microsoft.com/en-us/library/cc467894.aspx).약간의 학습 곡선이 있지만 꽤 잘 작동합니다.현재 제가 선호하는 접근 방식은 4가지 우선순위 수준을 정의하는 것입니다.4=처리되지 않은 예외(이벤트 로그의 오류), 3=처리된 예외(이벤트 로그의 경고), 2=웹 서비스, db 또는 메인프레임 시스템과 같은 외부 리소스에 액세스(이벤트 로그의 정보), 1=상세/기타 관심 사항(이벤트 로그의 정보)

애플리케이션 블록을 사용하면 기록하려는 우선순위 수준을 조정하는 것이 매우 쉽습니다.따라서 개발 중에는 모든 것을 기록하지만 프로덕션 환경에서는 안정적인 시스템을 얻으면 아마도 처리되지 않은 예외와 처리된 예외에만 관심이 있을 것입니다.

업데이트:명확성을 위해 winform/wpf 앱과 웹 서비스 모두에 로그인하는 것이 좋습니다.웹 시나리오에서는 과거에 클라이언트의 오류를 앱 서버에 다시 연결하는 것이 어려울 수 있는 문제가 있었습니다.주로 웹 서비스를 통한 오류는 SOAP 예외로 마무리되기 때문입니다.머리로는 기억이 나지 않지만 사용자 정의 예외 처리기(엔터프라이즈 라이브러리의 일부)를 사용하면 앱 서버에서 예외의 처리 인스턴스 ID와 같은 예외에 데이터를 추가할 수 있다고 생각합니다.이렇게 하면 LogParser(http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en).

두 번째 업데이트:또한 각 이벤트에 별도의 이벤트 ID를 부여하고 이를 소스 제어 하의 텍스트 파일이나 스프레드시트에서 추적하는 것을 좋아합니다.예, 고통스럽습니다. 하지만 IT 팀이 프로덕션 환경에서 시스템을 관리할 수 있을 만큼 운이 좋다면 IT 팀에서는 다양한 이벤트에 서로 다른 이벤트 ID가 있을 것으로 기대하는 경향이 있습니다.

Answer 2

관리자로서 추적 로그를 제외한 모든 로깅에 대해 이벤트 로그(자체 자체 로그, 그렇지 않으면 애플리케이션 로그 선호)에 기록하는 앱에 대해 정말 감사하게 생각합니다.이벤트 로그에 기록하면 심각한 문제가 발생하기 전에(처리할 수 있는 문제인 경우) 관리 직원이 경고나 오류를 찾아서 처리할 가능성이 훨씬 높아지거나 연락할 수 있게 됩니다. 문제를 추가로 해결하기 위해 추적 로그를 사용할 수 있는 개발자와 협력하세요.

현재 사용자 지정 .NET 앱을 지원할 때 가장 큰 문제점은 동일한 공급업체에서 제공하는 8개의 서로 다른 애플리케이션(일부 콘솔 앱, 일부 Winform 및 일부 웹)이 있다는 것입니다.그들 중 누구도 이벤트 로그에 기록하지 않으며 모두 자신만의 사용자 정의 로그 파일을 가지고 있습니다.그러나 모든 winforms 및 콘솔 앱의 경우 실행 중에 파일을 열어 두므로 문제를 모니터링할 수 없습니다.또한 로그는 모두 약간씩 다르게 작성되므로 유용한 정보를 얻으려면 로그를 약간 다르게 구문 분석해야 합니다.

이로 인해 애플리케이션의 실제 상태가 아닌 애플리케이션의 모양(활성 포트에서 응답하는지, 프로세스 작업 세트가 너무 높아지는지 등)을 모니터링해야 합니다.

배포 후 애플리케이션을 유지 관리하고 사용할 수 있는 로깅을 제공하는 사람들을 고려하시기 바랍니다.감사해요!

Answer 3

highscalability.com의 이 게시물 대규모 분산 시스템 로그인에 대한 좋은 관점을 제공합니다.(그리고 우연히 JoelOnSoftware의 게시물을 언급하면서 시작됩니다.)

Answer 4

여러 번의 시도/일에 걸쳐 모든 것을 기록하는 것이 더 낫습니까, 아니면 필요한 것만 기록하는 것이 더 낫습니까(HDD가 저렴하다고 가정할 때).

하드 드라이브가 저렴하다는 사실은 몇 가지 이유로 가능한 모든 것을 장황하게 기록하는 좋은 이유가 아닙니다.우선, 매우 바쁜 응용 프로그램의 경우 속도를 늦추고 디스크 쓰기 쓰기 로그를 묶고 싶지 않습니다(하드 드라이브는 매우 느립니다).두 번째이자 더 중요한 점은 테라바이트 규모의 로그에서 얻을 수 있는 것이 거의 없다는 것입니다.개발에 유용할 수 있지만 몇 분 이상 보관할 필요는 없습니다.

일부 로깅은 물론 유용합니다. 다른 수준을 갖는 것이 유일한 방법입니다. 예를 들어 debug() info()는 요청된 경우에만(구성 또는 명령줄 플래그에서) 요청된 경우에만 기록되고 warning() 및 error()는 로그 파일로 전송됩니다.

내가 작성한 대부분의 것(작은 스크립트)에는 일반적으로 --verbose가 설정되어 있는지 확인하고 메시지를 인쇄하는 debug() 함수가 있습니다.그렇게 하면 debug("some value:%s" % (avar)) 필요할 때마다 돌아가서 어디에서나 디버깅 print() 문을 제거하는 것에 대해 걱정할 필요가 없습니다.

웹 애플리케이션의 경우 일반적으로 통계용 웹 서버 로그와 오류 로그만 사용합니다.필요할 때 mod_rewrite의 로그와 같은 것을 사용하지만 개발 이후에도 이를 활성화하는 것은 어리석은 일입니다(각 페이지 요청에 대해 많은 행을 생성하므로).

애플리케이션 자체에 따라 다르지만 일반적으로 대규모 애플리케이션의 경우 필요할 때 활성화할 수 있는 여러 수준의 로그를 사용합니다.더 작은 경우 --verbose 플래그 또는 이에 상응하는 웹 애플리케이션의 경우 오류 및 (특정 지점까지) 로그 적중을 기록합니다.

기본적으로 "프로덕션"에는 사용할 수 있는 정보만 기록하고, 개발 로그에는 문제를 해결하는 데 필요한 모든 정보를 기록합니다.

Answer 5

일반적인 데스크톱 앱의 경우 현재 세션에 모든 것을 저장하고 지난 n 세션 또는 최대 x 크기에 대한 정보 메시지를 저장할 수도 있습니다.

나는 당신의 메시지가 정리되어 있다고 가정합니다.우리는 4가지 카테고리를 사용합니다.오류, 경고, 정보 및 추적.우리는 여전히 어떤 수준에서 어떤 일이 일어나는지 파악하고 있습니다.로그 파일을 구문 분석하는 데 익숙해지면서 일반적으로 "log more"라고 말합니다.가독성에 대해 걱정하지 마세요. 로그 파일을 사용하기 전에 약간의 처리가 필요할 수도 있습니다.

결국, 수명과 저장 공간에 대한 스풀 사용을 제어할 수 있는 좋은 로깅 프레임워크와 코드에 미치는 영향을 최소화하는 적절한 API를 찾으세요.이상적으로는 입력만 하면 됩니다. info("waaah") 또는 warning("waah") API가 모든 멋진 태그 지정을 수행합니다.

Answer 6

빠른 답변으로 일련의 범주를 만들고 전환 가능한 로깅 수준을 갖도록 하겠습니다.정보, 경고, 오류, 중요 등

그런 다음 필요한 세부 정보 수준을 조정하기 위해 로깅 수준을 쉽게 설정할 수 있습니다.일반적으로 구성 파일에서 로깅 수준을 설정하고 앱을 중지했다가 다시 시작합니다.

또한 각 레벨의 의미가 무엇인지 개발자들에게 공개하겠습니다.

편집하다:또한 정기적으로, 어쩌면 밤에 로그 파일을 교체하고, 압축하고, 보관하는 시스템을 설정할 것입니다.

Answer 7

고마워요, 좋은 정보가 많이 있지만 Martin이 진행 방법에 대해 좀 더 자세히 설명했습니다.나는 그에게 대답을 줄 것입니다. 이제 우리는 몇 페이지 앞선 답변에서 벗어난 것처럼 보입니다.