1. 개요
OPENMARU APM은 Java 기반 웹 애플리케이션에 대한 실시간 모니터링을 제공함으로써 장애를 사전에 예방하고, 지속적인 성능 개선에 활용할 수 있는 APM(Application Performance Monitoring) 도구입니다.
OPENMARU APM은 Java 기반 웹 애플리케이션 에 대한 실시간 동작 모니터링뿐만 아니라, 실시간 통계 분석 기법을 적용하여 문제를 사전에 판단할 수 있는 강력한 기능들을 제공합니다.
이 가이드로 하는 일
에이전트를 설치합니다. 에이전트는 모니터링 대상 서버에서 도는 작은 프로그램으로, 성능 데이터를 모아 APM 서버로 보냅니다. APM 서버와 콘솔은 이미 설치되어 있다고 가정합니다 — 서버 구축은 별도의 설치 가이드에서 다룹니다.
에이전트는 두 종류입니다
| 무엇을 보나 | 어디에 설치하나 | 애플리케이션을 고치나 | |
|---|---|---|---|
| 시스템 에이전트 | 서버의 CPU·메모리·디스크·네트워크, 웹 서버·데이터베이스 | 서버마다 한 벌 | 아니오 (별도 프로세스) |
| WAS 에이전트 | 애플리케이션 안의 요청 흐름·SQL·외부 호출·JVM 메모리 | WAS 인스턴스마다 한 벌 | 아니오 (기동 옵션만 추가) |
둘 다 설치하는 것을 권합니다. 응답이 느려졌을 때 서버 자원이 모자란 것인지 코드가 문제인지 가르려면 양쪽 데이터가 함께 있어야 합니다.
설치를 마치면 무엇이 되나
- 콘솔에 서버와 애플리케이션 인스턴스가 나타나고 지표가 실시간으로 갱신됩니다
- 느린 요청 한 건을 눌러 어느 구간에서 시간을 썼는지 볼 수 있습니다
- 임계치를 넘으면 알림을 받도록 설정할 수 있습니다 (이벤트 설정 가이드에서 다룹니다)
얼마나 걸리나
에이전트 한 벌에 10~20분입니다. 대부분은 파일을 내려받아 압축을 풀고 접속 정보를 적는 작업이고, WAS 에이전트는 마지막에 WAS 재기동이 한 번 필요합니다. 재기동 일정을 미리 잡아 두십시오.
설치 가이드 소개
이 문서는 OPENMARU APM을 사용하여 웹 애플리케이션 서버(WAS)를 모니터링하고자 하는 사용자를 위한 설치 안내서입니다.
대상 독자
| 대상 | 설 명 |
|---|---|
| 시스템 관리자 | APM Server 및 에이전트 설치 담당자 |
| DevOps 엔지니어 | CI/CD 파이프라인에 APM 통합 담당자 |
| 개발자 | 애플리케이션 성능 분석 및 최적화 담당자 |
| 운영팀 | 실시간 모니터링 및 장애 대응 담당자 |
문서의 목적
- OPENMARU APM 에이전트 설치 및 구성 방법 제공
- 웹 애플리케이션 모니터링을 통한 장애 원인 파악 가이드
- 성능 분석 및 최적화를 위한 모니터링 설정 방법
주요 기능
에이전트를 설치하면 콘솔에서 아래 기능을 쓸 수 있습니다. 무엇을 볼 수 있는지 먼저 알아야 어느 에이전트를 어디에 설치할지 정할 수 있으므로 설치에 들어가기 전에 훑어보십시오. 괄호 안은 그 기능에 필요한 에이전트입니다.
성능 분석 및 모니터링
서비스 만족도 지수 (APDEX) — WAS 에이전트
"지금 서비스가 괜찮은가"를 숫자 하나로 답합니다. 응답 시간을 밀리초로 보면 1.2초가 괜찮은 값인지 매번 따져야 하지만, APDEX 는 사용자가 만족했는지를 기준으로 0~100 점으로 환산하므로 "90 이상 유지" 같은 목표를 세우기 쉽습니다.
그래서 부서 간 합의 문서나 경영진 보고의 서비스 수준 목표(SLO) 지표로 자주 씁니다. 값이 떨어지면 아래의 T-Map 으로 어느 트랜잭션이 끌어내렸는지 찾아 들어갑니다.
Application Performance Index의 약자로, 애플리케이션 성능에 대한 사용자 만족도를 0~100점 사이의 하나의 숫자로 표현하는 산업 표준 지표입니다.
등급 구분:
- 94~100점: Excellent (탁월) - 거의 완벽한 성능
- 85~94점: Good (좋음) - 양호한 성능
- 70~85점: Fair (보통) - 허용 가능한 성능
- 50~70점: Poor (나쁨) - 개선 필요
- 0~50점: Unacceptable (수용 불가) - 즉각적인 조치 필요
응답 시간 기준:
- Satisfied (만족): T 이하 - 사용자가 집중하고 있음, 성능이 만족스러움
- Tolerating (허용): T ~ 4T - 사용자가 집중하기 어려움, 성능에 만족스럽지 못함
- Frustrated (불만): 4T 초과 - 사용자가 서비스 사용을 포기함, 서비스를 받아들일 수 없는 상태
APDEX 계산식: (Satisfied 요청 수 + (Tolerating 요청 수 ÷ 2)) ÷ 전체 요청 수 × 100
T(Threshold)는 WAS Agent 설정 파일에서 지정(기본값 3.0)할 수 있습니다.
T-Map (Transaction 분포도) — WAS 에이전트
평균에 가려진 느린 요청을 찾습니다. 트랜잭션 하나하나를 시간(가로)과 응답 시간(세로)의 점으로 찍어 놓은 화면입니다.
평균 응답 시간만 보면 "0.4초, 괜찮다"로 끝나지만, T-Map 에서는 위쪽에 떨어져 있는 몇 개의 점이 그대로 보입니다. 그 점을 클릭하면 그 요청 하나의 처리 과정이 열립니다 — 어느 메서드에서 얼마를 썼는지, 어떤 SQL 을 몇 번 실행했는지, 외부 시스템을 얼마나 기다렸는지.
점이 흩어진 모양으로 원인을 짐작할 수 있습니다. 특정 시각에 세로로 몰려 있으면 그때 무슨 일이 있었던 것이고(배치·GC·배포), 특정 화면만 계속 위쪽에 있으면 그 화면의 문제입니다.
실시간 예측 (Forecast) — WAS · 시스템 에이전트
임계값을 넘기 전에 알려 줍니다. 최근 값의 추세를 이어 그려 "이대로 가면 몇 분 뒤에 임계값에 닿는다"를 계산합니다.
메모리가 서서히 새는 경우처럼 터진 뒤에는 되돌리기 어려운 상황에서 쓸모가 있습니다. 임계값 도달 알림은 이미 문제가 생긴 뒤에 오지만, 예측 알림은 조치할 시간을 줍니다.
예측 대상은 CPU 사용률, 메모리 사용량, 지연 트랜잭션입니다.
장애 분석 도구
WAS 장애 분석 — WAS 에이전트
"WAS 가 멈췄는데 원인을 모르겠다"에 답하는 도구입니다. 장애가 났을 때 서버에 접속해
jstack 을 뜨고 눈으로 읽는 대신, 콘솔에서 바로 받아 분석 결과를 봅니다.
| 도구 | 어떤 상황에 쓰나 |
|---|---|
| 스레드 덤프 수집·분석 | 응답 이 없거나 느릴 때 — 어느 스레드가 어디서 멈춰 있는지, 데드락인지 |
| 힙 덤프 분석 | 메모리가 부족할 때 — 무엇이 메모리를 잡고 있는지 |
| 실행 중인 SQL 추적 | 데이터베이스가 의심될 때 — 지금 돌고 있는 쿼리가 무엇인지 |
| 트랜잭션 프로파일링 | 특정 요청이 느릴 때 — 그 안에서 어느 구간이 오래 걸리는지 |
| 메서드 실행 통계 | 코드 어디를 고칠지 정할 때 — 호출 횟수와 누적 시간 |
장애 상황에서는 서버에 접속조차 어려울 때가 있습니다. 미리 설치해 두면 그때 콘솔만으로 자료를 확보할 수 있습니다.
이상 징후 모니터링 — WAS · 시스템 에이전트
임계값을 정하지 않아도 되는 감시입니다. 지표마다 임계값을 손으로 정하려면 서비스 특성과 시간대를 다 알아야 하는데, 이 기능은 평소 값의 분포를 학습해 두고 거기서 벗어날 때 알려 줍니다.
새벽에는 한산하고 낮에는 붐비는 서비스에서 고정 임계값 하나로는 둘 다 맞추기 어렵습니다. 평소와 다른지를 보면 시간대에 관계없이 판단할 수 있습니다.
감지 대상은 평균 응답 시간 급증, 오류율 증가, CPU·메모리의 평소와 다른 사용 패턴, 트래픽 급증·급감입니다.
시스템 및 인프라 모니터링
OS 자원 모니터링 — 시스템 에이전트
애플리케이션이 느린 것인지 서버가 부족한 것인지 가릅니다. WAS 지표만 보면 응답이 느려진 사실은 알아도 원인이 코드인지 자원인지 알 수 없습니다. 같은 시각의 서버 자원을 겹쳐 보면 갈립니다.
| 모니터링 항목 | 수집 지표 | 무엇을 판단하나 |
|---|---|---|
| CPU | 사용률, Core별 사용량, System/User Time | 연산이 몰렸는가, 커널 쪽인가 사용자 코드인가 |
| Memory | 사용량, 가용 메모리, Swap 사용량 | 메모리가 부족한가, 스왑이 일어나 느려졌는가 |
| Disk | 사용률, I/O 성능, 읽기/쓰기 속도 | 로그·데이터 쓰기가 병목인가, 용량이 곧 차는가 |
| Network | 트래픽, 패킷 수, 오류율, 소켓 상태 | 대역폭이 모자란가, 소켓이 쌓이고 있는가 |
| Load Average | 1분, 5분, 15분 평균 부하 | 지금 몰린 것인가, 계속 그런 것인가 |
1분·5분·15분을 같이 보는 이유 — 1분 만 높고 15분이 낮으면 방금 몰린 것이고, 셋 다 높으면 계속 부하가 걸려 있는 것입니다. 전자는 기다려 보고 후자는 증설을 검토합니다.
웹 서버 모니터링 — 시스템 에이전트 (플러그인)
사용자와 WAS 사이 구간을 봅니다. WAS 에는 요청이 안 들어왔는데 사용자는 느리다고 할 때, 그 사이에서 무슨 일이 있었는지는 웹 서버 지표로만 알 수 있습니다.
| 지표 | 무엇을 알 수 있나 |
|---|---|
| 트래픽 | 실제로 얼마나 들어오고 있는가 |
| RPS(초당 요청 수) | 부하가 늘었는가, 평소 대비 몇 배인가 |
| 활성 연결 수 | 연결이 처리되지 못하고 쌓이고 있는가 |
| 응답 코드 분포 | 2xx·3xx·4xx·5xx — 오류가 웹 서버에서 난 것인가 WAS 에서 난 것인가 |
5xx 가 웹 서버에서 잡히는데 WAS 트랜잭션 수는 그대로라면 요청이 WAS 까지 닿지 못한 것입니다. 연결 수·워커 상태를 봐야 합니다.
이벤트 및 알림
통계 기반 이벤트 처리
알림이 너무 많아 아무도 안 보는 상태를 피하는 것이 목적입니다. 값이 임계값을 한 번 넘을 때마다 알리면 순간적으로 튄 값에도 알림이 나가고, 그런 알림이 쌓이면 정작 중요한 것을 놓칩니다.
그래서 순간값이 아니라 일정 구간의 통계값(평균·표준편차)으로 판정합니다. 잠깐 튄 값은 평균에 묻히고, 실제로 나빠진 상태만 남습니다.
| 방식 | 하는 일 |
|---|---|
| 통계 기반 임계치 | 평균·표준편차로 판정 — 순간적인 튐을 걸러냅니다 |
| 이벤트 필터링 | 같은 원인의 반복 알림을 묶습니다 |
| 알림 채널 | 이메일 · SMS · Webhook · Slack · MS Teams |
채널별 설정 방법은 OPENMARU APM 이벤트 설정 가이드에서 다룹니다.
사용자 인터페이스
HTML5 기반 웹 콘솔
따로 설치할 프로그램이 없습니다. 브라우저만 있으면 되므로 장애 상황에서 사무실 밖에 있어도 휴대전화로 확인할 수 있습니다.
| 특징 | 설명 |
|---|---|
| 반응형 디자인 | 데스크톱 · 태블릿 · 휴대전화 화면에 맞춰 배치가 바뀝니다 |
| 실시간 대시보드 | WebSocket 으로 값이 바뀔 때마다 갱신됩니다 — 새로 고침이 필요 없습니다 |
| 대시보드 구성 | 자주 보는 차트를 골라 자기 화면을 만듭니다 |
| 다크 모드 | 야간 상황실처럼 어두운 곳에서 보기 위한 어두운 테마 |
시스템 구성
아키텍처 개요
데이터는 한 방향으로 흐릅니다. 모니터링 대상 서버에 설치한 에이전트가 수집한 값을 APM 서버로 밀어 올리고, APM 서버가 집계해 저장소에 쌓으면, 운영자는 웹 콘솔로 그것을 읽습니다. APM 서버가 대상 서버로 먼저 접속하는 일은 없습니다 — 방화벽은 대상 서버에서 APM 서버로 나가는 방향만 열면 됩니다.
이 구조 때문에 설치도 대상 서버마다 따로 합니다. 서버 100 대를 보려면 에이전트를 100 번 설치하는 것이지, APM 서버에 서버 목록을 등록하는 방식이 아닙니다.
구성 요소
다섯 가지가 등장하지만 직접 설치하는 것은 에이전트 두 개뿐입니다. 나머지 셋(APM 서버· 저장소·웹 콘솔)은 APM 서버를 설치할 때 함께 올라갑니다.
| 구성 요소 | 어디에 있나 | 이 가이드에서 다루나 |
|---|---|---|
| WAS 에이전트 | 모니터링할 WAS 마다 | 다룹니다 — 3장 · 4장 |
| 시스템 에이전트 | 모니터링할 서버마다 | 다룹니다 — 2장 |
| APM 서버 · 데이터 저장소 · 웹 콘솔 | 한 곳에 모여 있음 | 아니요 — 설치 가이드가 따로 있습니다 |
WAS 에이전트 — 애플리케이션 안에서 벌어지는 일
자바 애플리케이션 안에 들어가 요청 하나가 어떤 경로로 처리됐는지 따라갑니다. WAS 기동
옵션에 -javaagent 를 한 줄 넣는 방식이라 애플리케이션 소스를 고치지 않습니다.
| 볼 수 있는 것 | 어떤 질문에 답하나 |
|---|---|
| 트랜잭션 실행 시간과 프로파일 | 어느 화면이 느린가, 그 안에서 어느 구간이 오래 걸리나 |
| SQL 쿼리 실행 정보 | 느린 원인이 데이터베이스인가, 어떤 쿼리인가 |
| 외부 호출 (HTTP · REST API) | 다른 시스템을 기다리느라 느린가 |
| JVM 메모리 (Heap · Non-Heap) | 메모리가 새고 있는가, 곧 부족해지는가 |
| 스레드 상태 | 어디서 멈춰 있는가, 데드락인가 |
| GC(Garbage Collection) 통계 | 멈춤이 GC 때문인가, 얼마나 자주·오래 멈추나 |
지원 WAS — Apache Tomcat · SpringBoot · JBoss EAP / WildFly · WebLogic · JEUS · Jetty. WAS 종류마다 옵션을 넣는 파일이 다릅니다. 4장에서 종류별로 어느 파일의 어디에 넣는지 다룹니다.
시스템 에이전트 — 서버와 그 서버에서 도는 제품
서버마다 한 벌 도는 별도 프로세스입니 다. WAS 에이전트와 달리 애플리케이션을 건드리지 않으므로, 자바가 아닌 서버(웹 서버·데이터베이스 서버)에도 설치합니다.
기본으로는 운영체제 자원만 봅니다 — CPU · 메모리 · 디스크 · 네트워크 · 프로세스 · 파일 시스템 사용량. 같은 서버에서 도는 제품까지 보려면 해당 플러그인을 켭니다.
| 플러그인 | 켜면 볼 수 있는 것 |
|---|---|
| Apache · NGINX · HAProxy | 요청 수, 응답 코드 분포, 워커·연결 상태 |
| MySQL · CUBRID | 세션 수, 느린 쿼리, 데이터베이스·브로커 상태 |
| Docker · CRI-O · containerd | 컨테이너별 CPU · 메모리 · 네트워크 |
켜는 것만 동작합니다. 쓰지 않는 플러그인을 켜 두면 없는 제품에 계속 상태를 물어보므로 수집 오류가 로그에 쌓입니다. 플러그인마다 대상 제품 쪽에 준비할 것이 따로 있습니다 — 웹 서버는 상태 페이지, 데이터베이스는 조회용 계정, 컨테이너는 런타임 소켓 읽기 권한입니다. 자세한 내용은 2장에 있습니다.
APM 서버 · 데이터 저장소 · 웹 콘솔
에이전트가 보낸 값을 받아 집계하고, 임계값과 견줘 이벤트를 판정하고, 저장소에 쌓는 쪽입니다. 통신은 WebSocket(기본 80 포트)이며, 연결은 에이전트가 겁니다.
저장소는 시계열 데이터와 이벤 트 이력을 나눠 보관하며 보존 기간은 설정으로 정합니다. 웹 콘솔은 그 데이터를 HTTP(S)로 읽어 대시보드 · 트랜잭션 분석(T-Map) · 통계 · 이벤트 이력 · 설정 화면으로 보여 줍니다. 같은 데이터를 프로그램에서 가져다 쓰려면 REST API 를 씁니다 — OPENMARU APM API 연동 가이드에서 다룹니다.
이 세 가지는 이 가이드의 범위가 아닙니다. APM 서버가 이미 설치돼 있고 접속할 주소를 알고 있다는 전제로 에이전트 설치만 설명합니다.
네트워크 구성
지원 환경
APM Server 설치 지원 환경
OPENMARU APM Server는 RHEL, CentOS 운영체제 환경에서 는 OPENMARU Installer를 이용하여 자동으로 설치할 수 있습니다.
지원 운영체제
| 운영체제 | 버전 | 아키텍처 |
|---|---|---|
| Red Hat Enterprise Linux (RHEL) | 7.x / 8.x / 9.x | x86_64 |
| CentOS | 7.x / 8.x | x86_64 |
| Rocky Linux | 8.x / 9.x | x86_64 |
| AlmaLinux | 8.x / 9.x | x86_64 |
- RHEL: 엔터프라이즈 환경, 장기 지원 필요 시
- Rocky Linux / AlmaLinux: CentOS 대체, 커뮤니티 지원
시스템 요구 사양
최소 / 권장 사양
| 항목 | 최소 환경 | 권장 환경 | 비고 |
|---|---|---|---|
| CPU | 8 Core | 16 Core | 가상머신 코어 기준 |
| Memory | 16 GB | 32 GB | 여유 메모리 확보 권장 |
| Disk | 500 GB | 1 TB 이상 | SSD 권장 |
| Network | 1 Gbps | 10 Gbps | 대규모 환경 시 |
시스템의 사양은 다음 요소에 크게 영향을 받습니다:
- 모니터링 대상 서버 수: 서버 수가 많을수록 더 많은 리소스 필요
- WAS 인스턴스 개수: 인스턴스당 데이터 수집량 증가
- 트랜잭션 처리량: TPS가 높을수록 더 많은 CPU/메모리 필요
- 데이터 보관 기간: 보관 기간이 길수록 더 많은 디스크 필요
사양 산정 예시:
- 소규모 (서버 10대, 인스턴스 20개): 8 Core, 16 GB, 500 GB
- 중규모 (서버 50대, 인스턴스 100개): 16 Core, 32 GB, 1 TB
- 대규모 (서버 100대 이상, 인스턴스 300개 이상): 32 Core, 64 GB, 2 TB 이상
네트워크 요구 사항
| 항목 | 요구 사항 |
|---|---|
| 포트 | 80 (HTTP/WebSocket) |
| 방화벽 | 에이전트 → 서버 방향 통신 허용 필요 |
에이전트 설치 지원 환경
WAS Agent 지원 환경
| WAS | 버전 | JDK 버전 |
|---|---|---|
| Apache Tomcat | 7.x / 8.x / 9.x / 10.x / 11.x | JDK 7, 8, 11, 17, 21, 25 |
| JBoss EAP | 6.x / 7.x / 8.x | JDK 8, 11, 17 |
| WildFly | 10.x ~ 30.x | JDK 8, 11, 17, 21 |
| WebLogic | 12c / 14c | JDK 8, 11 |
| WebSphere | 8.5 / 9.x | JDK 8, 11 |
| Jetty | 9.x / 10.x / 11.x | JDK 8, 11, 17, 21 |
- JDK 8: 모든 WAS에서 안정적 지원
- JDK 11: 엔터프라이즈 표준, 장기 지원 (LTS)
- JDK 17: 최신 LTS, 성능 개선
- JDK 21: 최신 LTS, 최신 기능 지원
- JDK 25: 최신 LTS. 최신 클래스 파일 형식을 읽고 쓰도록 에이전트가 갱신되었습니다
-noverify · -Xverify:none 을 쓰지 마십시오예전 문서와 설정 예제에는 클래스 적재 오류를 피 하려고 이 옵션을 넣으라는 안내가 있었습니다. 최신 에이전트에서는 필요하지 않으며, 넣으면 운영 중 JVM 이 비정상 종료될 수 있습니다. 기동 스크립트에 남아 있으면 지우십시오 — 자세한 내용은 6. 트러블 슈팅 가이드를 참고하십시오.
System Agent 지원 환경
| 운영체제 | 버전 | 아키텍처 |
|---|---|---|
| Linux | RHEL/CentOS 6.x ~ 9.x | x86_64 |
| Windows | Windows Server 2012 R2 / 2016 / 2019 / 2022 | x64 |
| Windows | Windows 10 / 11 | x64 |
| AIX | AIX 7.x | Power (ppc64) |
| HP-UX | HP-UX 11i v3 (11.31) | Itanium (ia64) |
| Solaris | Solaris 10 / 11 | SPARC, x86_64 |
- Linux: 대부분의 주요 배포판 지원 (RHEL, CentOS, AlmaLinux, RockyLinux 등)
- AIX: IBM Power 시스템 전용 Unix
- HP-UX: HP Integrity 서버 전용 Unix
- Solaris: Oracle SPARC 및 x86 시스템 지원
지원 웹 서버:
- Apache HTTP Server 2.2 / 2.4
- Nginx 1.x
에이전트 설치 방법
OPENMARU APM의 에이전트 설치는 두 가지 방법을 제공합니다:
1. Installer를 이용한 자동 설치 (권장)
OPENMARU Installer의 Provisioning 기능을 활용하면 에이전트가 자동으로 설치 및 구성됩니다.
장점:
- 빠른 설치: 몇 분 내 완료
- 자동 구성: 설정 파일 자동 생성
- 오류 방지: 수동 설정 오류 최소화
설치 프로세스:
1. APM Server UI 접속
2. 에이전트 추가 → 자동 설치 스크립트 다운로드
3. 대상 서버에서 스크립트 실행
4. 에이전트 자동 설치 및 구성 완료
- 대상 서버에서 APM 서버에 접속할 수 있어야 합니다 — 에이전트 파일을 APM 서버에서 내려받으므로 외부 인터넷은 필요하지 않습니다. 폐쇄망에서도 씁니다
- 스크립트를 실행할 권한이 있어야 합니다
2. 수동 설치
Provisioning 을 쓸 수 없거나 쓰지 않기로 한 경우, 다음 장의 절차대로 직접 설치합니다.
수동 설치를 고르는 경우:
- 대상 서버에서 APM 서버에 접속할 수 없다 — 망이 나뉘어 있어 파일을 따로 옮겨야 할 때
- 보안 정책상 스크립트 자동 실행이 막혀 있다
- 설치 위치나 계정을 사이트 규칙에 맞춰야 한다 — 자동 설치의 기본 경로를 쓸 수 없을 때
- 이미 운영 중인 WAS 에 붙인다 — 기동 스크립트를 이미 손봐 둔 상태라, 어느 줄이 어떻게 바뀌는지 확인하며 넣고 싶을 때
수동 설치 절차:
1. 에이전트 패키지 다운로드
2. 대상 서버에 압축 해제
3. 설정 파일 수정 (agent.conf)
4. WAS 시작 옵션 수정 (-javaagent)
5. WAS 재시작
| 상황 | 권하는 방법 |
|---|---|
| 새로 구축하는 서버 | 자동 설치 — 가장 빠릅니다 |
| 이미 운영 중인 WAS 에 붙이기 | 수동 설치 — 기존 기동 스크립트를 확인하며 넣습니다 |
| 쿠버네티스·OpenShift | Operator 자동 주입 — 이미지를 고치지 않고 업그레이드도 맡깁니다 |
| 망이 나뉘어 APM 서버에 못 붙는 경우 | 수동 설치 — 파일을 옮겨 설치합니다 |
어디에 설치하는가 — 장 고르기
같은 에이전트지만 붙이는 자리에 따라 절차가 다릅니다. 아래에서 자기 환경을 찾아 해당 장으로 가세요.
| 어디에 붙이나 | 어떻게 | 어디를 보나 |
|---|---|---|
| 서버의 OS·웹서버 | 시스템 에이전트 설치 | 2장 |
| 서버에 직접 설치한 WAS | JVM 옵션에 -javaagent | 3장 · 4장 |
| 컨테이너 이미지 | 이미지에 굽거나 S2I 로 빌드 | 5장 |
| 쿠버네티스·OpenShift 워크로드 | 라벨만 붙이면 자동 주입 | OPENMARU APM Operator 가이드 |
쿠버네티스 환경이면 Operator 의 자동 주입을 먼저 검토하세요. 이미지를 고치지 않아도 되고 업그레이드도 Operator 가 맡습니다. 5장의 방법은 Operator 를 쓸 수 없거나 이미지를 직접 관리해야 할 때를 위한 것입니다.
다음 단계
에이전트 설치에 대한 자세한 내용은 다음 장을 참조하세요:
- 시스템 에이전트 설치: 시스템 및 웹 서버 모니터링 에이전트 설치
- WAS 에이전트 설치: Java WAS 모니터링 에이전트 설치
- WAS 종류별 에이전트 설정: WAS 별 설정 방법
- 컨테이너·쿠버네티스에 설치: 이미지 빌드 · S2I · Pod 환경변수
- 트러블 슈팅: 설치 중 발생하는 문제 해결