• Link to Facebook
  • Link to LinkedIn
  • Link to X
  • Link to Youtube
  • 로그인
  • 회원가입
  •  한글 한글 한글 ko
  • English English 영어 en
OPENMARU APM
  • 오픈마루
    • 회사소개
    • 연혁
    • 오픈마루 CI
  • 제품
    • Cloud APM
      • Application 모니터링
      • Openshift & Kubernetes 모니터링
      • WEB/WAS 모니터링
      • URL 모니터링
      • Cubrid 모니터링
    • Cluster
    • Dashboard
    • COP
    • CogentAI
    • iAP
    • Observability
  • 오픈소스
    • 쿠버네티스
    • 아파치 톰캣
    • CentOS
  • 레드햇
    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat JBoss EAP
  • 견적 문의
    • 견적문의
    • 가격 안내
  • 기술 지원
  • 조달물품
    • G2B 딜 등록
    • 조달물품 OPENMARU APM
    • 조달물품 OPENMARU Cluster
    • 조달물품 OPENMARU iAP
    • 혁신장터
    • 찾아가는 클라우드 네이티브 세미나
  • 레퍼런스
  • 문서
  • 블로그
    • 오픈마루
    • 구매 관련
    • 기술 지원
    • 트러블 슈팅
    • White Paper
    • Youtube
  • Click to open the search input field Click to open the search input field Search
  • Menu Menu

AIOps – 서버 자원 사용량 분석

서버 자원 사용량 분석을 AI에게 한 문장으로 물으면 부하 구간 표와 증설 결론, 제안, Word 보고서까지 한 번에 받습니다. 41초 영상과 제품 화면 7장으로 증설 판단 과정을 주장 단위로 정리했습니다.

서버 자원 사용량 분석 영상 정리 글 배너

영상으로 먼저 보기: 41초에 담은 서버 자원 사용량 분석 과정


OPENMARU APM의 AI Insight에 한 문장을 묻고 부하 구간 표, 결론, 제안, Word 보고서를 차례로 받는 과정을 41초로 담은 영상입니다.

영상에서 다루는 순서는 다음과 같습니다.

  • 질문을 시작하는 WAS 대시보드 (0:07)
  • AI 패널에 보내는 한 문장 (0:11)
  • 날짜와 시간대로 나눈 부하 구간 표 (0:18)
  • 결론, 자원 증설이 필요합니다 (0:24)
  • 무엇을 어떻게 늘릴지 적은 제안 (0:29)
  • Word 문서로 내보낸 보고서 (0:32)

이 영상이 답하는 7가지 질문 정리


영상의 내용을 질문으로 바꾸면 일곱 가지이고, 아래 일곱 개 절이 이 순서대로 답합니다.

  1. 서버 증설 판단은 어느 화면에서 시작하는가?
  2. AI Insight에는 무엇을 어떻게 물어야 하는가?
  3. 부하 구간은 어떤 단위와 항목으로 정리되는가?
  4. 증설이 필요하다는 결론은 무엇을 근거로 나오는가?
  5. 결론 다음에는 무엇을 얼마나 늘리라고 제안하는가?
  6. 분석 결과는 어떤 형태로 내보내는가?
  7. 내보낸 보고서는 화면의 분석과 얼마나 같은가?

서버 증설 판단이 운영 대시보드에서 시작되는 이유


서버 증설 판단에 필요한 데이터는 이미 APM이 모으고 있습니다. 영상의 첫 문장은 “서버 증설, 아직도 감으로 결정하십니까?”이고, 이어서 “지금 보고 있는 대시보드에서”라고 말합니다. 분석을 위해 다른 도구로 옮겨 갈 필요가 없다는 뜻입니다.

화면은 OPENMARU APM의 WAS 대시보드입니다. WAS(Web Application Server, 웹 애플리케이션 서버)는 업무 프로그램이 실제로 실행되는 서버를 말하고, APM(Application Performance Management, 애플리케이션 성능 관리)은 그 위에서 도는 요청의 처리 상태를 계속 기록하는 도구입니다. 대시보드에는 shopping이라는 애플리케이션 그룹이 선택되어 있고, 그 아래 인스턴스 다섯 개가 탭으로 나열되어 있습니다.

OPENMARU APM 대시보드는 shopping 애플리케이션의 요청 흐름과 TPS, 응답시간, 사용자 만족도를 한 화면에 보여준다.

▲ 질문을 시작하는 자리, WAS 대시보드 (영상 0:07)

