실험실

개요

다른 로그프레소 소나 인스턴스의 티켓을 이 인스턴스로 복제하는 기능입니다. 지사·고객사·망분리 구간에 흩어진 소나의 티켓을 본사 인스턴스 한 곳에서 모아 보는 용도로 사용합니다.

복제 대상은 티켓만이 아닙니다. 티켓이 근거로 삼은 탐지 이벤트와 원본 로그까지 함께 가져오므로, 복제된 티켓을 열어 "무엇을 보고 이 티켓이 생겼는지"를 그대로 확인할 수 있습니다.

시작하기 전에

양쪽 인스턴스에 실험실 앱을 설치하는 것을 권장합니다. 수집하는 쪽에만 설치해도 동작하지만, 원격에도 설치되어 있으면 변경된 티켓만 골라내는 전용 조회 명령어를 쓸 수 있어 원격 부하가 크게 줄어듭니다. 원격에 앱이 없으면 자동으로 호환 모드로 내려가며, 그때는 메모가 제한적으로만 복제됩니다(아래 "조회 방식" 참고).

원격 인스턴스에 연동 전용 계정을 하나 만들고 다음을 확인하세요.

• 다단계 인증(MFA)이 비활성이어야 합니다. 로그인 과정에 추가 단계가 있으면 접속하지 못합니다.
• 클러스터 관리자여야 합니다. 전용 조회 명령어가 클러스터 관리자 권한을 요구합니다. 일반 관리자 권한으로는 부족하며, 권한이 모자라면 진단 화면에 REMOTE_PERMISSION으로 표시됩니다.
• 탐지 규칙 조회 권한(실시간 규칙 조회 / 배치 규칙 조회)이 있으면 좋습니다. 근거 이벤트를 제대로 표시하는 데 사용됩니다(아래 "복제 전용 탐지 규칙" 참고).

1단계 — 접속 프로파일 만들기

설정 > 접속 프로파일에서 유형이 로그프레소 소나인 프로파일을 만듭니다.

저장 전에 연결 테스트로 접속과 로그인이 되는지 확인하세요.

2단계 — 매핑 만들기

실험실 > 티켓 동기화에서 추가를 누르면 오른쪽에 설정 패널이 열립니다. 위에서부터 차례로 고르면 되고, 앞 단계를 정해야 다음 단계가 채워집니다.

1. 로그프레소 소나 접속 프로파일 — 1단계에서 만든 프로파일을 고릅니다.
2. 원격 티켓 분류 — 원격 인스턴스의 티켓 분류 목록이 표시됩니다. 고르면 그 분류의 최근 티켓 20건이 미리보기로 나옵니다. 저장하기 전에 의도한 분류가 맞는지 여기서 확인하세요.
3. 로컬 티켓 분류 — 복제된 티켓이 쌓일 이 인스턴스의 분류입니다.
4. 수집 주기 — 기본 5초입니다.
5. 수집 대기 — 기본 0초. 아래 참고.
6. 동기화 항목 — 항목별로 무엇을 어디까지 따라갈지 정합니다. 아래 참고.
7. 동기화 활성화 — 켠 상태로 저장하면 바로 수집이 시작됩니다.

기존 매핑을 수정할 때 접속 프로파일과 원격 티켓 분류는 바꿀 수 없습니다. 이미 수집 중인 동기화를 말없이 다른 대상으로 돌리지 않기 위해서입니다. 대상을 바꾸려면 매핑을 지우고 새로 만드세요.

수집 대기

마지막 변경 후 이만큼 지난 티켓만 가져옵니다. 기본값은 0초이고, 설정 화면은 60초를 권장값으로 안내합니다.

사람이 티켓 하나를 정리하는 동안 보통 여러 번 저장이 일어납니다. 대기가 없으면 폴링이 그 중간에 내려앉아 미완성 상태를 복제했다가 다음 회차에 다시 고칩니다. 원격이 근거 이벤트를 저장소에 올리기 전에 티켓만 먼저 가져가는 것도 막아 줍니다.

