너무 많은 고객들에게 영향을 미치기 전에 이렇게 할 수 있으면 좋겠죠?
함께 살펴 보시죠~!
위험 감소 및 시스템 관리 비용 감소
- 우리는 서비스가 어떤 작업에 시간을 사용하는지, 왜 작동이 중단되는지를 이해하고 대응 할 수 있습니다.
- 우리는 서비스들이 어떻게 서로 상호작용하는지를 알게 되고, 병목 현상을 시각화하여 개선 할 수 있습니다.
조직간 공유하는 성능 및 시스템 정보
- 우리가 개발하고, 운영하는 서비스의 성능 정보와 시스템 정보를 타 조직과 즉시 공유할 수 있습니다.
- 우리는 공유된 시스템의 정보를 통하여, 장애요인을 파악하고 개선하여 장애율을 개선할 수 있는 포인트를 도출할 수 있습니다.
장애 문제 예측 가능성
- 우리는 목표한 임계설정으로 장애 상황을 감지할 수 있습니다.
- 우리는 장애 상황을 학습하여, 패턴 반복시 장애 상황을 예측 할 수 있습니다.
성능 및 장애 원인 파악 가능성
- 우리는 성능 병목 현상과 오류를 사전에 발견하고 수정할 수 있습니다.
- 우리는 테스트 서버의 모니터링 데이터를 개발팀에게 제공하여 고도의 품질기반 서비스를 얻을 수 있습니다.
- Web Server :: Apache, Nginx...
- aRMS 모니터링은 Front와 Backend가 분리된 구조로 동작합니다.
- 따라서, Web용 Front Code는 커스터마이징이 가능합니다.
- Docker Swarm :: aRMS, Monitoring ...
- aRMS 모니터링의 Backend는 Docker Swarm 서비스로 구성됩니다.
- 따라서, Swarm 내부 서비스간 통신은 자동으로 설정됩니다.
- Agent Service :: 모니터링 대상 어플리케이션 ...
- 모니터링을 할 어플리케이션에 에이전트를 설치 후 실행합니다.
- 운용 서버 최소 스펙
- 모니터링 시스템은 클러스터를 지원합니다.
- 최소 12개의 CPU Thread가 필요합니다.
- 최소 16GB 의 Memory가 필요합니다.
- 데이터 저장을 위한 NFS Server ( 최소 200기가 : 1주일분 )가 필요합니다.
- 모니터링 범주
- Application layer : 모니터 대상의 어플리케이션 레벨의 데이터 수집 ( ex> JVM heap, perm )
- Server Status Layer : 어플리케이션이 동작하는 호스트의 상태 데이터 수집 ( ex> CPU, MEM, HDD )
- Database Query Layer : 어플리케이션과 연동하는 데이터베이스 질의 데이터 수집 ( ex> SQL, Transaction )
- Client Layer & Log Layer : 단말 장치의 요청 데이터 및 어플리케이션 로그 데이터 수집 ( ex> Log, Client action flow )
- 연동 시스템 Status Layer : 어플리케이션과 연동하는 3rd party 데몬 상태 데이터 수집 ( ex> Heartbeat Status Data )