대시보드의 위쪽은 지금 들어오는 요청의 흐름과 인스턴스별 처리 건수를, 아래쪽은 활성 사용자, TPS(Transactions Per Second, 초당 처리 건수), 평균 응답시간, 사용자 만족도, JVM(Java Virtual Machine, 자바 가상 머신) 힙 사용량을 그래프로 그립니다. 오른쪽 숫자 패널에는 TPS 102.8, 평균 응답시간 732ms, 활성 사용자 57이 찍혀 있습니다.

이 화면이 보여 주는 것은 지금 이 순간입니다. 증설 판단에는 지난 며칠 동안 어느 시간대에 얼마나 찼는지가 필요한데, 실시간 그래프는 그 질문에 바로 답하지 않습니다. 지금까지 운영자는 기간을 바꿔 가며 통계 화면을 열고, 값을 표 계산 프로그램에 옮겨 적은 뒤 보고서를 따로 썼습니다. 영상이 ‘감’이라고 부른 것은 이 수고를 건너뛰고 체감으로 정하는 증설을 가리킵니다.

한 문장으로 끝나는 서버 자원 사용량 분석 요청 방식


요청은 “전체 자원 사용량 분석” 한 문장입니다. 나레이션은 “AI 인사이트에게, 한 문장만 물어보세요”라고 말하고, 화면에서는 대시보드 오른쪽에 열린 AI 패널에 이 문장이 파란 말풍선으로 올라갑니다.

패널은 대시보드를 덮지 않고 옆에 열립니다. 질문에는 기간도, 서버 이름도, 지표 이름도 없습니다. 어느 애플리케이션 그룹을 볼지는 대시보드에서 이미 골라 두었고, 무엇을 서버 자원으로 볼지는 AI Insight가 정합니다.

AI 패널에 「전체 자원 사용량 분석」 한 문장을 보내자 관련 도구를 선택하고 컨텍스트를 준비한다.

▲ 「전체 자원 사용량 분석」 한 문장을 보낸다 (영상 0:11)

질문을 보내면 말풍선 아래에 “관련 도구를 선택하고 컨텍스트를 준비하고 있습니다”라는 진행 문구와 경과 시간이 나타납니다. 이 문구는 AI Insight가 답을 지어내는 것이 아니라 APM에 쌓인 데이터를 조회하는 도구를 골라 실행한다는 점을 알려 줍니다. 서버 자원 사용량 분석에 쓰이는 CPU 사용률, 메모리 사용률, 스왑, 사용자 수는 모두 APM이 수집해 둔 값입니다.

서버 자원 사용량 분석에서 운영자에게 달라지는 점은 질문의 단위입니다. 통계 화면에서는 “6월 22일 11시의 CPU 평균”처럼 값 하나를 물어야 했습니다. AI 패널에서는 “자원이 충분한가”라는 판단 자체를 묻습니다. 어떤 값을 어떤 순서로 볼지는 묻는 쪽이 아니라 답하는 쪽이 정리합니다.

날짜와 시간대로 부하 구간을 나누는 표의 구조


첫 번째 답은 부하 OS 목록이라는 표입니다. 나레이션은 “날짜별, 시간대별 부하 구간을 표로 정리하고”라고 설명합니다. 표의 한 줄은 ‘어느 날 어느 시간대’이고, 그 구간에서 서버가 얼마나 찼는지를 열로 펼칩니다.

부하 OS 목록 표는 날짜와 시간 구간마다 평균 액티브 유저, CPU·메모리 사용률, SWAP 사용 여부, 부하 판단 사유를 적는다.

▲ 날짜·시간대별 부하 구간 표 (영상 0:18)

표의 열은 아홉 개입니다. 날짜와 요일, 시간 구간, 평균 액티브 유저, 서버 주소, 평균 CPU 사용률, 평균 메모리 사용률, 스왑(SWAP, 메모리가 모자랄 때 디스크를 메모리처럼 빌려 쓰는 공간) 사용 여부, CPU 대기 비율, 부하 판단 사유입니다. CPU와 메모리는 평균과 최댓값을 함께 적습니다. 화면에 보이는 구간 가운데 다섯 줄을 옮기면 다음과 같습니다.

날짜 시간 구간 평균 액티브 유저 CPU 평균 / 최대 메모리 평균 / 최대
6월 25일(목) 09:00~10:00 598 72.5% / 75% 77.4% / 81.7%
6월 24일(수) 11:00~12:00 886 81.5% / 88% 77.3% / 82.8%
6월 23일(화) 11:00~12:00 907 83.3% / 86.3% 77.8% / 81.1%
6월 23일(화) 15:00~16:00 604 77.2% / 83% 78.3% / 83.5%
6월 22일(월) 11:00~12:00 886 86.3% / 86.3% 78.5% / 83.2%