반영까지 걸리는 시간은 수집 주기 + 수집 대기가 됩니다. 호환 모드(msgbus)에서는 적용되지 않습니다.

동기화 항목

원격을 그대로 따라가는 것이 늘 옳지는 않습니다. 복제된 티켓을 여기서 분석가가 재분류하거나 종료했다면, 다음 회차에 원격 값이 되돌아오면 곤란합니다. 그래서 항목마다 세 가지 중에서 고릅니다.

제목과 본문·중요도·종료 여부·건수와 이벤트 시각은 최초 복제에서 뺄 수 없습니다. 티켓을 만드는 데 반드시 필요한 값이라 가져오지 않음이 제시되지 않습니다.

"원본 이벤트"는 "근거 이벤트"에 의존합니다. 근거 이벤트를 끄면 원본도 복제되지 않습니다. 원본만 켜는 조합은 의미가 없습니다. 저장소 부담을 줄이려면 원본 이벤트만 끄세요.

현재 근거 이벤트·원본 이벤트·메모에서는 최초 1회만과 계속 동기화가 같게 동작합니다. 구분이 필요하면 가져오지 않음만 의미가 있습니다.

목록 화면 읽기

마지막 두 열은 서로 다른 질문에 답합니다. 앞은 "언제 돌았나", 뒤는 "어디까지 가져왔나"입니다. 원격이 조용하면 앞은 계속 갱신되지만 뒤는 멈춰 있습니다. 둘 다 과거에 멈춰 있으면 수집 자체가 동작하지 않는 것이니 상태 인디케이터를 확인하세요.

분류 이름에 마우스를 올리면 GUID가 툴팁으로 보이고, 옆의 복사 버튼으로 클립보드에 담을 수 있습니다.

상태 인디케이터

수집기 목록과 같은 규칙입니다.

오류일 때만 클릭할 수 있습니다. 진단 대화상자에는 오류 분류·상세 메시지·발생 시각·마지막 성공 시각·동기화 기준점·조회 방식이 표시되고, 분류별 권장 조치가 함께 나옵니다. 여기서 지금 동기화로 즉시 재시도하거나 초기화로 수집 시점을 바꿀 수 있습니다.

수집 시점 초기화

과거 티켓을 가져오는 유일한 방법이고, 수집이 멈춰 있을 때 되살리는 방법이기도 합니다. 목록의 초기화 버튼 또는 진단 대화상자에서 엽니다.

달력에서 시작할 시점을 고르면 다음 회차부터 그 시점을 기준으로 수집하고, 오류와 마지막 동기화 기록, 조회 방식을 지웁니다. 미래 시각은 지정할 수 없습니다.

• 진행 중이던 회차는 중단됩니다. 그대로 두면 옛 기준으로 끝나면서 방금 지정한 시점을 덮어쓰기 때문입니다.

• 시점을 멀리 잡을수록 그 다음 회차가 길어집니다. 몇 달 전으로 되돌리면 첫 회차에 시간이 걸리고, 그동안 해당 매핑의 다음 회차는 시작되지 않습니다.

무엇이 복제되는가

복제되는 것

• 티켓 본문 — 제목, 내용, 형식, 중요도, 상태, 공격 여부, 사고 여부, 건수, 발생·이벤트 시각, 출처 정보, 생성·변경 시각
• 상태 전이 — 원격에서 종료하면 로컬도 종료되고, 재오픈하면 로컬도 재오픈됩니다
• 근거 이벤트와 원본 로그 — 건수 제한이 없습니다
• 메모 — 아래 "메모 복제" 참고
• GUID — 원격과 같은 GUID로 복제됩니다. 두 인스턴스가 같은 티켓을 같은 식별자로 가리킵니다

복제되지 않는 것

메모 복제

메모는 티켓과 별개의 기준점으로 수집합니다. 메모를 달아도 티켓의 변경 시각은 움직이지 않기 때문에, 티켓 기준으로만 보면 영원히 잡히지 않습니다.

