감사 로그란 무엇입니까?
각 규칙에는 규칙이 트리거 된 시기, 실행의 최종 결과 및 수행되었을 수 있는 모든 액션을 확인하기 위해 검토할 수 있는 감사 로그가 있습니다.
각 규칙 액션에 대해 감사 로그에 다음이 표시됩니다.
Date : 규칙이 트리거된 날짜 및 시간입니다.
Rule : 규칙의 이름입니다.
Status : 규칙 실행 상태입니다.
Duration : 규칙을 실행하는데 걸린 시간입니다.
Operations : 규칙이 수행한 액션 및 관련 항목입니다.
프로젝트 범위 또는 글로벌 수준에서 개별 규칙의 감사 로그를 볼 수 있습니다. 감사 로그를 검토하면 규칙을 효과적으로 디버깅할 수 있습니다.
서비스 제한은 무엇입니까?
인스턴스의 성능을 유지하기 위해 다음과 같은 자동화 서비스 제한이 적용되었습니다.
요약 | 제한 | 이 제한은 어떻게 위반할 수 있습니까? |
---|---|---|
규칙당 구성 요소 수 | 65 | 단일 규칙에 65개 이상의 조건, 브랜치 및 실행이 포함됩니다. |
액션당 새 하위 작업 수 | 100 | 규칙은 100개 이상의 하위 태스크 생성을 실행합니다. |
검색된 이슈 | 1000 | 충분히 효율화되지 않고 1000개 이상의 이슈를 반환하는 예약된 JQL 검색입니다. |
동시 예약된 규칙 실행 | 1 | 실행하는데 5분 이상 걸리는 예약된 규칙이며, 매 5분마다 예약됩니다. 이 규칙의 단일 동시 실행만 허용됩니다. |
규칙에 연결된 항목 | 5000 | 단일 규칙 실행에서 가져올 수 있는 항목 수를 정의합니다. 예를 들어, 100개의 문제를 가져오는 스케줄링된 트리거와 각 이슈당 10개의 하위 작업을 가져오는 관련 브랜치는 이 제한에 100*10=1000개의 관련 항목을 추가합니다. |
전역적으로 대기 중인 항목 | 50000 | 규칙에 따라 대기 중인 항목과 유사하지만 전역적으로 Jira 인스턴스에서 진행 중인 규칙에 적용됩니다. |
*일별처리시간 | 12시간당 60분 | 규칙은 5분마다 실행되며 각 실행에는 5초 이상 걸립니다. 예를 들어 규칙이 외부 시스템 속도를 저하시키는 경우 이 문제가 발생할 수 있습니다. |
루프 감지 | 10 | 이것은 실행이 중지되고 LOOP로 표시되기 전에 규칙이 자체(또는 기타 규칙)를 연속적으로 트리거할 수 있는 횟수를 제어합니다. |
*서비스 제한 위반 트리거를 사용하여 일일 또는 시간당 처리 제한에 도달할 때 알림을 보내는 자동화 규칙을 생성할 수 있습니다.
한계치 위반
감사 로그의 다음 오류는 서비스 제한을 위반하고 있음을 나타낼 수 있습니다:
감사 항목 상태가
THROTTLED
입니다.감사 항목에 다음이 포함됩니다:
Automation for Jira has exceeded the allowed total processing time for this rule. Maximum allowed processing time over 12 hours is (in seconds):
A JQL search in this automation rule has exceeded the allowed maximum number of issues to retrieve per search. Only the first issues up to the following limit where processed:
규칙이 서비스 제한을 위반하는 경우 감사 로그는 오류에 대한 자세한 정보를 제공합니다.
감사 로그에 제공된 정보를 사용하여 몇 가지 단계를 수행하여 규칙이 허용 가능한 제한 아래로 떨어지도록 할 수 있습니다. 몇 가지 일반적인 주의사항은 다음과 같습니다:
예약된 규칙이 실행되는 간격을 줄입니다. 예를 들어 매 5분마다 규칙을 실행하는 대신 매 시간마다 규칙을 실행합니다.
JQL 쿼리를 관심 있는 이슈만 검색하도록 제한합니다. 예를 들어, 이슈의 업데이트된 시간이 특정 범위(
updated > -1w
지난 주의 이슈만 포함하도록 제한) 내에 있는지 확인합니다.규칙당 구성 요소가 더 필요한 경우 자동화 규칙을 여러 규칙으로 분할합니다.
지라의 대량 변경 기능을 사용하여 수천 가지 이슈를 편집해야 하는 대규모 일회성 작업에 대해 설명합니다.
대기 중인 항목 서비스 제한
자동화는 규칙 처리 대기열을 사용하여 인스턴스의 규칙 실행을 관리합니다. 성능을 유지하기 위해 규칙 실행이 대기열에 저장되고 병렬로 처리되는 항목 수가 제한됩니다.
자동화 규칙 빌더는 강력하며 사용자가 대기열에 있는 항목의 수를 빠르게 늘릴 수있는 복잡한 규칙 구조를 만들 수 있습니다.
규칙이 대기열에 있는 항목 제한에 도달하면 세부 정보가 감사 로그에 기록되고 이후 실행을 방지하기 위해 규칙이 실행 중지됩니다.
어떤 종류의 규칙이 이것을 야기시킬 수 있습니까?
관련 이슈 브랜치가 많은 규칙. 각 관련 이슈 브랜치는 상당한 수의 이슈와 일치합니다.
다음 예에서는 약 13,000 개의 대기 항목이 생성됩니다.
100개의 이슈와 일치하는 스케줄링된 트리거
50개의 이슈와 일치하는 관련 이슈 브랜치
80개의 이슈와 일치하는 또 다른 관련 이슈 브랜치
여러 관련 이슈 브랜치가 있는 규칙은 조건 여부를 시뮬레이션하기 위해 대기 중인 항목도 많이 발생시킬 수 있습니다. 다음 예제에서는 브랜치 수에 따라 3,500개 이상의 항목이 생성됩니다.
트리거 : 이슈 업데이트
1000개의 이슈와 일치하는 JQL: 유형 = Bug 관련 이슈 브랜치
500개의 이슈와 일치하는 JQL: 유형 = Task 관련 이슈 브랜치
2000개의 이슈와 일치하는 JQL: 유형 = Feature 관련 이슈 브랜치
예방
트리거 또는 관련 이슈 브랜치를 통해 규칙이 가져 오는 전체 이슈 수를 줄이는 것이 좋습니다 .
대기중인 항목 서비스 제한에 도달할 위험을 줄이려면 다음 지침을 고려하십시오:
가능한 최소 이슈 집합으로 실행을 제한하는 JQL을 사용해야 합니다. 이는 다음과 같은 다양한 방법으로 달성할 수 있습니다.
JQL 검색이 가능한 한 구체적이 되도록 하십시오. 현재 진행 중인 이슈에만 관심이 있는 경우,
type = Task
유형에 맞는 이슈만 검색하지 마십시오. 이 경우 더 나은 대안은 다음과 같습니다.type = Task and status = "In Progress"
이 규칙을 마지막으로 실행한 이후 변경된 이슈만 포함 옵션을 사용합니다. 많은 규칙에서는 이 작은 하위 집합에서만 작동하는 것이 좋습니다.
조건부 확인을 위해 관련 이슈 브랜치를 생성하지 마십시오. 위의 예에서 If/else 블록 조건을 사용하여 이슈 유형을 기준으로 일치시킬 수 있습니다.
규칙에 대한 데이터 보기
개별 규칙에 대한 감사 로그를 보려면:
규칙 목록에서 세부 정보를 볼 규칙 이름을 선택
Audit log 선택
프로젝트의 감사 로그를 보려면:
데이터를 보려는 프로젝트의 규칙 목록으로 이동
••• > Show audit log 선택
글로벌 감사 로그를 보려면:
글로벌 Jira 설정의 규칙 목록으로 이동
••• > Show audit log 선택
규칙 디버그
규칙이 예상대로 작동하지 않는 경우 다음 정보가 이슈를 해결하는 데 도움이 될 수 있습니다.
1. 감사 로그 확인
감사 로그 확인은 규칙이 실패할 때 첫 번째 단계여야 합니다. 감사 로그 검토 시:
표시된 오류가 있는지 확인합니다. 오류가 있는 경우 이슈 해결 방법에 대한 제안이나 지침을 제공합니까?
Jira의 오른쪽 화면에 모든 관련 필드가 있습니까?
감사 로그의 편집 내용을 이슈 페이지의 이슈 기록 탭과 비교합니다.
항목이 없고 일부 항목이 예상된 경우 트리거를 올바르게 구성하지 않았거나 트리거에 예상대로 작동하지 않는 필터가 있습니다.
2. 스마트 값 디버깅
로그 작업 사용
로그 작업은 스마트 값을 포함하여 감사 로그에 값을 추가합니다. 이 기능은 복잡한 스마트 값 기능을 테스트할 때 유용합니다.
Log message: This should evaluate to 2: {{#=}}1 + 1{{/}}
디버그 사용
로그 작업을 사용하려면 규칙에 추가 구성 요소를 추가해야 합니다. 이 문제를 방지하려면 {{#debug}}{{issue.fields.description}}{{/}}
기능과 같은{{#debug}}
기능을 사용할 수 있습니다.
스마트 값을 디버그로 둘러싸면 스마트 값을 정상적으로 처리할 수 있으며 감사 로그에도 값을 인쇄하여 상황별 정보를 더 많이 제공합니다.
{{#debug}}{{#=}}1 + 1{{/}}{{/}}
이제 이 규칙이 실행되면 감사 로그에는 다음이 포함됩니다.
Debug message 2
3. 테스트 실행
테스트하기 전에 규칙을 복사하고 원본을 비활성화하십시오. 이렇게 하면 변경한 경우 원래 규칙으로 쉽게 되돌릴 수 있습니다.
매뉴얼 트리거를 사용하여 언제든지 이슈에서 규칙을 실행합니다.
스케쥴 트리거를 사용하고 실행을 클릭하여 테스트를 위한 규칙을 트리거합니다.
현재 시간을 이슈 필드에 포함하려면 스마트 값 {{now}}를 사용합니다. 이렇게 하면 편집한 시간과 값이 변경되었는지 확인할 수 있습니다.
자동화 성능 인사이트
자동화 성능 인사이트는 규칙이 어떻게 수행되고 있는지에 대한 전반적인 보기를 제공하여 실행 횟수와 규칙에 걸리는 시간을 볼 수 있습니다.
각 규칙 실행에 대해 다음에 대한 성능 인사이트를 볼 수 있습니다.
Execution count : 실행 횟수
Average duration : 평균 기간(초)
Total duration : 총 기간(초)
각 성능 지표는 규칙이 다음과 같은지 여부에 따라 분류됩니다.
Successful : 규칙이 액션을 수행했습니다.
No action : 규칙이 실행되었지만 액션이 수행되지 않았습니다.
Some errors : 규칙으로 인해 오류가 발생했습니다.
Loop : 규칙 실행으로 인해 실행 루프가 발생했습니다.
Throttled : 규칙이 서비스 제한을 위반했습니다.
자동화 성능 인사이트 보기
프로젝트의 성능 인사이트를 보려면 :
인사이트를 보려는 프로젝트의 규칙 목록으로 이동
••• > View performance insights 선택
인스턴스의 모든 프로젝트에 대한 성능 인사이트를 보려면 :
글로벌 관리 설정의 자동화 공간으로 이동
••• > View performance insights 선택
0 Comments