이 표에서 세 가지가 읽힙니다. 첫째, 구간은 하루에 두 번, 오전 11시대와 오후 3시대에 몰려 있습니다. 업무 시스템의 사용이 몰리는 시간과 겹칩니다. 둘째, 평균 CPU 사용률이 가장 높은 구간은 6월 22일 11시대의 86.3%이고, 순간 최댓값은 6월 24일 11시대의 88%입니다. 셋째, 메모리는 날짜와 시간대에 상관없이 76~78%대에 머물고 최댓값은 83.5%입니다.

영상 설명란도 같은 세 숫자를 사례로 적었습니다. 평균 CPU 사용률 최고 86.3%, CPU 최대 88%, 메모리 최대 83.5%이며, 화면의 수치는 데모 환경에서 측정한 값이라고 밝힙니다.

서버 자원 사용량 분석을 손으로 할 때 가장 시간이 드는 일이 이 표를 만드는 일입니다. 기간을 정하고, 시간 단위로 묶고, 평균과 최댓값을 각각 뽑고, 사용자 수와 나란히 놓아야 합니다. 표가 먼저 나오면 서버 자원 사용량 분석은 집계가 아니라 읽기에서 출발합니다.

사용자 수가 같은 표에 들어 있다는 점은 따로 짚을 만합니다. 인프라 모니터링만 쓰는 환경에서는 CPU 사용량이 한도를 넘었다는 사실까지만 알 수 있고, 그때 사용자가 얼마나 있었는지는 다른 도구에서 찾아야 합니다. 운영자는 세션 기록, 트랜잭션 기록, 인프라 지표를 각각 뽑아 시간대를 맞춰 손으로 이어 붙였고, 이 작업에 몇 시간에서 며칠이 걸리기도 했습니다. APM은 요청과 사용자, 서버 자원을 같은 시간축에 기록하므로 이 이어 붙이기가 필요 없습니다.

사용자 수가 늘어난 구간에서 사용률이 함께 올랐다면 증설의 사유는 업무량 증가입니다. 사용자 수는 그대로인데 사용률만 올랐다면 증설보다 애플리케이션 점검이 먼저입니다. 두 경우를 가르는 데 필요한 열이 표 안에 이미 있습니다.

결론을 먼저 말하는 요약과 부하 판단 기준


표 다음에는 판단 기준과 결론이 옵니다. 나레이션은 “결론부터 말합니다. 자원 증설이 필요합니다”라고 말합니다. 화면의 요약 표 마지막 칸에도 같은 문장이 초록 체크 표시와 함께 적혀 있습니다.

요약 표의 결론 칸은 자원 증설이 필요하다고 적고, 그 위에 부하 판단 기준을 밝힌다.

▲ 판단 기준과 요약, 결론 「자원 증설이 필요합니다」 (영상 0:24)

요약 위의 노란 경고 상자가 어떤 기준으로 부하를 판정했는지 밝힙니다. 내용은 세 가지입니다.

  • 부하 판단 사유는 CPU 사용률 60% 초과를 기준으로 했고, 모든 구간이 부하 노드에 해당한다.
  • 스왑 사용 여부는 매 구간에서 스왑 사용량이 50%여서 ‘사용’으로 표시했다.
  • CPU 대기 비율은 기준보다 훨씬 낮아 부하 사유에 들지 않았다.

요약 표는 세 줄입니다. ‘전체 자원 상태’는 CPU 사용률이 높은 수준에서 이어지고 메모리 사용률이 70~80% 사이에 고정되어 있다고 적습니다. ‘부하 패턴’은 평균 액티브 유저가 900명 안팎으로 늘어나는 날에 CPU와 메모리 사용률이 함께 오른다고 적습니다. ‘결론’은 CPU 사용률이 지속적으로 80% 이상이고 메모리도 80% 근처까지 쓰이므로 자원 증설이 필요하다는 것입니다.

기준이 답과 함께 나온다는 점이 중요합니다. “증설이 필요하다”는 문장만 있으면 받아들일지 말지를 정할 수 없습니다. 60%라는 문턱이 적혀 있으면 운영자는 자기 조직의 기준과 견줄 수 있습니다. 조직의 문턱이 70%라면 같은 표를 놓고 다시 셀 수 있습니다.