• 작성자는 옮길 수 없습니다. 복제된 메모의 작성자는 연동 계정이고, 원본 작성자는 본문 앞에 [이름] 형태로 표기됩니다.
• 원격에서 메모를 수정하면 복제본도 따라 수정됩니다. 삭제는 따라가지 않습니다.
• 복제된 티켓의 메모만 들어옵니다. 아직 복제되지 않은 티켓에 달린 메모는 붙일 곳이 없어 건너뜁니다. 그 메모까지 필요하면 티켓이 복제될 만큼 수집 시점을 과거로 되돌리세요.
• 호환 모드(msgbus)에서는 티켓이 다른 이유로 변경될 때 딸려오는 메모만 들어옵니다.

복제 전용 탐지 규칙

동기화를 시작하면 탐지 규칙 목록에 비활성 규칙이 자동으로 생성됩니다. 이름은 원본 규칙 이름 (접속 프로파일 이름) 형태입니다. 실시간 규칙과 배치 규칙 모두 만들어집니다.

이것은 복제된 근거 이벤트를 화면에 보이게 하기 위한 자리표시자입니다. 소나는 이벤트를 조회할 때 "그 이벤트를 만든 탐지 규칙을 볼 권한이 있는가"를 함께 검사하는데, 복제된 이벤트가 달고 온 원격 규칙 번호는 이 인스턴스에 존재하지 않아 그대로 두면 아무에게도 보이지 않습니다.

• 항상 비활성입니다. 탐지를 수행하지 않고, 쿼리도 동작하지 않습니다.
• 매핑의 로컬 티켓 분류에 묶입니다. 그 분류를 볼 수 있는 사람만 근거 이벤트를 볼 수 있다는 뜻이고, 티켓 권한과 근거 권한이 어긋나지 않습니다.
• 원본 탐지 쿼리는 주석 형태로 보존됩니다. 복제된 티켓을 조사할 때 원격에서 어떤 로직이 탐지했는지 읽을 수 있습니다.

자동 생성되는 인덱스

앱을 설치하면 기동할 때 코어 테이블 두 곳에 인덱스를 만듭니다. 매핑이 하나도 없어도 생성됩니다.

코어 티켓 테이블에는 updated_at 인덱스가 없어, 이 인덱스가 없으면 증분 조회 비용이 변경 건수가 아니라 해당 분류의 전체 티켓 수에 비례합니다. 5초 주기로 치르기에는 큰 비용입니다.

이 인덱스가 필요한 쪽은 티켓을 읽히는 인스턴스(원격)인데, 그쪽에는 매핑이 없습니다. 그래서 매핑 유무를 보지 않고 생성합니다.

동작은 이렇습니다.

• 같은 역할의 인덱스가 이미 있으면 건너뜁니다. 이름이 아니라 repo_id가 첫 번째, updated_at이 두 번째인 인덱스가 있는지를 봅니다. 코어가 나중에 같은 인덱스를 다른 이름으로 추가해도 중복이 생기지 않습니다.
• 전용 백그라운드 스레드에서 만듭니다. 티켓이 수백만 건이면 수 분이 걸릴 수 있지만 동기화가 그 뒤에 줄 서지 않고, InnoDB가 온라인으로 추가하므로 그동안에도 인스턴스는 정상 동작합니다.
• 실패해도 동기화는 그대로 돕니다. 계정에 DDL 권한이 없으면 경고 한 줄만 남습니다. 속도만 잃고 정확성은 잃지 않습니다.

생성 여부는 로그에서 확인할 수 있습니다.

experimental: creating index IX_sonar_tickets_repo_id_updated on sonar_tickets, this may take a while on a large ticket table
experimental: created index IX_sonar_tickets_repo_id_updated in 1234 ms
experimental: cannot create index IX_sonar_tickets_repo_id_updated on sonar_tickets, incremental ticket queries will scan the repository: ...

직접 확인하려면:

