docker load -i sysmaster-db-{version}.tar
podman load -i sysmaster-db-{version}.tar
수집 모듈(TPM Agent)이 접속할 포트 번호
\[참고] 관제 DB에서 접속할 수 있도록 SysMasterDB 서버에서 열려 있어야 함
| 8292 | | METADB\_PORT | Meta DB의 접속 포트 번호 | 25432 | | METADB\_USER | SysMasterDB가 Meta DB에 접속할 때 사용하는 사용자 이름. meta.conf의 pg\_users에 있는 name과 같아야 한다 | sysmaster | | METADB\_PASSWORD | SysMasterDB가 Meta DB에 접속할 때 사용하는 사용자 암호. meta.conf의 pg\_users에 있는 pass와 같아야 한다 | sysmaster | | METADB\_PATH | Meta DB의 데이터 파일 경로 | ./meta | | METADB\_CONF\_PATH | Meta DB의 설정 파일 경로 | ./meta.conf | | REPODB\_PORT | Repository DB의 접속 포트 번호 | 15432 | | REPODB\_USER | SysMasterDB가 Repository DB에 접속할 때 사용하는 사용자 이름. repo.conf의 pg\_users에 있는 name과 같아야 한다 | sysmaster | | REPODB\_PASSWORD | SysMasterDB가 Repository DB에 접속할 때 사용하는 사용자 암호. repo.conf의 pg\_users에 있는 pass와 같아야 한다 | sysmaster | | REPODB\_PATH | Repository DB의 데이터 파일 경로 | ./repo | | REPODB\_CONF\_PATH | Repository DB의 설정 파일 경로 | ./repo.conf | | RETENTION\_DAY | 수집 정보의 보관 주기 | 7 | | LOG\_PATH | 로그 생성 위치 | ./logs | | LOG\_RETENTION\_DAY | 로그 파일 보관 주기 | 30 | | LOG\_FILE\_SIZE | 로그 파일 하나의 최대 크기 | 20MB | | LOG\_TOTAL\_SIZE | 모듈 별 최대 로그 저장 용량 | 1GB | | LOG\_LEVEL | 모듈 별 로그 레벨 | info | | REPORT\_PATH | TPR 리포트·ASH 리포트 파일이 저장되는 호스트 경로 | ./reports | | CONTAINER\_LOG\_PATH | 컨테이너 내부 로그 경로 설정 | /sysmaster/logs | | KAFKA\_MESSAGE\_MAX\_BYTES |카프카 메시지 사이즈 설정,
1MB \~ 2GB 범위로 설정 가능
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4이다.
\[참고] 현재 docker 기본 이미지는 eclipse-temurin:17-jdk-alpine이다.
| | SDM\_HEAP\_SIZE\_MIN | SDM의 최소 힙 크기 |현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64이다.
\[참고] 현재 docker 기본 이미지는 eclipse-temurin:17-jdk-alpine이다.
| | ANALYZER\_HEAP\_SIZE\_MAX | Analyzer의 최대 힙 크기 |현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4이다.
\[참고] 현재 docker 기본 이미지는 eclipse-temurin:17-jdk-alpine이다.
| | ANALYZER\_HEAP\_SIZE\_MIN | Analyzer의 최소 힙 크기 |현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64이다.
\[참고] 현재 docker 기본 이미지는 eclipse-temurin:17-jdk-alpine이다.
| | COLLECTOR\_HEAP\_SIZE\_MAX | Collector의 최대 힙 크기 |현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4이다.
\[참고] 현재 docker 기본 이미지는 eclipse-temurin:17-jdk-alpine이다.
| | COLLECTOR\_HEAP\_SIZE\_MIN | Collector의 최소 힙 크기 |현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64이다.
\[참고] 현재 docker 기본 이미지는 eclipse-temurin:17-jdk-alpine이다.
| | COLLECTOR\_AGENT\_HEARTBEAT\_TIMEOUT\_MS | TPM Agent로부터 메시지를 받지 못해도 연결을 유지하는 허용 시간(ms). Agent의 최대 수집 주기보다 넉넉하게 설정한다. | 300000 | | DBMANAGER\_HEAP\_SIZE\_MAX | DBManager의 최대 힙 크기 |현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4이다.
\[참고] 현재 docker 기본 이미지는 eclipse-temurin:17-jdk-alpine이다.
| | DBMANAGER\_HEAP\_SIZE\_MIN | DBManager의 최소 힙 크기 |현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64이다.
\[참고] 현재 docker 기본 이미지는 eclipse-temurin:17-jdk-alpine이다.
| | PERFORMANCE\_LOGGING |성능 관련 로그 작성 여부(.env에 기본 포함되지 않으며, 필요 시 추가한다)
\[참고] 추가적인 CPU, Disk를 사용하는 것이기 때문에 Y로 설정 시 성능 저하가 발생할 수 있음.
100만개
\[참고] 총 약 <등록된 인스턴스 개수> \* 300MB 메모리를 차지한다.
장기 미사용 계정 잠금
마지막으로 사용한 뒤 이 기간(일)이 지나면 로그인, 토큰 재발급, 역할 변경을 막는다.
0 이하면 기능을 끈다.
Refresh Token 유효기간
0 이하면 별도로 지정하지 않은 것으로 본다. 장기 미사용 잠금이 켜져 있으면 옵션과 무관하게 상한이 잠금 기간까지 맞춰진다.
이전 비밀번호 재사용 금지
비밀번호를 바꿀 때 직전 N개와 같은 값으로는 바꿀 수 없다.
1\~24로 설정 가능하다.
비밀번호 주기적 변경 안내
마지막으로 비밀번호를 바꾼 뒤(값이 없으면 계정을 만든 뒤) 이 기간이 지나면 로그인 응답으로 변경을 안내한다.
0 이하면 기능을 끈다.
계정당 동시 세션 수
유휴 세션 자동 로그오프(분)
0 이하면 기능을 끈다.
허용IP 외 접속차단서비스
super admin의 허용 IP
super admin의 허용 IP는 이 값으로만 정한다. IP는 1개만 지정 가능하다.
프록시 대역
사내 PC 대역(10.0.0.0/8, 192.168.0.0/16 등)은 넣으면 안 된다. 그 대역의 PC가 헤더를 위조해 IP 제한을 피할 수 있다.
| 172.16.0.0/12, 10.88.0.0/15 | | ACCESS\_LOG\_RETENTION\_DAY |이벤트 로그 보관 기간(일)
ACCESS\_LOG ( 로그인/ 로그아웃 로그) 보관 기간을 설정한다.
0 이하면 기록, 보관, 삭제 정책이 모두 멈춘다. 이미 쌓인 데이터는 그대로 둔다.
| 365 | {% hint style="info" %} **참고 1** **SKIP\_DB\_USER\_COUNT\_MIGRATION\_PATCH, SKIP\_DAILY\_SEGMENT\_MIGRATION\_PATCH** 파라미터는 신규 설치 시에는 필요하지 않고, **SysMasterDB v8.1.2 이하 기설치 환경**에서 **버전 업데이트를 수행하는 경우에만 적용**이 필요하다. 각 파라미터를 별도로 설정하지 않으면, 버전 업데이트 시 해당 패치가 자동으로 수행되면서 기수집 데이터를 기반으로 **DB\_USER\_COUNT**, **DAILY\_SEGMENT** 데이터를 생성한다. 이때, 기수집 데이터양에 따라 패치 수행에 **장시간 소요**될 수 있으므로, 해당 파라미터를 통해 사용자가 **선택적으로 해당 패치 수행 여부를 설정**할 수 있다. **v8.1.3 이상의 SysMasterDB** 서비스 이용 시, **DB\_USER\_COUNT**, **DAILY\_SEGMENT** 데이터는 각각 다음 메뉴에서 사용된다. 1\. **DB\_USER\_COUNT** 데이터 - **Analysis > All Session Flow 메뉴** 2\. **DAILY\_SEGMENT** 데이터 - **Analysis > Segment Usage 메뉴** 따라서 해당 패치를 생략하도록 설정(각 파라미터를 **true**로 설정하고 **주석 제거**)하는 경우, **위 1, 2의 메뉴**에서 **과거(해당 업데이트 이전에 수집된) 데이터가 조회되지 않는다**. 그러므로 기본적으로는 해당 파라미터를 **별도로 설정하지 않는 것을 권장**한다. 반면 다음과 같은 경우, 사용자는 해당 파라미터를 **true**로 설정(**주석 제거**)하여 앞서 설명한 패치를 생략할 수 있다. 1. **위 1, 2의 메뉴**에서 과거(**SysMasterDB v8.1.2 이하**에서 수집된) 데이터 조회가 불필요한 경우 2. (SysMasterDB 서버 자원 제한 등의 이유로) 해당 데이터 생성 패치 진행 시 **장시간 SysMasterDB 사용이 불가능**해지는 상황이 우려되고, 이를 방지해야만 하는 경우 사용자는 필요에 따라, 해당 두 파라미터 중 **원하는 파라미터만 선택적으로 설정**하는 것도 가능하다. {% endhint %} {% hint style="info" %} **참고 2** **SKIP\_V8\_2\_1\_TO\_V8\_3\_0\_MIGRATION\_PATCH**, **RETENTION\_DAY\_FOR\_V8\_2\_1\_TO\_V8\_3\_0\_MIGRATION\_PATCH** 파라미터는 신규 설치 시에는 필요하지 않고, **SysMasterDB v8.2.1 이하 기설치 환경**에서 **버전 업데이트를 수행하는 경우에만 적용**이 필요하다. 각 파라미터를 별도로 설정하지 않으면, v8.3.0에서 신규 스키마가 적용된 테이블을 대상으로 **v8.2.1 이하 버전에서의 기수집 데이터를 마이그레이션**하는 패치가 자동으로 수행된다. v8.3.0에서 신규 스키마가 적용된 테이블 목록은 다음과 같다. * SQL * SQL\_TEXT * SQL\_PLAN * DB\_SESSION * SESSION\_TEMP * SESSION\_UNDO * LOCK * SQL\_TRACE 위 테이블에 대한 마이그레이션 과정은 기수집 데이터양에 따라 **장시간 소요**될 수 있다. 사용자는 필요에 따라, 다음과 같이 **별도 파라미터 설정을 통해 사용자가 선택적으로 해당 패치 수행 여부를 설정**할 수 있다. * **SKIP\_V8\_2\_1\_TO\_V8\_3\_0\_MIGRATION\_PATCH** * v8.3.0에서 신규 스키마가 적용된 테이블에 대해 v8.2.1 이하 기수집 데이터를 마이그레이션하는 패치 수행 여부를 설정 * **SKIP\_V8\_2\_1\_TO\_V8\_3\_0\_MIGRATION\_PATCH** 파라미터를 **true**로 설정(**주석 제거**) 시, 패치 대상 테이블 전체에 대한 마이그레이션이 수행되지 않음. **SKIP\_V8\_2\_1\_TO\_V8\_3\_0\_MIGRATION\_PATCH** 설정을 통해 마이그레이션을 수행하지 않은 경우, v8.2.1 이하에서 수집된 데이터가 삭제되므로 더 이상 조회되지 않는다. 그러므로 기본적으로는 해당 파라미터를 별도로 설정하지 않는 것을 권장한다. 반면 다음과 같은 경우, 사용자는 해당 마이그레이션 생략을 고려할 수 있다. 1. **v8.3.0에서 신규 스키마 적용 대상 테이블**의 과거(**SysMasterDB v8.2.1 이하**에서 수집된) 데이터 조회가 **불필요**한 경우 2. (SysMasterDB 서버 자원 제한 등의 이유로) 해당 데이터 생성 패치 진행 시 **장시간 SysMasterDB 사용이 불가능**해지는 상황이 우려되고, 이를 방지해야만 하는 경우 이때, 사용자는 아래 파라미터 설정을 통해 (마이그레이션 패치를 수행하되,) 패치 수행 대상 데이터 범위(일 단위 기간)를 별도로 설정할 수도 있다. * **RETENTION\_DAY\_FOR\_V8\_2\_1\_TO\_V8\_3\_0\_MIGRATION\_PATCH** * v8.3.0에서 신규 스키마가 적용된 테이블에 대한 v8.2.1 이하 기수집 데이터 중 마이그레이션 대상 데이터 범위(일 단위 기간) 설정 * 예를 들어, **RETENTION\_DAY\_FOR\_V8\_2\_1\_TO\_V8\_3\_0\_MIGRATION\_PATCH** 파라미터를 **7**로 설정(**주석 제거**)하는 경우, v8.2.1 이하에서 수집된 데이터 중 **최근 7일 이내의 데이터에 대해서만 마이그레이션**이 수행됨. * **SKIP\_V8\_2\_1\_TO\_V8\_3\_0\_MIGRATION\_PATCH** 파라미터를 **true**로 설정(**주석 제거**)한 경우, 본 파라미터 설정은 무시됨. 상기 설명을 참고하여, 사용자는 운영 환경에 맞는 적절한 파라미터 설정을 선택, 적용할 수 있다. {% endhint %} ### 3.1 Podman 환경에서 DNS Resolver 설정 Rootless podman 환경에서는 NGINX\_RESOLVER 패러미터 설정이 별도로 필요하다. 이는 SysMasterDB 기동 후 개별 컨테이너가 재기동 되는 상황에서의 재연결을 위해 필요하며 sysmaster 네트워크의 gateway ip 주소를 사용한다. 해당 값은 환경 / podman 기동마다 달라질 수 있다. 아래 예시에서 NGINX\_RESOLVER=10.89.0.1로 설정 후 SysMasterDB를 부팅하는 과정을 보여준다. 네트워크 이름은 '<설치 디렉터리 이름>\_sysmaster'이며, 예시는 설치 디렉터리가 script인 경우이다. {% code collapsedlinecount="10" %} ``` [tibero@smdb-podman ~]$ podman compose up --no-start [tibero@smdb-podman ~]$ podman network inspect script_sysmaster [ { "name": "script_sysmaster", "id": "e014d8811e9b51f417d578358ab41e2624a465d9026c7916f9ba7e4ce382f699", "driver": "bridge", "network_interface": "cni-podman1", "created": "2025-08-04T22:55:11.345378476-04:00", "subnets": [ { "subnet": "10.89.0.0/24", "gateway": "10.89.0.1" /// -> 이 주소를 사용. } ], "ipv6_enabled": false, "internal": false, "dns_enabled": true, "labels": { "com.docker.compose.project": "script", "io.podman.compose.project": "script" }, "ipam_options": { "driver": "host-local" } } ] /// .env 파일에 패러미터 설정하기 [tibero@smdb-podman ~]$ podman compose up -d ``` {% endcode %} ### 3.2 Podman 환경에서 SysMasterDB 서버와 동일 호스트에 설치된 관제 DB 등록 Podman bridge 네트워크 환경에서 SysMasterDB 컨테이너가 동일 호스트에 설치된 관제 DB에 호스트 IP(예: 192.168.141.12) 로 접속을 시도할 경우, 컨테이너 → 호스트 방향의 **Hairpin NAT(DNAT loopback)** 가 기본적으로 보장되지 않아 **Connection Refused**가 발생할 수 있다. 이는 동일 서버 내 구성이라도 컨테이너와 호스트가 서로 다른 네트워크 네임스페이스에 존재하기 때문에 발생하는 Podman bridge 구조적 제약이다. 예시로, 컨테이너에 접속하여 `telnet 192.168.141.12 40010`을 수행하면 `Connection refused`로 실패하고, Host Gateway 경로 적용 후 `telnet host.docker.internal 40010`은 정상 접속되는 것으로 확인할 수 있다. #### 설정 방법 (YML 예시 + 관제 DB 접속 주소 변경) 해결을 위해 `podman-compose.yml`에 **Host Gateway 매핑**을 추가하고, 관제 DB 접속 주소를 **호스트 IP → host.docker.internal** 로 변경한다. 아래 예시처럼 dbmanager와 collector 서비스에 각각 `extra_hosts`를 추가한다. 두 서비스 모두 관제 DB에 직접 접속한다. {% code collapsedlinecount="10" %} ```yaml dbmanager: image: sysmaster-db-dbmanager:TIBERO-8.4.0 container_name: dbmanager hostname: dbmanager environment: <<: *common-env # (기타 환경변수 생략) networks: sysmaster: aliases: - dbmanager edge: {} restart: always # 이 부분 추가 extra_hosts: - "host.docker.internal:host-gateway" ``` {% endcode %} 그리고 아래처럼 관제 DB IP를 **host.docker.internal** 로 설정하면 동일 호스트에 설치된 관제 DB를 등록할 수 있다.