요약 문장은 표와 나란히 읽어야 합니다. 표에는 평균 CPU 사용률이 69.8%나 72.5%인 구간도 있으므로, 구간마다의 정확한 값은 요약이 아니라 표에서 확인합니다. AI 패널 아래쪽에도 응답을 다시 확인해 달라는 안내가 항상 표시됩니다. 결론을 보고에 쓰기 전에 표의 어느 줄이 그 결론을 받치는지 짚어 두면, 질문을 받았을 때 숫자로 답할 수 있습니다.

증설 범위를 네 갈래로 좁히는 제안의 구조


결론 뒤에는 제안 네 가지가 이어집니다. 나레이션은 “무엇을 어떻게 늘릴지, 제안까지”라고 말합니다. 증설이 필요하다는 판단에서 멈추지 않고 대상과 크기를 적습니다.

제안은 CPU·메모리 스케일링, SWAP 사용 모니터링, ActiveUser와 자원 사용 연관성, 모니터링 알림 설정 네 가지다.

▲ 제안 네 가지 (영상 0:29)

화면의 제안을 표로 옮기면 다음과 같습니다.

순서 제안 화면에 적힌 내용
1 CPU 및 메모리 스케일링 노드 1대를 인스턴스 1~2개 더 늘리거나 CPU·메모리 할당량을 20~30% 올린다. 피크 트래픽에 대비해 오토스케일 설정을 검토한다.
2 스왑 사용 모니터링 스왑 사용 비율이 50%로 일정하게 높다. 물리 메모리가 더 필요하면 메모리 증설을 고려하고, 메모리 사용량을 주기적으로 점검한다.
3 사용자 수와 자원 사용의 연관성 액티브 유저가 늘 때 CPU와 메모리 사용률이 함께 오른다. 사용자가 몰리는 시점에는 미리 리소스 할당을 늘린다.
4 모니터링 알림 설정 CPU 평균 사용률 70% 초과 또는 메모리 사용률 80% 초과에 알림을 건다. 알림 시점에 스케일링이 실행되도록 자동화한다.

네 제안은 성격이 다릅니다. 1번은 지금 늘릴 양입니다. 서버를 더 두는 방법과 한 서버의 할당량을 키우는 방법을 함께 적고 20~30%라는 범위를 줍니다. 2번은 지켜볼 위험입니다. 스왑이 계속 쓰인다는 것은 물리 메모리가 빠듯하다는 신호라서, CPU만 늘리고 끝내면 안 된다는 점을 짚습니다. 3번은 증설 시점입니다. 사용률은 사용자 수를 따라 움직이므로 사용자가 늘 일정이 보이면 먼저 움직이라는 뜻입니다. 4번은 다음번 판단을 앞당기는 장치입니다. 문턱을 넘는 순간 알림이 오면 다음 서버 자원 사용량 분석은 문제가 커지기 전에 시작됩니다.

예산을 요청하는 자리에서는 1번이 금액의 근거가 되고, 2번과 3번이 그 금액의 사유가 됩니다. 4번은 증설 뒤에도 같은 상황이 오면 어떻게 알아챌지에 대한 답입니다.

3번 제안은 일정이 보이는 부하에 특히 쓸모가 있습니다. 행사나 프로모션처럼 짧은 기간에 접속자가 급증하는 날은 미리 알 수 있는 경우가 많습니다. 지난 구간의 표에서 사용자 수와 사용률이 어떤 비율로 함께 움직였는지 봐 두면, 예상 접속자 수에 맞춰 얼마나 먼저 늘려 둘지를 셈할 수 있습니다.

분석 결과를 Word 보고서로 내보내는 과정


분석은 Word 문서로 내보냅니다. 나레이션은 “보고서는 워드 문서로 바로 받습니다”라고 말합니다. 답변 아래의 내보내기 버튼을 누르면 문서 파일이 만들어지고, 영상은 그 파일을 Word에서 연 화면을 보여 줍니다.

내보낸 Word 문서의 첫 쪽에는 Cogent AI 메시지 보고서라는 제목과 생성 시각이 찍힌다.

▲ Word 로 내보낸 보고서 표지 (영상 0:32)

첫 쪽은 표지입니다. 제목과 날짜가 가운데 놓이고 그 아래에 생성 시각이 초 단위로 찍혀 있습니다. 영상은 이 문서를 “표·요약·제안까지, 6쪽 문서”라고 소개합니다. 표지 다음에 부하 OS 목록, 요약, 제안이 로마 숫자 번호가 붙은 장으로 이어집니다.