SHOW INDEX FROM sonar_tickets        WHERE Key_name = 'IX_sonar_tickets_repo_id_updated';
SHOW INDEX FROM sonar_ticket_comments WHERE Key_name = 'IX_sonar_ticket_comments_repo_id_updated';

조회 방식

진단 대화상자의 "조회 방식" 항목에 둘 중 하나가 표시됩니다.

호환 모드에서는 두 가지가 제한됩니다. 수집 대기가 적용되지 않고, 메모가 티켓 변경에 딸려올 때만 들어옵니다.

원격에 앱을 설치하면 다음 회차부터 자동으로 query로 올라갑니다. 즉시 바꾸려면 초기화하세요.

문제 해결

진단 대화상자의 오류 분류를 먼저 보세요.

티켓은 들어오는데 근거자료가 비어 있을 때

가장 흔한 원인은 복제 전용 탐지 규칙이 만들어지지 않은 것입니다. 이 경우 이벤트는 저장소에 정상적으로 적재되어 있는데 조회에서만 걸러지므로, 오류도 로그도 남지 않습니다.

순서대로 확인하세요.

1. 진단 대화상자에 오류가 있는지 먼저 봅니다. 근거 적재 자체가 실패하면 그 회차 전체가 실패로 기록됩니다.
2. 탐지 규칙 목록에 원본 이름 (프로파일 이름) 형태의 비활성 규칙이 있는지 확인합니다. 하나도 없으면 그 매핑의 근거는 전부 보이지 않는 상태입니다.
3. 연동 계정에 탐지 규칙 조회 권한이 있는지 확인합니다. 권한이 없으면 자리표시자를 제대로 만들지 못합니다.
4. 동기화 항목에서 "건수와 이벤트 시각"이 최초 1회만으로 되어 있지 않은지 확인합니다 (위 경고 참고).
5. 원격에서 해당 이벤트가 아직 보존 기간 안에 있는지 확인합니다. 이미 삭제된 이벤트는 가져올 수 없습니다.

근거자료가 회차마다 일부만 들어올 때

원격이 이중화되어 있고 접속 프로파일이 VIP를 가리키는 경우입니다. 티켓은 두 노드가 공유하는 데이터베이스에서 오지만 근거 이벤트는 각 노드의 로그 저장소에서 오기 때문에, 회차마다 응답하는 노드가 달라지면 그 노드가 가진 만큼만 복제됩니다.

프로파일 주소를 노드 하나로 고정하세요. 양쪽 노드의 근거가 모두 필요하면 노드마다 매핑을 따로 두고 같은 로컬 분류로 모으면 됩니다.

특정 티켓이 들어오지 않을 때

수집 기준은 티켓의 변경 시각입니다. 생성 시각이 아닙니다. 원격에서 오래전에 만들어졌지만 최근에 갱신된 티켓은 들어오고, 반대로 "마지막 티켓 시각"보다 변경 시각이 이른 티켓은 들어오지 않습니다. 필요하면 초기화로 기준점을 그 티켓의 변경 시각 이전으로 되돌리세요.

제약사항

• 연동 계정은 다단계 인증을 사용할 수 없고, 원격의 클러스터 관리자여야 합니다.
• HTTP 프록시를 경유한 접속은 지원하지 않습니다. 수집 측에서 원격 인스턴스로 직접 연결할 수 있어야 합니다.
• 티켓 삭제와 메모 삭제는 동기화되지 않습니다.
• 담당자·결재자·첨부파일·태그·규칙 참조는 복제되지 않습니다.
• 매핑을 삭제해도 이미 복제된 티켓과 이벤트는 남습니다.
• 같은 원격 분류를 두 개의 매핑에 연결할 수 없습니다. 두 수집기가 같은 티켓을 쓰게 되기 때문입니다.
• 앱을 설치하면 티켓 테이블과 메모 테이블에 조회용 인덱스가 자동으로 생성됩니다 (위 "자동 생성되는 인덱스").