Jira 클러스터 모니터링

Owned by 이병욱
2021-01-06
5 min read

클러스터된 노드 보기

클러스터된 노드에 대한 정보를 보려면  > 시스템> 클러스터링으로 이동.


노드의 상태 및 상태 모니터링

  • active : 노드가 활성 상태이고 하트비트가 있습니다.

active 노드가 offline으로 플래그가 지정되면 Jira는 클러스터가 손상될 가능성을 방지하기 위해 자동으로 종료됩니다. 이것은 공식적으로 권장되는 지라 클러스터를 종료하는 방법이 아닙니다. jira.cluster.node.self.self.if.disabled.true 속성을 사용하여 이 기능을 비활성화할 수 있습니다.

  • no heartbeat : 노드가 일시적으로 중단되었거나 중단되었거나 활성 상태이지만 실패합니다. 이 상태는 자동 배포로 인해 발생할 수 있습니다. 서버가 시작되고 하트비트 없음 상태가 일시적일 수도 있습니다. 일반적으로 5분 동안 하트비트가 없는 것으로 보고되면 노드가 이 상태로 이동합니다. 노드가 실제로 중단되었는지 확인하고 재시작할지 여부를 결정하거나 REST API를 통해 즉시 제거할 수 있습니다.

노드가 갑자기 중지된 경우에도 상태를 하트비트 없음으로 변경하기 전에 약 5분 동안 활성 상태로 표시될 수 있습니다.

기본적으로 하트비트 없음 상태를 보고한 후 이틀 후에 노드가 자동으로 오프라인으로 이동합니다. 그러나 jira.not.alive.active.nodes.retention.period.in.hours을 수정하여 기본값을 변경할 수 있습니다. 또는 Jira startup에서 JVM 플래그를 추가할 수 있습니다. 예를 들어 3시간 후에 노드를 오프라인으로 전환하려면 다음 플래그를 입력하십시오.

Djira.not.alive.active.nodes.retention.period.in.hours=3

jira.not.alive.active.nodes.retention.period.in.hours의 값은 Jira 인스턴스 시작 시간보다 커야 합니다. 그렇지 않으면 클러스터의 다른 노드가 노드를 offline 상태로 이동할 수 있습니다.

  • offline : 노드를 수동으로 수정하거나 중지하고 오프라인으로 이동합니다. 클러스터 작업을 실행하는데 노드를 사용하면 안 됩니다. 오프라인으로 이동하면 노드는 이틀 후 클러스터에서 자동으로 제거됩니다.

적용여부

응답은 서버 측에서 매 분마다 새로 고쳐집니다. 페이지를 새로 고쳐서 최신 데이터를 가져옵니다. 노드가 오프라인 상태이거나 하트비트가 없는 경우 애플리케이션 상태 열에 데이터가 포함되지 않습니다.

MAINTENANCE : 노드의 지라가 다시 인덱싱되고 있으며 현재 사용자를 지원할 수 없습니다.

ERROR : 시작 시 문제가 발생하여 Jira가 이 노드에서 실행되고 있지 않습니다. 데이터베이스에 연결하지 못했거나 잠금 파일이 있는 등의 여러 가지 이유로 인해 오류가 발생했을 수 있습니다. 자세한 내용은 로그 파일을 확인하십시오.

RUNNING : 노드가 작동 중이고 Jira가 작동 중입니다.

STARTING : Jira와 함께 노드가 시작됩니다.

감사 로그의 클러스터 정보

클러스터를 관리하기 위해 감사 로그에서 클러스터를 종료하거나 클러스터에 가입하는 노드에 대한 정보도 찾을 수 있습니다. 글로벌 구성 및 관리 범위 영역의 전체 수준을 선택하면 이벤트가 기록됩니다.

  1. > System > Advanced audit log로 이동

  2. "Clustering" 키워드로 기록된 클러스터 관련 이벤트를 검색

다음 이벤트를 기록합니다.

  •  - NodeJoined - 새 노드가 클러스터에 가입되었습니다.

  •  - NodeReJoined - 기존 노드가 다시 시작되어 클러스터에 다시 가입되었습니다.

  •  - NodeLeft - 노드가 offline 상태를 수신하였습니다.

  •  - NodeRemoved - 클러스터에서 노드가 제거되었습니다.

  •  - NodeUpdated - 기존 노드를 업데이트한 다른 모든 사례

런타임 및 시스템 정보 보기

드릴다운하여 런타임 및 시스템 정보를 보려면 특정 노드에 대한 액션을 클릭합니다.

인덱싱하는 데 가장 오래 걸리는 사용자 지정 필드 보기

인덱싱 성능이 갑자기 저하되는 경우 사용자 지정 필드를 인덱싱하는데 시간이 오래 걸리기 때문일 수 있습니다. 일반적으로 재색인 시간은 고르게 분포되지 않으며 대부분의 인덱싱 시간을 차지하는 여러 필드가 있습니다.

인덱싱하는데 가장 오래 걸릴 수 있는 사용자 지정 필드를 확인하려면 로그에서 메트릭(Jira 8.1 이상에서 사용 가능)을 조회하거나 작업 > 사용자 지정 필드 인덱싱을 클릭하여 UI에서 이 데이터를 볼 수 있습니다. 페이지에 가장 많은 시간이 소요되는 사용자 지정 필드 20개가 표시됩니다(총 10개 및 스냅샷 기간 10개).