내보내기가 따로 있는 까닭은 분석을 읽는 사람과 결정하는 사람이 다르기 때문입니다. 운영자는 AI 패널에서 답을 읽지만, 증설을 승인하는 사람은 APM 화면을 열지 않습니다. 화면을 갈무리해 붙이거나 표를 다시 그리는 일이 보고서 작성 시간의 대부분을 차지합니다. 서버 자원 사용량 분석 결과를 편집할 수 있는 문서로 받으면 운영자는 조직의 양식에 맞춰 머리말을 붙이고 의견을 덧쓰는 일만 하면 됩니다.

생성 시각이 표지에 남는다는 점도 쓸모가 있습니다. 서버 자원 사용량 분석은 기간이 바뀌면 결과가 달라지므로, 보고서가 언제의 데이터를 읽었는지가 문서 자체에 적혀 있어야 나중에 다시 비교할 수 있습니다.

보고서의 표가 화면과 같은 값을 담는 이유


보고서 2쪽에는 화면에서 본 부하 OS 목록 표가 그대로 들어갑니다. 열의 이름과 순서, 날짜와 시간 구간, CPU와 메모리의 평균과 최댓값이 화면과 같습니다.

Word 보고서 2쪽에는 화면에서 본 부하 OS 목록 표가 같은 열 구성으로 들어간다.

▲ 보고서 안의 부하 구간 표 (영상 0:33)

문서의 표는 화면의 표를 사진으로 찍은 것이 아니라 Word의 표입니다. 줄을 지우거나 열을 더할 수 있고, 조직이 쓰는 글꼴과 색으로 바꿀 수 있습니다. 6월 25일 9시대의 72.5%부터 6월 20일의 구간까지, 화면에서 스크롤을 내려야 보이던 줄이 문서에서는 한 표로 이어집니다.

값이 같다는 것은 근거가 한 벌이라는 뜻입니다. 운영자가 화면에서 확인한 숫자와 결재권자가 문서에서 읽는 숫자가 다르면, 보고 자리의 시간은 숫자를 맞추는 데 쓰입니다. 화면의 답을 그대로 문서로 옮기면 이 어긋남이 생길 자리가 없습니다. 요약과 제안도 같은 방식으로 3쪽 이후에 들어가므로, 문서 한 편이 표에서 결론을 거쳐 조치까지 이어지는 구성을 갖춥니다.

영상의 마지막 문장은 “질문 하나로, 용량 계획까지”입니다. 용량 계획은 앞으로 필요한 서버 자원을 미리 셈해 준비하는 일을 말합니다. 표, 결론, 제안, 문서가 한 번의 질문에서 나오면 이 계획의 초안이 그 자리에서 만들어집니다.

영상 밖의 보충: 사용률 숫자를 증설 근거로 읽는 기준


사용률 하나만으로 증설을 정하지 않는다는 것이 성능 분석의 오래된 원칙입니다. 브렌던 그레그의 USE 방법론은 자원마다 사용률, 포화도, 오류 세 가지를 함께 보라고 권합니다. 사용률은 자원이 일한 시간의 비율이고, 포화도는 처리하지 못해 밀린 일의 양입니다. 사용률이 높아도 밀린 일이 없으면 자원은 제 몫을 하고 있는 것이고, 사용률이 낮아도 밀린 일이 있으면 문제가 있는 것입니다.

영상의 표가 CPU 사용률 옆에 스왑 사용 여부와 CPU 대기 비율을 둔 것은 이 원칙과 맞습니다. 스왑이 계속 쓰이는 것은 메모리의 포화 신호입니다. 구글의 SRE 책도 서비스에서 지켜볼 네 가지 신호 가운데 하나로 포화도를 꼽고, 대부분의 시스템은 사용률이 100%에 이르기 전에 성능이 떨어지기 시작하므로 목표 사용률을 미리 정해 두라고 설명합니다.

사용률을 사용자 수와 나란히 놓는 것에도 근거가 있습니다. 접속 패턴은 시간대에 따라 크게 달라지므로, 어느 한 시점의 사용자 수나 사용률 하나로 서버 용량을 정하면 평소에는 자원이 남고 사용자가 몰릴 때는 모자라는 일이 함께 생깁니다. 날짜와 시간대로 구간을 나눠 사용자 수와 사용률을 같이 적은 표는 이 두 경우를 한 번에 드러냅니다.

