오류 로그 유지에 대한 모범 사례(시스템, 장치 드라이버 및 응용 프로그램)

오류 로그 유지에 대한 모범 사례(시스템, 장치 드라이버 및 응용 프로그램)

Ubuntu armhf와 Wi-Fi를 통해 연결된 PC 서버가 있는 여러 Pandaboard가 있습니다. 각 임베디드 보드에는 지속적으로 실행되는 실시간 애플리케이션이 있습니다.

많은 것을 모니터링해야 하기 때문에 로그를 올바르게 유지하는 방법을 모르겠습니다.

  1. 시스템 오류(파일 시스템, 과열 등)
  2. 장치 드라이버 오류(Wi-Fi 및 USB)
  3. 애플리케이션 종료(충돌 및 예상되는 충돌)

지금까지 내 생각:

  1. 심각도 수준 0~3과 같은 시스템 로그를 필터링하여 관련 시스템 오류를 찾습니다.어떻게 해야 하나요?
  2. 장치 드라이버 문제는 시스템 로그에서도 찾을 수 있습니다.
  3. 현재 저는 cout과 cerr을 별도의 파일에 기록하고 있습니다. 응용 프로그램이 충돌하는 경우에는 도움이 되지 않습니다. 디버그 모드에서 실행하려면 너무 많은 처리 능력이 필요하고 시스템이 더 이상 실시간이 아닐 것 같습니다.
  4. 매일 로그를 교체하는 것보다 컴퓨터가 시작될 때마다 또는 로그가 너무 커질 때까지 syslog를 사용하는 것이 좋습니다. 또는 애플리케이션이 시작될 때마다 애플리케이션 로그를 교체하는 것을 선호합니다.
  5. 모든 중요한 문제는 서버에서 쉽게 읽을 수 있는 파일로 파이프될 수 있습니다.

오류 로깅을 효율적으로 유지하기 위한 모든 아이디어를 환영합니다. 현재 저는 Fabric Python 라이브러리를 사용하여 서버 PC와 Pandaboard 간에 진단 정보와 업데이트를 전송하고 있습니다.

답변1

시스템 로거(System Logger)는 이것을 시스템 로거(System Logger)라고 부르지 syslog만, 우분투에서는 시스템 로거(System Logger)라는 보다 정교한 변형을 사용할 수도 있고 사용하지 않을 수도 있습니다 rsyslog. 가장 쉽게 알 수 있는 방법은 ls /etc | grep syslog모두 자체 기본 구성 파일과 .d추가 구성을 수행할 디렉터리가 있습니다. 애플리케이션 내에서 시스템 로거에 정보를 제공할 수 있지만(예: man logger및 참조 man 3 syslog), 당황스러운 복잡함을 원하지 않는 한 이 방법은 주요 오류를 처리하는 데 가장 적합합니다.

소개도 많고시스템 로그 튜토리얼온라인. Rsyslog는 syslog와 호환되도록 설계되었으며 추가 문서는 다음을 통해 제공됩니다.그들의 웹사이트. 기본 구성은 일반적 /var/log으로 다음을 기준으로 메시지를 다양한 파일로 필터링합니다.시설그리고심각성. 모든 메시지의 모든 사본을 수집하는 파일(예 /var/log/syslog: )이 있을 수도 있고 다른 형태의 중복도 있을 수 있습니다. Rsyslog는 콘텐츠를 기반으로 메시지를 필터링하는 추가 기능을 제공합니다(예를 들어 일반적으로 특정 애플리케이션에 첨부된 태그와 일치시킬 수 있음).

로그 회전에 대한 WRT 관련 애플리케이션은 일반적으로 데몬 에 의해 실행되는 logrotate(참고자료 참조 ) 것입니다. 빈도 등의 제어는 해당 구성(일반적 으로 의 다른 파일에서 ) 및 cron을 통해 수행되어야 합니다 . 기본 구성 파일을 사용하지 않으므로 관련 crontab에서 어떻게 호출되는지 확인 하고 싶을 수도 있습니다.man logrotatecron/etc/logrotate.conf/etc/logrotate.dlogrotate

관련 정보