9.1. 설정
프로젝트의 연결 상태, API 키, 검사 조건, 애플리케이션 그룹, 알림 채널, 사용자 권한을 한 곳에서 관리합니다.
개요
설정 페이지는 OPENMARU Observability 프로젝트 전반에 걸친 구성을 관리하는 화면입니다. 좌측 사이드바에서 설정 메뉴를 클릭하면 진입할 수 있으며, 상단의 탭으로 기능 영역을 전환합니다.
| 탭 | 내용 |
|---|---|
| 시스템 설정 | 서버 연결 상태 확인 및 API 키 관 리 |
| 검사 조건 설정 | 인시던트(Incident) 발생 기준 임계값 설정 |
| 애플리케이션 카테고리 | 애플리케이션 그룹화 규칙 및 사용자 정의 애플리케이션 설정 |
| 알림채널 연결 | Slack, Teams, Email(SMTP), Webhook 알림 연동, 인시던트 해결 유예 |
| 사용자 및 권한관리 | 사용자 계정 관리 및 RBAC(Role-Based Access Control, 역할 기반 액세스 제어) |
| 보안 설정 | IP 화이트리스트(IP Whitelist) 관리 |
화면 구성
설정 페이지는 다음 영역으로 구성됩니다.
- 페이지 헤더: 설정 아이콘과 페이지 제목
- 탭 바: 6개 기능 탭(시스템 설정, 검사 조건 설정, 애플리케이션 카테고리, 알림채널 연결, 사용자 및 권한관리, 보안 설정) 전환
- 탭 콘텐츠 영역: 선택한 탭에 해당하는 설정 항목
주요 기능
시스템 설정
시스템 설정 탭에서는 프로젝트의 서버 연결 상태를 확인하고 API 키(API Key)를 관리합니다.
노드 상태
노드 상태 섹션에서 프로젝트에 연결된 구성 요소의 연결 상태를 확인할 수 있습니다.
| 항목 | 설명 | 작업 |
|---|---|---|
| VictoriaMetrics | 메트릭(Metric) 저장소 연결 상태 | 미연결 시 설정 링크 표시 |
| openmaru-node-agent | 노드 에이전트 설치 여부 및 탐지된 노드 수 | -- |
| kube-state-metrics | Kubernetes 상태 메트릭 수집기 연결 상태 및 탐지된 애플리케이션 수 | -- |
Kubernetes 가 아닌 환경(호스트 모드)에서는 kube-state-metrics 행이 표시되지 않습니다.
각 항목의 상태는 색상 표시등으로 확인할 수 있습니다.
- 녹색: 정상 연결
- 빨간색: 연결 실패 또는 미설치
- 회색: 상태를 알 수 없음
openmaru-node-agent가 설치되지 않았으면 행에 "에이전트가 설치되지 않았습니다." 문구가 표시됩니다. 이 행에는 버튼이 없습니다.
API 키
API 키(API Key)는 에이전트 및 외부 애플리케이션이 이 프로젝트에 측정 데이터를 전송할 때 사용하는 인증 키입니다.
참고: API 키 관리 기능은 Admin 역할의 사용자만 사용할 수 있습니다. Admin이 아닌 사용자에게는 키 값이 표시되지 않습니다.
API 키 조회
- 시스템 설정 탭을 엽니다.
- API 키 섹션의 테이블에서 각 키의 설명과 마스킹된 값을 확인합니다.
- 눈 모양 아이콘을 클릭하면 전체 키 값이 표시됩니다. 다시 클릭하면 마스킹됩니다.
- 복사 버튼을 클릭하면 API 키가 클립보드에 복사됩니다.
API 키 생성
- API 키 생성 버튼을 클릭합니다.
- 설명 필드에 키의 용도를 입력합니다. (예: "production-agent", "otel-collector")
- 생성 버튼을 클릭합니다.
- 생성된 API 키가 목록에 추가됩니다.
참고: 생성된 API 키는 에이전트 설치 시 사용합니다. 키 값을 안전한 곳에 보관하세요.
API 키 수정
- 수정할 키의 편집 버튼(연필 아이콘)을 클릭합니다.
- 설명 필드를 수정한 후 저장 버튼을 클릭합니다.
API 키 삭제
- 삭제할 키의 삭제 버튼(휴지통 아이콘)을 클릭합니다.
- 삭제 확인 창이 열립니다.
- 삭제 버튼을 클릭하여 확인합니다.
주의: API 키를 삭제하면 해당 키를 사용하는 에이전트나 애플리케이션이 더 이상 측정 데이터를 전송할 수 없습니다. 삭제 전 해당 키를 사용 중인 에이전트가 없는지 확인하세요.
비용 설정
비-Kubernetes(호스트) 모드가 아닌 프로젝트에서는 비용 설정 섹션이 함께 표시됩니다. 자원 사용량에 대한 단가를 지정하여 자원 현황·예측 보고서의 비용 계산 기준으로 사용합니다. 자세한 내용은 SRE 보고서 장을 참조하세요.
사용자 추정
사용자 추정 설정 섹션에서는 HTTP 트래픽에서 고유 사용자를 식별하는 방법을 설정합니다. 변경 사항은 약 1분 후 모든 node-agent에 반영됩니다. 자세한 내용은 사용자 추정 장을 참조하세요.
검사 조건 설정
검사(Inspection)는 애플리케이션 및 인프라의 상태를 지속적으로 모니터링하는 임계값(Threshold) 조건입니다. 설정한 임계값을 초과하면 인시던트(Incident)가 자동으로 생성됩니다.
검사 항목 목록
검사 조건 설정 탭에는 검사 항목 목록이 테이블 형태로 표시됩니다.
| 컬럼 | 설명 |
|---|---|
| 검사 항목 | 검사 조건의 카테고리와 이름 (예: 가용성, 응답 시간, 서버 CPU 사용률) |
| 조건 | 현재 적용 중인 기본 임계값 조건 |
| 프로젝트 수준 재정의 | 이 프로젝트 전체에 적용할 사용자 정의 임계값 |
| 애플리케이션 수준 재정의 | 개별 애플리케이션에 적용한 사용자 정의 임계값 |
이 표에 나오는 검사 항목:
- SLO / 가용성, SLO / 응답 시간: 요청 성공률과 요청 처리 시간 목표
- 인스턴스 / 인스턴스 가용성, 인스턴스 / 재시작: 인스턴스 정상 동작 여부와 컨테이너 재시작 횟수
- 배포 / 배포 상태: 배포 이상 상태 탐지
- CPU / 노드 CPU 사용률, CPU / 컨테이너 CPU 사용률: 노드와 컨테이너의 CPU 사용률 임계값
- 메모리 / 메모리 부족, 메모리 / 메모리 누수: Out of Memory 발생과 메모리 지속 증가 탐지
- 스토리지 / 디스크 I/O 부하, 스토리지 / 디스크 공간: 디스크 입출력 부하와 디스크 공간 임계값
- 네트워크 / 네트워크 라운드트립 시간(RTT): 업스트림 서비스 RTT 임계값
- 로그 / 오류수: ERROR 및 CRITICAL 심각도 로그 메시지 수 임계값
- PostgreSQL 데이터베이스: 가용성, 응답 시간, 복제 지연, 연결
- Redis: 가용성, 응답 시간
- JVM: 가용성, safepoint 작업시간
- MongoDB: 가용성, 복제 지연
PostgreSQL·Redis·JVM·MongoDB 의 가용성 검사는 판정에 기준값을 쓰지 않습니다. 대상 인스턴스가 하나라도 응답하지 않으면 경고가 됩니다. 이 검사의 설정 창에는 기준값 입력란과 저장 버튼이 없고, "이 검사는 판정에 기준값을 쓰지 않습니다." 로 시작하는 안내가 표시됩니다.
참고: 아래 표의 검사 항목은 위의 검사 항목 목록에 나오지 않습니다. 이 항목의 기준값은 애플리케이션 상세에서 바꿉니다. 탭 열은 그 검사가 나오는 애플리케이션 상세의 탭입니다. 해당 탭 상단의 검사 항목에서 톱니바퀴 아이콘을 클릭하면 설정 창이 열립니다. 이 창에서 애플리케이션 수준 값과 프로젝트 수준 값을 모두 바꿀 수 있습니다.
이 검사 항목과 기본 기준값은 다음과 같습니다. vLLM·Python 런타임·DB 연결 사용률 검사에 연결된 기본 알림 규칙은 인시던트 장의 알림 규칙 탭 설명을 참고합니다.
| 탭 | 검사 항목 | 조건 | 기본 기준값 |
|---|---|---|---|
| 네트워크 | 네트워크 연결 | 업스 트림 서비스 가용성 실패 개수 > 기준값 | 0 (판정에 쓰지 않음) |
| 네트워크 | TCP 연결 | 애플리케이션이 연결하지 못한 업스트림 서비스 수 > 기준값 | 0 (판정에 쓰지 않음) |
| 네트워크 | DB 연결 사용률 | PostgreSQL·MySQL 목적지의 동시 질의 수 > 열린 연결 수의 기준값 | 90% |
| 도메인네임 | DNS 응답 시간 | DNS 응답 시간의 95% 백분위수 > 기준값 | 0.1초 |
| 도메인네임 | DNS 서버 오류 | 서버 DNS 오류 (NXDOMAIN 제외) 수 > 기준값 | 0 |
| 도메인네임 | DNS NXDOMAIN 오류 | 이전에 유효했던 요청에 대한 NXDOMAIN DNS 오류 수 > 기준값 | 0 |
| MySQL | Mysql 가용성 | MySQL 인스턴스 가용성 실패 수 > 기준값 | 0 (판정에 쓰지 않음) |
| MySQL | Mysql 복제 상태 | I/O 또는 SQL 복제 스레드가 실행되지 않음 | 없음 |
| MySQL | Mysql 복제 지연 | MySQL 복제 지연시간 > 기준값 | 30초 |
| MySQL | Mysql 연결수 | 'max_connections'중의 연결 사용량 > 기준값 | 90% |
| Memcached | Memcached 가용성 | 가용하지 않은 memcached 인스턴스 수 > 기준값 | 0 (판정에 쓰지 않음) |
| .NET | .NET 런타임 가용성 | 가용하지 않은 .NET 인스턴스 수 > 기준값 | 0 (판정에 쓰지 않음) |
| 파이썬 | Python GIL(Global Interpreter Lock) 대기 시간 | Python 스레드가 GIL을 얻으려고 기다린 시 간의 합(초/초, 메인 인터프리터) > 기준값 | 0.05초 |
| 파이썬 | Python 이벤트 루프 막힘 | 최근 5분 Python 이벤트 루프 최장 실행 시간 > 기준값 | 2초 |
| 파이썬 | Python GC 최장 멈춤 | 최근 5분 Python GC 최장 멈춤 시간 > 기준값 | 0.5초 |
| 파이썬 | Python GC 시간 비율 | 최근 5분 Python 프로세스당 평균 GC 시간 비율 > 기준값 | 5% |
| 보안 | 트래픽 급증 | 요청률 > 1시간 평균의 기준값배 | 8배 |
| 보안 | 브루트포스 | 401/403 응답 비율 > 기준값 | 50% (아래 참고) |
| 보안 | 에러율 급증 | 5xx 에러율 > 1시간 평균의 기준값배 | 10배 |
| 보안 | 보안 패턴 탐지 | 보안 이벤트 수 > 기준값 | 0 |
| vLLM | vLLM 요청 오류 | 오류로 끝난 요청 비율 > 기준값 | 5% |
| vLLM | vLLM KV 캐시 사용률 | vLLM 인스턴스의 KV 캐시 사용률 > 기준값 | 90% |
| vLLM | vLLM 대기 요청 | vLLM 인스턴스의 대기 요청 수 > 기준값 | 0 |
- "판정에 쓰지 않음" 이 붙은 검사는 대상(업스트림 서비스, 인스턴스)이 하나라도 있으면 경고가 됩니다. 이 검사와 Mysql 복제 상태의 설정 창에는 기준값 입력란과 저장 버튼이 없고 안내 문구만 표시됩니다. Mysql 복제 상태는 조건에 기준값이 없습니다. 복제 스레드가 멈춘 인스턴스가 하나라도 있으면 경고가 됩니다.
- 브루트포스의 기준값은 % 단위입니다. 기본값 50% 는 401/403 응답이 요청의 50% 를 넘으면 경고한다는 뜻입니다. 이전 버전에서 저장한 비율 값(0~1)은 서버를 업데이트할 때 한 번 % 로 바뀝니다(예: 0.5 → 50). 판정 결과는 바뀌지 않습니다.
프로젝트 수준 임계값 재정의
특정 검사 항목의 임계값을 프로젝트 전체에 걸쳐 변경하려면:
- 변경할 검사 항목의 프로젝트 수준 재정의 열에서 재정의 링크를 클릭합니다.
- 설정 창이 열리면 원하는 임계값을 입력합니다.
- 설정 창에는 전역 기본값(Global default), 프로젝트 수준 재정의(Project-level override), 그리고 필요 시 애플리케이션 수준 재정의 행이 표시됩니다.
- 프로젝트 수준 재정의가 설정되지 않은 경우 전역 기본값이 적용되며, 재정의 링크를 클릭하여 사용자 정의 값을 입력할 수 있습니다.
- 저장 버튼을 클릭합니다.
설정이 완료되면 해당 열에 재정의된 값이 표시됩니다. 재정의 값을 변경하려면 표시된 값 옆의 편집 아이콘을 클릭합니다.
참고: SLO(Service Level Objective, 서비스 수준 목표) 가용성 및 SLO 응답 시간 항목은 프로젝트 수준 재정의를 지원하지 않습니다. 해당 항목은 애플리케이션 상 세 페이지에서 개별 설정할 수 있습니다.
애플리케이션별 임계값 재정의
특정 애플리케이션에만 다른 임계값을 적용하려면:
- 애플리케이션 수준 재정의 열에 표시된 해당 애플리케이션 이름의 편집 아이콘을 클릭합니다.
- 설정 창에서 해당 애플리케이션에 적용할 임계값을 입력합니다.
- 저장 버튼을 클릭합니다.
팁: 서비스 특성에 따라 애플리케이션별 임계값을 개별 조정하면 불필요한 인시던트 발생을 줄이고 정확한 경보를 받을 수 있습니다.
SLO 검사 조건 설정
SLO 가용성 및 SLO 응답 시간 항목은 애플리케이션 상세 페이지의 SLO 탭에서 설정합니다. 검사 조건 설정 창에서는 다음을 구성할 수 있습니다.
SLO 가용성 설정
- 지표(Metrics): 기본 제공되는 인바운드 요청(built-in)을 사용하거나, 사용자 정의 PromQL 쿼리를 지정할 수 있습니다. 사용자 정의를 선택하면 총 요청 쿼리와 실패 요청 쿼리를 별도로 입력합니다.
- 목표값(Objective): 체크박스로 SLO 추적을 활성화하고, 요청 성공률 목표를 퍼센트(%)로 설정합니다. (예:
99%의 요청이 실패하지 않아야 함)
SLO 응답 시간 설정
- 지표(Metrics): 기본 제공 인바운드 요청 또는 사용자 정의 히스토그램 쿼리를 지정할 수 있습니다.
- 목표값(Objective): 요청의 일정 비율이 지정한 응답 시간 이내에 처리되어야 하는 목표를 설정합니다. (예:
99%의 요청이500ms이내에 처리되어야 함) - 대상 버킷: 5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2s, 3s, 4s, 5s, 6s, 7s, 8s, 9s, 10s 중에서 선택할 수 있습니다(1초 이상은 1초 간격).
vLLM 애플리케이션의 응답 시간 SLO
vLLM 엔진이 있는 애플리케이션은 응답 시간 SLO 를 HTTP 응답 시간이 아니라 첫 토큰 시간(TTFT, Time To First Token) 으로 판정합니다. LLM 요청의 HTTP 응답 시간은 생성한 토큰 수에 따라 길어지기 때문입니다.
- 기본 목표: 첫 토큰 시간 2.5초 이하인 요청이 95% 이상이어야 합니다. 사용자가 저장한 값이 있으면 그 값을 씁니다.
- 대상 버킷: 0.1s, 0.25s, 0.5s, 0.75s, 1s, 2.5s, 5s, 7.5s, 10s, 20s 중에서 선택할 수 있습니다. 이 목록은 vLLM 이 첫 토큰 시간을 기록하는 구간 경계입니다.
- 지표에서 사용자 정의 히스토그램 쿼리를 선택하면, 첫 토큰 시간 대신 그 쿼리로 판정합니다.
- 첫 토큰 시간 데이터가 수집되지 않으면, 다른 애플리케이션과 같이 HTTP 응답 시간으로 판정합니다.
- 가용성 SLO 는 바뀌지 않습니다. vLLM 애플리케이션도 HTTP 5xx 응답 비율로 판정합니다.
SLO 탭의 조건 문구는 "첫 토큰 시간(TTFT)이 2.5s 보다 빠른 요청 비율" 처럼 첫 토큰 시간 기준임을 표시합니다. 조회 구간의 일부만 첫 토큰 시간 데이터가 있으면 "TTFT 기준 시작: <시각>" 이 함께 표시됩니다.
참고: APM 대시보드는 HTTP 응답 시간을 그대로 보여 줍니다. 그래서 vLLM 애플리케이션은 APM 대시보드에서 느린 애플리케이션으로 보일 수 있습니다.
경고(Alerting)
SLO 설정 창 하단에 현재 연동된 알림 채널 상태가 표시됩니다. 알림 채널이 설정되지 않은 경우 알림 채널 설정 버튼을 클릭하여 알림채널 연결 탭으로 이동할 수 있습니다.
SLO 검사 조건의 재정의를 삭제하려면 설정 창에서 삭제 아이콘을 클릭합니다.
애플리케이션 카테고리
애플리케이션을 논리적으로 그룹화하여 관리하는 설정입니다. 카테고리(Category)를 정의하면 대시보드, 토폴로지 맵, 애플리케이션 목록 등 여러 화면에서 카테고리 필터로 애플리케이션을 구분하여 볼 수 있습니다.
카테고리 설정
카테고리 목록에는 현재 정의된 카테고리가 표시됩니다.
| 컬럼 | 설명 |
|---|---|
| 카테고리 | 카테고리 이름 |
| 패턴 | 이 카테고리에 포함할 애플리케이션을 매칭하는 Glob 패턴 |
| 배포 알림 | 이 카테고리 애플리케이션의 배포 발생 시 알림 수신 여부 (켜짐/꺼짐) |
| 작업 | 편집 및 삭제 버튼 |
참고: 기본 카테고리(default)는 다른 카테고리에 포함되지 않는 애플리케이션을 담는 카테고리입니다. 기본 카테고리는 삭제할 수 없습니다. 내장(builtin) 카테고리는 이름과 내장 패턴을 변경할 수 없으며, 사용자 정의 패턴만 추가할 수 있습니다.
카테고리 추가
- 카테고리 추가 버튼을 클릭합니다.
- 이름 필드에 카테고리 이름을 입력합니다.
- 사용자 정의 패턴 필드에 이 카테고리에 포함할 애플리케이션 패턴을 입력합니다.
- 패턴은
네임스페이스/애플리케이션명형식으로 입력합니다. (예:staging/*,test-*/*) - 여러 패턴은 공백으로 구분합니다.
- Glob 패턴 문법을 사용할 수 있습니다.
- 패턴은
- 배포 알림 옵션을 설정합니다. 활성화하면 이 카테고리의 애플리케이션이 배포될 때 설정된 알림 채널로 알림이 전송됩니다.
- 알림 채널이 설정되지 않은 경우 "알림 채널이 설정되지 않았습니다" 메시지가 표시되며, 알림 채널 설정 버튼을 클릭하여 알림채널 연결 탭으로 이동할 수 있습니다.
- 저장 버튼을 클릭합니다.
카테고리 편집 및 삭제
- 편집: 목록에서 카테고리의 편집 버튼(연필 아이콘)을 클릭하여 설정을 변경합니다.
- 삭제: 삭제 버튼(휴지통 아이콘)을 클릭합니다. 내장 카테고리는 삭제할 수 없습니다.
참고: Kubernetes 애플리케이션의 경우, Kubernetes 객체에 주석(annotation)을 달아서 카테고리를 정의할 수도 있습니다.
사용자 정의 애플리케이션
OPENMARU Observability는 기본적으로 다음 방법으로 컨테이너를 애플리케이션으로 자동 그룹화합니다.
- Kubernetes 메타데이터: Pod이 Deployment, StatefulSet 등으로 그룹화됩니다.
- Kubernetes 이외의 컨테이너: Docker 컨테이너 또는 Systemd 유닛은 이름 기준으로 그룹화됩니다. 예를 들어 여러 서버에서 실행 중인
mysql서비스는 하나의mysql애플리케이션으로 묶입니다.
이 기본 방식이 적합하지 않은 경우, 사용자 정의 애플리케이션 설정으로 인스턴스 이름 패턴을 정의하여 원하는 컨테이너를 하나의 애플리케이션으로 묶을 수 있습니다.
| 컬럼 | 설명 |
|---|---|
| 애플리케이션 이름 | 사용자 정의 애플리케이션의 이름 |
| 인스턴스 패턴 | 이 애플리케이션에 포함할 인스턴스를 매칭하는 Glob 패턴 |
| 작업 | 편집 및 삭제 버튼 |
사용자 정의 애플리케이션 추가
- 애플리케이션 추가 버튼을 클릭합니다.
- 이름 필드에 애플리케이션 이름을 입력합니다.
- 인스턴스 패턴 필드에 포함할 인스턴스 이름 패턴을 입력합니다.
- 인스턴스 이름 기준으로 매칭합니다. (예:
mysql@node1,cassandra@cass-node*) - 여러 패턴은 공백으로 구분합니다.
- 인스턴스 이름 기준으로 매칭합니다. (예:
- 저장 버튼을 클릭합니다.
참고: 사용자 정의 애플리케이션 설정은 Kubernetes 환경이 아닌 컨테이너(Docker 컨테이너, Systemd 유닛 등)에 적용됩니다. Kubernetes 워크로드에는 적용되지 않습니다.
네임스페이스 규칙
비-Kubernetes 워크로드(Docker, Systemd, 호스트 프로세스)에 대해 container_id를 Glob 패턴으로 매칭하여 사용자 지정 네임스페이스를 부여합니다. 규칙은 순서대로(첫 매칭 우선) 평가되며, 사용자 수 추정과 보안 공격 탐지가 지정한 네임스페이스로 집계됩니다.
숨긴 애플리케이션
모든 화면(리스트, 토폴로지, 헬스, 인시던트)에서 숨긴 애플리케이션을 관리합니다. 숨김은 되돌릴 수 있고 데이터는 그대로 유지되므로, 언제든 다시 표시하여 애플리케이션을 복원할 수 있습니다.
알림채널 연결
인시던트 및 배포 이벤트가 발생했을 때 외부 채널로 알림(Notification)을 전송하도록 설정합니다.
기본 URL 설정
알림 메시지에 포함되는 링크의 기준이 되는 URL입니다. 외부에서 이 시스템에 접근할 수 있는 URL을 입력합니다.
- 기본 URL 입력 필드에 URL을 입력합니다.
- 저장 버 튼을 클릭합니다.
참고: 기본 URL이 설정되지 않은 경우, 현재 접속 중인 브라우저의 URL이 자동으로 설정됩니다.
알림 채널 목록
지원되는 알림 채널이 테이블에 표시됩니다.
| 컬럼 | 설명 |
|---|---|
| 유형 | 알림 채널 종류 (Slack, MS Teams, Email(SMTP), Webhook) |
| 인시던트 알림 | 인시던트 발생 시 이 채널로 알림 전송 여부 |
| 배포 알림 | 배포 발생 시 이 채널로 알림 전송 여부 |
| 알림 | 알림 규칙 발화 시 이 채널로 전송 여부 |
| 작업 | 설정, 편집, 삭제 버튼 |
아직 설정되지 않은 채널에는 설정 버튼이 표시되고, 이미 설정된 채널에는 편집(연필 아이콘) 및 삭제(휴지통 아이콘) 버튼이 표시됩니다.
Slack 연동
Slack 채널로 인시던트 및 배포 알림을 수신하려면:
- Slack 항목의 설정 버튼을 클릭합니다.
- Slack 앱 생성: Create Slack app 버튼을 클릭하여 Slack에서 앱을 생성합니다. 앱이 생성되면 Slack에서 Install to workspace를 클릭하여 승인합니다.
- Slack 봇 사용자 OAuth Token: Slack 앱의 OAuth & Permissions 페이지에서 Bot User OAuth Token을 복사하여 입력합니다.
- Slack 채널 이름: Slack에서 공용 채널을 생성한 후,
#뒤에 채널 이름을 입력합니다. - 알림 유형: 인시던트 및 배포 체크박스로 수신할 알림 유형을 선택합니다.
- 테스트 알림 보내기 버튼을 클릭하여 설정이 올바른지 확인합니다.
- 저장 버튼을 클릭합니다.
Microsoft Teams 연동
Microsoft Teams 채널로 알림을 수신하려면:
- Teams에서 대상 채널을 선택합니다(또는 새 채널을 생성합니다).
- 상단 탐색 메뉴에서 점 세 개(...)를 클릭하고 Connectors를 선택합니다.
- Incoming Webhook을 검색하고 Configure 버튼을 누릅니다.
- Webhook 이름을 입력하고 Create 버튼을 누릅니다.
- 생성된 Webhook URL을 복사합니다.
- 설정 페이지에서 Teams 항목의 설정 버튼을 클릭합니다.
- Webhook URL 필드에 복사한 URL을 붙여넣습니다.
- 알림 유형: 인시던트 및 배포 체크박스로 수신할 알림 유형을 선택합니다.
- 테스트 알림 보내기 버튼을 클릭하여 설정이 올바른지 확인합니다.
- 저장 버튼을 클릭합니다.
Webhook 연동
커스텀 Webhook으로 알림을 전송하여 외부 시스템과 자유롭게 연동할 수 있습니다.
- Webhook 항목의 설정 버튼을 클릭합니다.
- Webhook URL을 입력합니다.
- 필요 시 다음 고급 옵션을 설정합니다.
- TLS 검증 건너뛰기: 자체 서명 인증서 사용 시 활성화 (HTTPS URL인 경우에만 활성화 가능)
- HTTP 기본 인증: 사용자 이름과 비밀번호를 입력하여 인증 설정
- 사용자 정의 HTTP 헤더: 헤더 이름과 값을 추가합니다. 여러 헤더를 추가할 수 있습니다.
- 알림 유형: 인시던트 및 배포 체크박스로 수신할 알림 유형을 선택합니다.
- 인시던트 템플릿: 인시던트 발생 시 전송할 메시지 형식을 설정합니다.
- 배포 템플릿: 배포 발생 시 전송할 메시지 형식을 설정합니다.
- 테스트 알림 보내기 버튼을 클릭하여 설정이 올바른지 확인합니다.
- 저장 버튼을 클릭합니다.
Email(SMTP) 연동
사내 메일 서버로 알림을 받습니다. 외부 SaaS로 나갈 수 없는 폐쇄망에서 쓸 수 있는 통로입니다.
- Email (SMTP) 항목의 설정 버튼을 클릭합니다.
- 메일 서버의 호스트와 포트를 입력합니다.
- 암호화 방식을 선택합니다. 방식을 고르면 포트 기본값이 함께 바뀌지만, 포트를 직접 입력한 뒤에는 덮어쓰지 않습니다.
| 방식 | 기본 포트 | 설명 |
|---|---|---|
| STARTTLS | 587 | 평문으로 연결한 뒤 암호화로 전환합니다. 서버가 지원하지 않으면 실패합니다 |
| TLS | 465 | 첫 바이트부터 암호화합니다 |
| 없음 | 25 | 암호화하지 않습니다. 암호화되지 않은 연결에서는 인증이 거부됩니다 |
- 사설 인증기관이 발급한 인증서를 쓴다면 TLS 인증서 검증 건너뛰기를 켭니다.
주의: 이 옵션을 켜면 어떤 인증서든 받아들입니다. 신뢰하는 사설 인증기관 환경에서만 사용하세요.
- 인증의 사용자 이름과 비밀번호를 입력합니다. 인증이 필요 없는 릴레이라면 비워 둡니다.
- 주소를 입력합니다. 보내는 주소와 보내는 사람 이름, 받는 주소(여러 명이면 쉼표로 구분)를 지정합니다.
- 묶음 발송 간격을 분 단위로 지정합니다. 0이면 건별로 즉시 보냅니다.
주의: 묶음 발송은 심각도를 구분하지 않습니다. 장애 알림도 최대 이 시간만큼 늦게 도착합니다. 급한 알림을 놓치면 안 되는 채널이라면 0으로 두세요.
- 알림 언어를 선택합니다(한국어 / English).
- 알림 대상에서 장애·배포·알림 중 받을 유형을 고릅니다.
참고: 배포 알림을 처음 켜면 최근 24시간 배포에 대한 알림이 한 번 발송됩니다. 묶음 발송을 켜 두었다면 한 통으로 묶여 옵니다.
- 테스트 알림 보내기 버튼으로 설정이 올바른지 확인합니다.
- 저장 버튼을 클릭합니다.
설정이 맞지 않을 때 나오는 문구
메일 설정은 한 번에 맞는 일이 드뭅니다. 테스트 발송이 실패하면 화면에 원인이 그대로 표시됩니다.
| 문구에 포함된 말 | 원인 |
|---|---|
connection refused 또는 i/o timeout | 호스트·포트가 틀렸거나 방화벽에 막힘 |
certificate 또는 x509 | 인증서를 신뢰할 수 없음. 사설 인증서라면 검증 건너뛰기를 켠다 |
Must issue a STARTTLS command first | 서버가 암호화를 요구하는데 없음으로 설정함 |
Authentication credentials invalid | 사용자 이름·비밀번호가 틀림 |
보고서 첨부
SRE 보고서의 정기 보고서를 SMTP로 받으면 PDF·Excel이 첨부로 옵니다. 첨부가 상한(기본 20MB)을 넘으면 첨부를 빼고 본문에 그 사유를 적어 보냅니다.
채널 수정 및 삭제
- 편집: 설정된 채널의 편집 버튼(연필 아이콘)을 클릭하여 설정을 변경합니다.
- 삭제: 삭제 버튼(휴지통 아이콘)을 클릭하여 연동을 해제합니다.
인시던트 해결 유예
알림채널 연결 탭의 알림 통합 카드 아래에 인시던트 해결 유예 카드가 있습니다. 이 카드에서 인시던트를 해결하기 전에 기다리는 시간을 정합니다.
인시던트의 SLO 상태가 정상으로 돌아와도 인시던트는 바로 해결되지 않습니다. 이 시간 동안 SLO 위반이 다시 생기지 않으면 인시던트가 해결됩니다. 그사이 다 시 위반하면 새 인시던트를 열지 않고 같은 인시던트가 이어집니다. 해결 시각은 SLO 가 처음 정상으로 돌아온 시각으로 기록됩니다. 인시던트가 열리고 해결되는 과정은 인시던트 장을 참고합니다.
| 항목 | 내용 |
|---|---|
| 단위 | 초 |
| 입력 범위 | 0 ~ 3600 사이의 정수 |
| 기본값 | 300초(5분). 저장한 값이 없을 때 씁니다 |
| 0 | 해결 유예를 끕니다. SLO 가 정상이 되면 인시던트가 바로 해결됩니다 |
값 바꾸기
- 설정 페이지에서 알림채널 연결 탭을 엽니다.
- 인시던트 해결 유예 카드의 입력란에 초 단위 값을 입력합니다.
- 저장 버튼을 클릭합니다.
저장되면 "설정을 저장했습니다." 메시지가 표시됩니다. 범위 밖의 값이나 정수가 아닌 값을 입력하면 "0 ~ 3600 사이의 정수(초)를 입력하세요." 문구가 표시되고 값이 저장되지 않습니다.
- 이 카드는 저장 버튼을 클릭할 때만 값을 저장합니다. 기본 URL 이 비어 있으면 알림채널 연결 탭은 화면을 열 때 기본 URL 을 자동으로 저장합니다. 이 자동 저장은 인시던트 해결 유예 값을 바꾸지 않습니다.
- 입력란을 비우고 저장 버튼을 클릭하면 저장한 값이 지워지고 기본값 5분(300초)으로 돌아갑니다. 그 뒤 입력란은 빈 칸으로 표시됩니다.
- 기본 역할 중에서는 Admin 만 이 값을 저장할 수 있습니다. 알림 채널 설정과 같은 권한입니다. 다른 사용자가 저장 버튼을 클릭하면 오류 메시지가 표시됩니다.
- 모든 인시던트의 해결 통보는 유예 시간이 끝난 뒤에 나갑니다. 유예 중에는 SLO 가 정상이어도 인시던트가 해결되지 않은 상태로 목록에 남습니다.
참고: 알림 규칙의 해결 유예 시간(KeepFiringFor, 화면 이름 해결 유예 시간 (초))은 이 설정과 다릅니다. 그 값은 알림 규칙마다 정하고, 알림에만 적용됩니다. 이 카드의 값은 프로젝트의 모든 인시던트에 적용됩니다.
사용자 및 권한관리
프로젝트에 접근할 수 있는 사용자를 관리하고, RBAC를 통해 각 사용자의 권한을 설정합니다.
사용자 관리
등록된 사용자 목록이 테이블 형태로 표시됩니다.
| 컬럼 | 설명 |
|---|---|
| 이메일(로그인) | 사용자 로그인 이메일 주소 |
| 이름 | 사용자 이름 |
| 역할 | 할당된 역할 (Admin, Editor, Viewer) |
| 작업 | 편집 및 삭제 버튼 |
사용자 추가
- 사용자 추가 버튼을 클릭합니다.
- 사용자 추가 창이 열리면 다음 정보를 입력합니다.
- 이메일(로그인): 사용자의 로그인 이메일 주소
- 이름: 사용자 이름
- 역할: 부여할 역할 선택 (Admin, Editor, Viewer)
- 비밀번호: 초기 비밀번호 설정
- 생성 버튼을 클릭합니다.
사용자 수정
- 수정할 사용자의 편집 버튼(연필 아이콘)을 클릭합니다.
- 이메일, 이름, 역할, 비밀번호를 수정한 후 저장 버튼을 클릭합니다.
참고: 비밀번호 필드를 비워두면 기존 비밀번호가 유지됩니다.
사용자 삭제
- 삭제할 사용자의 삭제 버튼(휴지통 아이콘)을 클릭합니다.
- 삭제 확인 창에서 삭제 버튼을 클릭합니다.
참고: 읽기 전용(readonly)으로 표시된 사용자는 편집 및 삭제가 불가능합니다.
역할 기반 액세스 제어 (RBAC)
RBAC를 통해 각 역할이 수행할 수 있는 작업을 관리합니다.
OPENMARU Observability는 세 가지 기본 역할을 제공합니다.
| 역할 | 설명 |
|---|---|
| Admin | 모든 기능에 대한 완전한 접근 권한. 사용자 관리, 설정 변경, 데이터 조회 모두 가능. |
| Editor | 대부분의 모니터링 기능 사용 가능. 일부 관리 기능(사용자 관리 등)은 제한됨. |
| Viewer | 모니터링 데이터 조회만 가능. 설정 변경 불가. |
역할 기반 액세스 제어(RBAC) 섹션의 테이블에서 각 역할이 수행할 수 있는 작업 항목을 확인할 수 있습니다.
- 체크 표시(녹색): 해당 역할에서 허용되는 작업
- 목록 아이콘(녹색): 특정 객체에 한정하여 허용되는 작업 (아이콘에 마우스를 올리면 허용 대상 목록이 툴팁으로 표시됩니다)
- X 표시(빨간색): 해당 역할에서 허용되지 않는 작업
주요 작업 항목은 다음과 같습니다.
| 작업 | Admin | Editor | Viewer |
|---|---|---|---|
| 사용자 관리 | 허용 | 거부 | 거부 |
| 역할 관리 | 허용 | 거부 | 거부 |
| 프로젝트 설정 변경 | 허용 | 거부 | 거부 |
| 알림 채널 설정 | 허용 | 거부 | 거부 |
| 카테고리 설정 | 허용 | 허용 | 거부 |
| 사용자 정의 애플리케이션 설정 | 허용 | 허용 | 거부 |
| 검사 조건 설정 | 허용 | 허용 | 거부 |
| 분산추적 조회 | 허용 | 허용 | 허용 |
| 위험요소 조회 | 허용 | 허용 | 허용 |
| 위험요소 편집 | 허용 | 거부 | 거부 |
| 애플리케이션 조회 | 허용 | 허용 | 허용 |
| 서버 조회 | 허용 | 허용 | 허용 |
참고: 커스텀 역할을 가진 사용자가 존재할 경우 RBAC 테이블에 해당 역할이 함께 표시됩니다. 커스텀 역할의 편집 버튼(연필 아이콘)을 클릭하면 Scope, Action, Object 단위의 세분화된 권한 정책을 확인할 수 있습니다.
보안 설정
보안 설정 탭에서는 IP 화이트리스트(IP Whitelist)를 관리합니다. 허용할 IP 주소 또는 CIDR 대역을 등록하면, 해당 출발지에서 들어오는 트래픽은 보안 공격 탐지 대상에서 제외됩니다. 사내 스캐너, 헬스 체크, 신뢰할 수 있는 게이트웨이 등 정상 트래픽이 공격으로 오탐되는 것을 방지하는 데 사용합니다.
허용 항목을 추가하려면 IP 주소 또는 CIDR 대역을 입력한 후 저장하고, 더 이상 필요하지 않은 항목은 목록에서 삭제합니다.
참고: 보안 공격 탐지 및 보안 이벤트에 대한 자세한 내용은 보안 장을 참조하세요.