인덱싱 시간의 대부분을 사용자 지정 필드가 차지하는 정보를 통해 성능을 향상시키기 위한 작업을 수행할 수 있습니다. 사용자 정의 필드의 구성을 변경하거나 가능하면 사용자 정의 필드 인덱서 자체를 개선할 수 있습니다. 비즈니스에 중요하지 않고 시스템 사용자 지정 필드가 아닌 사용자 지정 필드인 경우 테스트 환경에서 해당 필드를 제거하고 인덱싱 시간을 얼마나 단축할 수 있는지 확인할 수 있습니다.

메트릭 분석을 위한 모범 사례

구성 변경을 도입하거나 테스트 환경에서 시스템을 변경할 때마다 이러한 메트릭을 참조하는 것이 좋습니다. 보고서를 분석하려는 경우 다음 모범 사례를 고려하십시오.

신뢰할 수 있는 데이터를 얻으려면 전체 배경 재색인이 완료된 후 보고서를 보는 것이 좋습니다.

인스턴스의 이슈 수보다 인덱서 호출이 더 많은 보고서는 최고 품질의 데이터이므로 분석하는 것이 좋습니다.

변경 사항을 적용하기 전에 스냅샷 섹션의 최대 인덱싱 시간 열에 있는 값을 확인하십시오. 점수가 높은 사용자 지정 필드(예: 5000밀리초 - 5초 이상)는 인덱스에서 가장 비싼 경향이 있는 필드입니다.

성능 데이터 분석

테이블에는 인덱싱 또는 재색인하는데 가장 오래 걸리는 사용자 지정 필드(총계는 10개, 스냅샷은 10개)가 표시됩니다. 데이터는 노드별로 표시되므로 클러스터링 페이지에서 선택하는 노드에 따라 다를 수 있습니다. 데이터는 백그라운드에서 5분마다 새로 고쳐집니다. 타임스탬프를 참조하여 시스템에서 마지막 인덱스 데이터 업데이트를 보낸 시간을 확인할 수 있습니다.

데이터는 전체 및 스냅샷 섹션의 가장 시간이 많이 걸리는 사용자 지정 필드부터 인덱싱 비용별로 정렬됩니다.

표에는 다음 데이터가 포함되어 있습니다.

기간: 데이터를 표시할 기간을 설정합니다. 총계는 마지막 전체 재색인 또는 지라의 시작 시간(이 시간 이후 전체 재색인이 없는 경우)입니다. 스냅샷은 5분 시간 프레임(마지막 스냅샷으로부터의 시간)을 제공합니다.

사용자 정의 필드 이름: JQL에서 사용되는 사용자 정의 필드의 이름입니다.

사용자 지정 필드 유형:

  • 시스템은 시스템에서 사용하는 사용자 지정 필드입니다. 구성 또는 인덱싱 시간을 변경할 수 없습니다.

  • 타사 앱은 사용하는 타사 앱에서 제공하는 사용자 지정 필드입니다. 인덱싱하는 데 시간이 오래 걸리는 경우 구성을 변경하거나 공급업체에 문의하여 사용자 지정 필드 인덱서를 개선할 수 있습니다.

  • 사용자 지정은 인스턴스에 생성된 사용자 지정 필드입니다. 인덱싱하는 데 시간이 오래 걸리는 경우 구성을 변경하거나 사용자 지정 필드 인덱서를 개선할 수 있습니다.

인덱싱 시간의 백분율: 지정된 사용자 지정 필드를 인덱싱하거나 다시 생성하는 데 걸린 시간의 백분율입니다. 사용자 정의 필드가 인덱싱 시간에 어떤 영향을 미치는지 보여줍니다.

최대 인덱싱 시간(ms): 지정된 사용자 지정 필드를 인덱싱하거나 다시 인덱싱하는 데 걸린 최대 시간입니다.

평균 인덱싱 시간(ms): 지정된 사용자 지정 필드를 인덱싱하거나 다시 인덱싱하는 데 걸린 평균 시간입니다. 인덱서에 대한 모든 호출의 합을 해당 호출의 수로 나눈 값(밀리초)입니다.

인덱서에 대한 호출: 지정된 사용자 지정 필드를 다시 인덱싱하기 위해 사용자 지정 필드 인덱서를 한 기간에 호출한 횟수입니다.

추가분석

더 많은 통찰력을 얻기 위해 로그(Jira 8.1 이상에서 사용 가능)를 분석할 수도 있습니다.

  1. atlassian/application-data/jira/log/atlassian-jira.log로 이동합니다.

  2. grep indexing-stats 사용하여 데이터를 찾습니다. 다음과 같이 보일 수 있습니다.

일반 로그 항목:

{field: epic, addIndex: {sum/allSum:38.5%, sum:1285825ms, avg:30.1ms, max:3822ms, count:42717}},

로그 항목을 다시 인덱싱하는 중:

위치:

order - 인덱스/재인덱스된 필드는 인덱스/재인덱스하는데 걸린 시간에 따라 표시됩니다.

sum/allSum - 사용자 지정 필드/모든 사용자 지정 필드를 인덱싱하는데 걸린 시간의 백분율입니다.

addIndex sum/avg/max/count - 사용자 정의 필드 인덱싱에 걸린 총 시간/사용자 정의 필드 인덱싱에 걸린 평균 시간/사용자 정의 필드를 인덱싱하는데 걸린 최대 시간/인덱서로 호출하는데 걸린 최대 시간입니다.

totalIndexTime - 총 인덱싱/재색인 시간입니다.

addIndexSum/totalIndexTime - 총 인덱싱/재색인 시간 대비 이 필드의 인덱싱/재색인 비용(시간 단위)입니다.

numberOfIndexingThreads - 인덱싱 스레드 수 입니다.