흩어져 있는 지표는 그 자체로는 아무것도 설명하지 못합니다.
CPU·메모리·워크프로세스·DB는 같은 시간축 위에 함께 놓일 때 비로소 원인을 가리키는 데이터가 됩니다.
OWLens Context Analyzer는 장애 시점의 모든 구성요소를 하나의 화면에 정렬해, 특정 전문가의 경험 없이도 원인을 규명할 수 있게 합니다.
장애가 발생하면 여러 화면을 순서대로 확인합니다. SM50에서 워크프로세스, ST06에서 OS 자원, ST02에서 SAP 메모리, ST22에서 덤프, SM21에서 시스템 로그를 각각 열고, 그 조각들을 머릿속에서 같은 시각으로 맞춰 이어 붙여야 원인의 윤곽이 잡힙니다. 그리고 그 작업을 제대로 수행할 수 있는 인원은 조직에 한두 명뿐입니다.
SM50·SM66은 현재 상태만 제공합니다. 장애가 지나가면 그 시점에 어느 워크프로세스가 무엇을 점유하고 있었는지 확인할 방법이 남지 않습니다.
자원·메모리·처리량 지표는 ST06·ST02·ST03·SM04에 각각 흩어져 있어, 화면마다 조회 시각을 사람이 맞춰야 하고 그 과정에서 지표 간 동시 발생 관계가 드러나지 않습니다.
덤프와 로그는 다시 별도의 화면(ST22·SM21·SLG1)에서 확인해야 하며, 시스템 로그는 파일이 쌓이면 앞에서부터 덮어써 정작 필요한 시점의 기록이 남아 있지 않은 경우가 발생합니다.
날짜와 시각을 지정하면 해당 시점의 시스템 상태가 재현됩니다. 재생 컨트롤로 전후 구간을 이동하며 장애의 시작과 확산 과정을 추적하고, WP Type·응답시간 범위·Active Workprocess Only·CBO Only로 관측 범위를 좁힙니다.
SAP 표준 도구는 현재 상태만 제공하므로, 지나간 시점의 시스템 상태는 되돌려 확인할 수 없습니다.
▲ 날짜·시각 지정과 재생 컨트롤, 관측 범위 필터
Work Processes & Actions에서 인스턴스별 각 워크프로세스가 그 시각 수행하던 작업을 타임라인 블록으로 표시합니다. 어느 프로세스가 어떤 작업을 얼마나 오래 점유했는지, 프로세스가 소진 상태였는지가 한눈에 드러납니다.
▲ 인스턴스별 워크프로세스가 수행하던 작업을 타임라인 블록으로 표시
이 화면이 답하는 것 자세히 보기OS CPU·OS Memory·SAP Memory(Extended)·Logon User·Queue·Work Process·Throughput·Response Time이 동일한 시간축과 동일한 시점 마커로 정렬됩니다. 화면을 옮겨 다니며 시각을 맞출 필요 없이, 어떤 지표들이 함께 움직였는지를 그대로 확인합니다.
▲ 여덟 개 지표가 동일한 시간축·시점 마커로 정렬된 KPI 차트
지표별로 대체하는 SAP 표준 화면 보기OWLens Alerts, ABAP Dump, System/Application Log을 같은 시간축에서 확인해 지표의 변화가 어떤 사건과 맞물렸는지 확정합니다. 지표가 흔들린 시각에 덤프가 발생했다면, 그 둘은 더 이상 별개의 정보가 아닙니다.
▲ 같은 시간축에서 확인하는 OWLens Alerts · ABAP Dump · System/Application Log
특정 워크프로세스가 장시간 점유한 시각에, 큐가 함께 쌓였는가?
CPU·메모리가 상승한 시각과, 응답시간이 악화된 시각이 일치하는가?
지표가 흔들린 바로 그 시각에, 덤프나 시스템 로그가 남았는가?
각 지표를 따로 조회하면 이 동시성이 보이지 않습니다. 같은 시간축에 정렬해야 비로소 인과의 단서가 됩니다.
장애 원인 규명이 특정 인원의 경험에 의존하지 않도록 하여, 인력 부재 리스크와 반복 장애를 줄입니다.
장애 시점에 어느 업무 처리가 영향받았는지 확인해 현업에 설명하고, 대응 우선순위를 판단합니다.
그 시점의 워크프로세스 점유와 자원 지표를 함께 확인해 병목을 특정하고, 개발·DBA·인프라로 정확히 이관합니다.
SAP 표준 도구는 '지금'을 보여줍니다. 장애는 이미 지나간 뒤입니다. OWLens는 장애 시점을 다시 보여줍니다.
3개월 무료 데모와 설치·교육을 무상으로 제공합니다. 지금 바로 경험해 보세요.