Automation Anywhere 설명서 읽기 및 검토

Automation Anywhere

콘텐츠 닫기

콘텐츠

콘텐츠 열기

로깅

  • 업데이트: 5/10/2019
    • 11.3.x
    • 탐색
    • Enterprise

로깅

로그는 쉽게 읽고 구문 분석할 수 있어야 합니다.

로그 파일은 다양한 애플리케이션과 및 시스템 구성요소에서 발행된 메시지를 저장합니다.

로그는 쉽게 읽고 이해하고 구문 분석할 수 있어야 합니다. 로그 파일을 읽기 쉽고 명확하며 이해하기 쉬운 상태로 유지하십시오. 처리 중인 데이터를 표시하고 해당 의미를 표시합니다. 이 실제로 수행하는 작업을 보여줍니다. 좋은 로그는 자체의 훌륭한 문서로 사용될 수 있습니다.

로그는 사람과 머신이 다음을 수행하는 데 도움이 됩니다.

  • 프로세스가 성공적으로 완료되었는지 판별합니다.
  • 프로세스가 완료되지 않은 경우 프로세스가 완료되지 못한 이유에 대한 정보를 검토합니다.
  • 이 예상대로 수행되는지 판별합니다.
  • 대화식으로 로그를 따라갑니다.
  • 도구를 사용하여 로그를 구문 분석하거나 로그를 Excel로 가져와 메트릭을 수집하고 분석합니다.
  • 로그를 데이터베이스로 가져옵니다.

다음은 로깅을 제대로 실행하기 위한 표준 세트입니다.

로그 유형

  • 프로세스/정보 - 프로세스 로그는 정보 로그입니다. 정상적인 태스크 작업을 모니터링하는 데 사용할 수 있지만 더 중요한 것은 감사에 사용할 수 있다는 것입니다. 감사 추적에 프로세스 로그를 사용하는 것은 비즈니스 프로세스가 제대로 완료되었는지를 판별하는 훌륭한 방법일 수 있습니다. 예를 들어, 주문을 완료했거나 티켓을 오류 없이 완료했는지를 판별할 수 있습니다.
  • 오류 - 오류 로그는 자세한 오류 메시지입니다. 태스크에서 오류가 발생하면 프로세스 로그에 오류가 발생했음을 알립니다. 오류에 대한 자세한 정보를 오류 로그에 기록합니다.
  • 디버그 - 프로덕션 모드에서 자체 로그 파일에 디버깅 정보를 저장하고 디버그 수집을 해제합니다. 이 프로덕션으로 이동하면 isProductionMode 변수를 사용하여 이러한 명령문을 해제합니다.
  • 성능 - 성능 로깅은 프로세스/정보 로그 또는 성능 로그 중 하나로 이동할 수 있습니다. 경우에 따라 성능 메시지를 자체 로그 파일에 저장하는 것이 유용합니다.

메시지 유형

  • 오류 - 심각한 잘못이 발생하여 즉시 조사해야 합니다. 이 상태에서는 태스크가 기능을 제대로 수행할 수 없습니다. 예: 데이터베이스가 사용 불가능한 경우, 미션 크리티컬 사용 사례를 계속 수행할 수 없는 경우, 파일이 사용 중이므로 열 수 없는 경우입니다.
  • 경고 - 태스크를 계속 수행할 수는 있지만 세심한 주의가 필요합니다. 예 : Task is running in development mode. 태스크를 계속 수행할 수 있지만 항상 메시지를 입증하고 검사하십시오.
  • 정보 - 중요한 비즈니스 프로세스가 완료되었습니다. 정보 메시지는 때때로 애플리케이션 정보를 애매하게 명시합니다. 예 :
    • 애플리케이션 작업이 완료되었습니다. 항공사 예약 애플리케이션의 경우 각 티켓당 하나의 정보 문만 발행하며 [Who] booked ticket from [Where] to [Where]를 명시합니다.
    • 애플리케이션 변경은 명확하게 명시됩니다. Database update or External system request
  • 디버그 - 을 디버깅하는 데 유용한 모든 정보입니다. 일반적으로 개발자가 사용합니다. 이 메시지는 프로세스 로그로 이동하지 않습니다. 이 프로덕션으로 이동하면 isProductionMode 변수를 사용하여 이러한 명령문을 해제합니다.
  • 성능 - 성능 로깅은 프로세스/정보 로그로 이동하거나, 별도의 성능 로그가 생성된 경우 성능 로그로 이동할 수 있습니다. 성능은 특정 단계를 수행하는 데 걸리는 시간을 추적하지만 세분화되지는 않습니다. 대부분의 경우 전체 비즈니스 프로세스에 대한 성능 로깅으로 제한됩니다. 예를 들어, 주문을 완료하는 데 걸린 시간 또는 송장을 처리하는 데 걸린 시간 등입니다.