평균과 최댓값을 함께 보는 것에도 까닭이 있습니다. 한 시간 평균이 80%라는 것은 그 한 시간 안에 80%를 넘은 순간이 여러 번 있었다는 뜻입니다. 평균만 보면 짧은 포화가 가려집니다. 표가 평균 81.5% 옆에 최대 88%를 적은 것은 이 차이를 보여 주기 위해서입니다.

제안에 나온 오토스케일은 부하에 따라 서버나 컨테이너의 수를 자동으로 늘리고 줄이는 기능입니다. 쿠버네티스에서는 수평 파드 오토스케일러가 이 일을 맡고, 목표 CPU 사용률을 정해 두면 그 값에 맞춰 파드 수를 조절합니다. 자동으로 늘리는 구성에서도 목표 사용률을 몇 퍼센트로 둘지는 사람이 정해야 하고, 그 값을 정하는 근거가 서버 자원 사용량 분석입니다.

컨테이너 환경에서 자원 사용량을 어떻게 수집하고 읽는지는 OPENMARU APM 활용 사례로 이해하는 쿠버네티스 모니터링 글에서 이어서 볼 수 있습니다.

핵심 정리: 한 표로 보는 서버 자원 사용량 분석의 결과물


AI Insight는 질문 한 문장을 표, 결론, 제안, 문서 네 가지로 바꿉니다. 영상의 흐름을 단계로 나누면 다음과 같습니다.

단계 화면에서 일어난 일 운영자가 얻는 것 영상 시각
시작 WAS 대시보드에서 AI 패널을 연다 화면을 옮기지 않는 분석 0:07
질문 “전체 자원 사용량 분석” 한 문장 지표 이름을 몰라도 되는 요청 0:11
표 날짜·시간대별 부하 OS 목록 평균 CPU 최고 86.3%, 최대 88% 0:18
결론 판단 기준과 요약 표 증설이 필요하다는 판단과 60% 기준 0:24
제안 스케일링, 스왑, 사용자 연관성, 알림 늘릴 양 20~30%와 알림 문턱 0:29
문서 Word 보고서 6쪽 편집해서 올릴 수 있는 보고 자료 0:32

증설 판단에서 사람이 할 일은 남아 있습니다. 기준이 조직에 맞는지 보고, 표의 값으로 결론을 확인하고, 제안의 크기를 예산과 맞추는 일입니다. 서버 자원 사용량 분석에서 집계와 문서 작성이 줄어든 만큼 이 판단에 시간을 쓸 수 있습니다. 증설한 뒤에도 같은 표를 다시 받아 사용률이 목표 아래로 내려왔는지 점검해야 합니다.

자주 묻는 질문


서버 자원 사용량 분석은 무엇을 보는 일인가요?

서버 자원 사용량 분석은 CPU와 메모리가 언제 얼마나 찼는지를 기간별로 정리해 증설이 필요한지 판단하는 일입니다. 영상의 AI Insight는 날짜와 시간 구간마다 평균 액티브 유저, CPU와 메모리의 평균과 최댓값, 스왑 사용 여부, CPU 대기 비율을 한 표에 놓았습니다. 사용률만 따로 보지 않고 사용자 수와 나란히 놓는다는 점이 핵심입니다.

AI Insight에는 어떻게 질문하나요?

대시보드 옆 AI 패널에 평소 쓰는 문장으로 묻습니다. 영상에서는 “전체 자원 사용량 분석”이라는 한 문장만 보냈습니다. 기간이나 지표 이름을 적지 않아도 되고, 분석할 애플리케이션 그룹은 대시보드에서 이미 선택한 것을 따릅니다. 질문을 보내면 AI Insight가 관련 도구를 골라 APM에 쌓인 데이터를 조회합니다.

영상의 사례에서는 왜 증설이 필요하다고 판단했나요?

CPU 사용률이 지속적으로 80% 이상이고 메모리도 80% 근처까지 쓰이고 있었기 때문입니다. 표에서 평균 CPU 사용률은 최고 86.3%, 순간 최댓값은 88%, 메모리 최댓값은 83.5%였습니다. AI Insight는 CPU 사용률 60% 초과를 부하 기준으로 삼았고 모든 구간이 이 기준을 넘었습니다. 화면의 수치는 데모 환경에서 측정한 값입니다.

부하를 판단한 기준은 바꿀 수 없나요?

