OpenTelemetry, Java, Linux, Docker, Kubernetes, Custom OTLP setup plan과 verify 상태를 확인합니다.
제품 화면
제품 화면은 Monithub가 실제로 줄이는 병목의 증거입니다.
Connect에서 데이터를 붙이고, Dashboard Workbench와 AI Assistant로 먼저 볼 신호를 좁힌 뒤, Trace/eBPF와 Gateway 확장 화면에서 원인 근거를 확인합니다.
고객이 실제로 보는 작업면
기능이 아니라 운영 판단의 순서로 봅니다.
Monithub Core는 연결, 대시보드 구성, AI 분석 보조, Trace 근거 확인을 하나의 작업면으로 묶습니다. Gateway는 AI 요청 운영을 확장 검증하는 화면으로 분리해 설명합니다.
패널, 변수, 시간 범위, 레이아웃으로 현재 팀이 볼 운영 화면을 만듭니다.
Chat & Analysis, Create Dashboard, panel update suggestion을 운영 흐름 안에 붙입니다.
trace list, error traces, span timeline, duration/error 근거를 개발자에게 넘깁니다.
service topology, traffic trend, top services, latency distribution, recent flows를 봅니다.
health/readiness, service registry, model visibility, request test를 확장 검증합니다.
01 · Connect
문제: 관측 데이터 연결부터 PoC가 느려집니다.
판단 변화: 연결 가능한 서비스와 데이터 소스를 setup plan, credential, verify 상태로 먼저 확인합니다.
- OpenTelemetry Collector
- Java application
- Linux host / Docker / Kubernetes
- Custom OTLP
OpenTelemetryJavaLinuxDockerKubernetesCustom OTLP
Setup plan
select integration → configure credential → copy command → verify connection
02 · Dashboard Workbench
문제: 전체 상태는 보이지만 어디서 시작할지 늦습니다.
판단 변화: 패널, 변수, 시간 범위, 레이아웃을 고정해 장애 대응의 첫 화면을 만듭니다.
03 · AI Assistant
문제: 그래프 해석이 담당자 경험에만 남습니다.
판단 변화: 분석 대화, 대시보드 생성, 패널 업데이트 제안으로 원인 후보와 다음 확인 지점을 남깁니다.
04 · Trace Evidence
문제: 개발자는 같은 시간대와 호출 흐름을 다시 찾아야 합니다.
판단 변화: trace list, error trace, span timeline을 바로 이어받아 같은 맥락에서 분석을 시작합니다.
05 · Network/eBPF
문제: 서비스 사이 흐름과 지연 위치가 따로 보입니다.
판단 변화: service topology, traffic trend, latency distribution, recent flows로 네트워크 근거를 같은 판단 흐름에 붙입니다.
gatewaycheckout-apipayment-dbqueue
Service topologyTraffic trendTop servicesLatency distributionRecent flowsPackets / bytes
06 · Gateway 확장
문제: LLM/API 요청은 운영 단위로 묶어 보기 어렵습니다.
판단 변화: health/readiness, service registry, model visibility, request test를 AI 운영 확장 화면에서 검증합니다.
Gateway는 Monithub Core 검증 이후 선택적으로 확인하는 확장 영역입니다.