로그 생성 팁

  • 사용자

    로그 파일에는 두 유형의 사용자가 있습니다. 사람 및 머신.

    사람 사용자 - 사람이 사용자인 경우 이 역할은 찾고 있는 정보 유형에 영향을 줍니다. 개발자는 디버깅하거나 성능을 분석하거나 오류를 찾기 위해 정보가 필요할 수 있습니다. 분석가는 감사 정보 또는 성능 정보가 필요할 수 있습니다.

    머신 사용자 - 머신은 일반적으로 시스템 관리자가 작성한 쉘 스크립트를 통해 로그 파일을 읽습니다. 이 두 로그 파일 사용자에 적합한 로그를 설계하십시오.

  • 콘텐츠

    • 객체 포함 - 좋은 로그는 다음을 포함합니다. 타임 스탬프, 로깅 레벨, 머신 이름, 태스크 이름 및 메시지.

    • 오류 로그 문 - Automation Anywhere 오류 처리 블록의 오류에 대한 라인 번호와 오류 설명이 포함됩니다.

    • 디버그 문 - 하위 태스크 간에 변수를 전달할 때 디버깅 로그 문을 사용합니다. 하위 태스크를 시작하고 종료할 때 변수 값을 포함시킵니다. 이 프로덕션으로 이동하면 isProductionMode 변수를 사용하여 디버깅 문을 해제합니다.

    • 인터페이스 호출 - 이 메타Bot, API, REST 또는 SOAP 호출 등 다른 시스템과 인터페이스로 접속하는 경우 해당 호출과 응답(해당되는 경우)을 로깅합니다.

  • 서식 지정
    • 구분 기호 - 콘텐츠 값을 제한합니다. 손쉽게 로그 파일을 가져오고 구문 분석하기 위해 탭 구분을 사용하여 값을 분리합니다.

    • Log-to-file(파일에 로깅) - log-to-file 기능을 사용하여 Automation Anywhere에 구축합니다.

    • 타임 스탬프 - log to file 명령에서 기본 제공 타임 스탬프를 사용합니다.

      주: Excel의 경우에도 타임 스탬프를 위한 자체 메서드 및 형식을 만들지 마십시오. 다른 타임 스탬프를 위해 특정하게 필요한 경우에만 기본 제공 버전을 수정하십시오.
  • 보안 및 단축키
    • 비밀번호 - 로그 비밀번호나 개인 정보는 절대 사용하지 마십시오!

    • 단축키 - 몇 사람만 이해할 수 있는 단축키 문자와 스크립트(매직 코드)는 추가하지 마십시오.

    • 숫자 지정 - 숫자 형식은 사용하지 마십시오. 정규식으로 쉽게 인식할 수 있는 패턴을 사용하십시오.

  • 성과

    • 과도한 로깅 - 일반적인 로깅 명령 자체는 성능면에서 비용이 많이 들지 않습니다. 그러나 과도한 로깅은 사용하지 마십시오. 예를 들어, 작은 루프 내에서 여러 번 반복하는 경우입니다.

    • 빈도 - 24시간마다 새로운 로그를 생성합니다. 현재 날짜를 확인하는 코드를 추가하십시오. 날짜가 변경되면 새 로그를 생성하십시오. 필요에 따라 이전 로그 파일을 압축하여 보관합니다(유휴 상태). 이렇게 하면 지나치게 큰 로그 파일을 방지할 수 있습니다.

피드백을 보내주십시오