기준은 답과 함께 표시되므로 조직의 기준과 견주어 다시 읽을 수 있습니다. 영상의 답변은 CPU 사용률 60% 초과를 부하 기준으로 썼다고 경고 상자에 밝혔습니다. 조직의 문턱이 70%나 80%라면 같은 표에서 그 값을 넘는 구간만 다시 세면 됩니다. 표에 평균과 최댓값이 함께 있어 어느 쪽을 기준으로 삼을지도 고를 수 있습니다.

제안에는 어떤 내용이 들어 있나요?

제안은 CPU와 메모리 스케일링, 스왑 사용 모니터링, 사용자 수와 자원 사용의 연관성, 모니터링 알림 설정 네 가지입니다. 스케일링은 인스턴스를 1~2개 더 두거나 할당량을 20~30% 올리라고 적었습니다. 알림은 CPU 평균 사용률 70% 초과 또는 메모리 사용률 80% 초과를 문턱으로 제시했습니다. 늘릴 양과 지켜볼 지표를 함께 주는 구성입니다.

Word 보고서에는 무엇이 담기나요?

화면에서 본 부하 OS 목록 표와 요약, 제안이 같은 내용으로 담깁니다. 영상의 문서는 6쪽이고 첫 쪽 표지에 제목과 생성 시각이 찍혀 있습니다. 표는 그림이 아니라 Word의 표로 들어가므로 줄과 열을 고칠 수 있습니다. 운영자는 조직의 양식에 맞춰 머리말과 의견을 붙여 바로 보고에 쓸 수 있습니다.

AI가 낸 증설 결론을 그대로 보고해도 되나요?

결론은 출발점으로 쓰고, 표의 값으로 직접 확인한 뒤 보고하는 것이 안전합니다. AI 패널에도 응답을 다시 확인해 달라는 안내가 항상 표시됩니다. 요약 문장은 전체 흐름을 말하므로 구간별 정확한 값은 표에서 읽어야 합니다. 결론을 받치는 줄이 어느 날 어느 시간대인지 짚어 두면 보고 자리에서 숫자로 답할 수 있습니다.

참고 리소스


서버 자원 사용량 분석과 증설 판단을 더 살펴볼 때 볼 원 영상과 이어서 읽을 글, 인용한 문서를 모았습니다.

  • APM AI Insight 사례, 장애 알람에서 근본 원인까지 30초
  • APM이란? 서버 모니터링으로 못 잡는 장애, 개념부터 도입까지
  • APM 핵심 지표 읽는 법
  • WAS 모니터링 가이드 — JVM 힙·스레드·커넥션 풀 관측 포인트
  • WAS 성능 튜닝 — JVM 힙·GC·스레드 풀·커넥션 풀 기준값 가이드
  • 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모
  • AIOps란? 안정적인 IT 운영을 위한 특급 비법
  • 서버 증설, 감 대신 AI에게 묻다 — 클라우드네이티브TV — 이 글이 정리한 원 영상
  • The USE Method — Brendan Gregg — 사용률·포화도·오류로 자원을 점검하는 방법
  • Google SRE Book: Monitoring Distributed Systems — 포화도를 포함한 네 가지 신호
  • Kubernetes Horizontal Pod Autoscaling — 목표 사용률에 맞춘 자동 확장
  • Kubernetes Resource Management for Pods and Containers — CPU·메모리 요청과 제한

JBoss EAP 7

JBoss EAP 시작과 역사 그리고 Wildfly 와의 차이점

2017-11-01/카테고리: JBoss/작성자: OM marketing
자세히 보기
https://i0.wp.com/www.openmaru.io/wp-content/uploads/2024/08/image-6.png?fit=2000%2C1111&ssl=1 1111 2000 OM marketing https://www.openmaru.io/wp-content/uploads/2020/11/logo@2x.png OM marketing2017-11-01 17:10:212024-08-19 16:08:04JBoss EAP 시작과 역사 그리고 Wildfly 와의 차이점
Apache , Tomcat , JBoss , Wildfly 설치 보고서

OpenShift Auto Scaling 데모, 동작 원리 그리고 개념 이해 (Docker Based)

2017-10-23/카테고리: Kubernetes, OpenShift, Red Hat/작성자: OM marketing
자세히 보기
https://i0.wp.com/www.openmaru.io/wp-content/uploads/2022/08/was%EC%9A%B4%EC%98%81%EC%A0%95%EB%B3%B4-%EC%A0%9C%EA%B3%B5_facebook-banner.png?fit=1200%2C627&ssl=1 627 1200 OM marketing https://www.openmaru.io/wp-content/uploads/2020/11/logo@2x.png OM marketing2017-10-23 13:22:172026-08-26 13:46:37OpenShift Auto Scaling 데모, 동작 원리 그리고 개념 이해 (Docker Based)
JBoss 고객이라면 반드시 알아야 하는 운영 노하우 공유

JBoss 고객이라면 반드시 알아야 하는 운영 노하우 공유 — 실무자가 꼭 알아야 할 이유

2017-02-07/카테고리: JBoss, Red Hat/작성자: OM marketing
자세히 보기
https://i0.wp.com/www.openmaru.io/wp-content/uploads/2024/08/image-3.png?fit=2000%2C1111&ssl=1 1111 2000 OM marketing https://www.openmaru.io/wp-content/uploads/2020/11/logo@2x.png OM marketing2017-02-07 21:22:362026-09-07 15:35:34JBoss 고객이라면 반드시 알아야 하는 운영 노하우 공유 — 실무자가 꼭 알아야 할 이유
Page 165 of 175«‹163164165166167›»

Recent Posts

  • 서버 사이징 어떻게 결정하시나요? AIOps 로 서버 자원 사용량 분석 2026-10-13
  • 사용자 활동 추적 사례, 특정 사용자가 특정 시간에 왜 느렸는지 알 수 있나요? 2026-10-13
  • APM AI Insight, 장애 알람에서 근본 원인까지 30초 2026-10-13
  • AI Native News | 데모에선 완벽했던 AI 에이전트, 운영에선 왜 멈출까? 2026-10-08
  • AI가 장애 원인까지 짚는다 — LLM AIOps 실전 데모 4선 2026-10-07

Categories

  • Blog
    • blog-price
    • blog-support
    • blog-trouble-shooting
    • blog-whitepaper
  • OPENMARU
    • APM
    • Cluster
    • Cogent AI
    • Dashboard
    • iAP
    • Newsletter
    • Observability
  • Technical
    • Cloud
    • Container
    • JBoss
    • Kubernetes
    • Linux
    • Microservices Architecture
    • OpenShift
    • Red Hat
  • Youtube
  • 미분류

이메일로 블로그 구독하기

이 블로그를 구독하고 이메일로 새글의 알림을 받으려면 이메일 주소를 입력하세요

태그

AI AIOps APM cloud Cloud Native Container DevOps Docker jboss JBoss EAP Kubernetes Kubernetes 모니터링 linux LLM MSA MSAP.ai Native Observability OPENMARU OPENMARU APM OpenShift RAG Red Hat RHEL tomcat WAS Wildfly 가상화 네이티브 도커 레드햇 리눅스 마이크로서비스 모니터링 애플리케이션 오픈마루 오픈마루 APM 오픈시프트 옵저버빌리티 인공지능 주간 컨테이너 쿠버네티스 클라우드 클라우드 네이티브

Search

Search Search

오픈마루

04778 서울시 성동구 뚝섬로1길 31 906 호
(성수동1가, 서울숲M타워)

Tel : 02-469-5426 | Fax : 02-469-7247
Email : sales@openmaru.io

  • OPENMARU CLOUD APM
    • Application 모니터링
    • Openshift & Kubernetes 모니터링
    • WEB/WAS 모니터링
    • URL 모니터링
    • Cubrid 모니터링
  • Cluster
  • Dashboard
  • COP
  • CogentAI
  • iAP
  • Observability

  • 가격안내
  • 고객 레퍼런스
  • 고객지원
    • 문서
    • 사용자가이드
    • 기술지원
  • 블로그
    • 오픈마루
    • 구매 관련
    • 기술 지원
    • 트러블 슈팅
  • 이용약관
  • 개인정보처리방침
  • 서비스수준협약
  • 회사소개
Copyright © OPENMARU, Inc. All Rights Reserved. - powered by Enfold WordPress Theme
  • Link to Facebook
  • Link to LinkedIn
  • Link to X
  • Link to Youtube
Link to: 사용자 활동 추적 사례, 특정 사용자가 특정 시간에 왜 느렸는지 알 수 있나요? Link to: 사용자 활동 추적 사례, 특정 사용자가 특정 시간에 왜 느렸는지 알 수 있나요? 사용자 활동 추적 사례, 특정 사용자가 특정 시간에 왜 느렸는지...사용자 활동 추적으로 느리다는 사용자 한 명에서 원인 SQL 한 줄까지 찾는 과정을 정리한 글의 대표 이미지
Scroll to top Scroll to top Scroll to top
  • 한글
  • English