CMDB 상태 프로세스 추적
다음 정보를 사용하여 CMDB 상태 프로세스와 관련된 문제를 추적하고 해결합니다.
로깅
기본적으로 오류 메시지만 CmdbHealth 소스 이름으로 syslog 테이블에 기록됩니다. '정보' 및 '경고' 메시지(일반적으로 각 처리 주기의 시작과 끝에 기록됨)의 로깅을 활성화하려면 시스템 속성 glide.cmdb.logger.use_syslog 업데이트합니다. CMDBHealth입니다. 이 속성 사용에 대한 자세한 내용은 다음 문서를 참조하십시오 CMDB 상태 시스템 속성.
처리 상태
예약된 작업이 활성화되었지만 <ph keyref="var.config-mgmt-database-short"/> 대시보드에 데이터가 표시되지 않는 경우 CMDB 상태 메트릭 상태 [cmdb_health_metric_status] 테이블에서 처리 상태를 확인할 수 있습니다. 메트릭 상태에 inactive 따라 진행 방법을 결정합니다.
처음에는 모든 메트릭의 상태가 '진행 중'입니다.
- 완료
- 모든 클래스가 처리되고 실패 수가 최대 실패 임계치 미만입니다.
- 최대 실패 수
- 이 메트릭의 실패 횟수가 최대 실패 임계치에 도달했습니다. 처리가 중단되었으며 다음 실행에서 다시 시작됩니다.
- 일일 제한 시간 일시 중지
- 프로세서가 처리 시간 제한에 도달했습니다. 처리가 일시 중지되고 다음 실행에서 다시 시작됩니다.
- 완료
- 연결된 모든 메트릭이 완료 상태이고 점수 계산이 완료되었습니다.
- 완료 안 됨
- 연결된 메트릭 중 하나가 최대 장애 임계치에 도달했기 때문에 점수가 계산되지 않습니다.
- 일일 제한 시간 일시 중지
- 연결된 메트릭 중 하나가 처리 시간 제한에 도달하여 시간 초과되었습니다.
처리 시간
메트릭 처리 시간이 초과되면 처리하는 데 시간이 너무 오래 걸리는 클래스를 확인할 수 있습니다. 이 정보를 사용하여 유효성 검사 규칙이 취약한지 확인합니다.
각 메트릭의 진행률은 CMDB 상태 프로세서 상태 테이블 [cmdb_health_processor_status]에서 추적됩니다. 메트릭에 대해 처리된 클래스의 상태는 완료이고 아직 처리되지 않은 클래스의 상태는 초안입니다. 각 클래스의 업데이트 시간을 확인하여 각 클래스의 처리 시간을 계산할 수 있습니다.
깨진 계층 구조로 인한 기록
고아 규칙은 고아 CI를 탐지할 수 있으며, 사용자는 이에 액세스하여 삭제할 수 없습니다. 또는 고아 기록을 표시하는 목록 뷰와 총 기록 수가 일치하지 않을 수 있습니다. 이러한 결과는 CMDB 계층 구조의 한 테이블에서 데이터베이스의 기록이 삭제되었기 때문입니다.
이러한 CI 기록은 GlideRecord를 통해 액세스할 수 없으며 데이터베이스에서 직접 삭제해야 합니다. 따라서 이 경우 데이터베이스에서 고아 CI를 삭제하려면 지원 부서에 문의하여 도움을 받아야 합니다.
고아 테스트 결과는 계층 구조가 정확히 어디에서 깨졌는지에 대한 상세 정보를 제공합니다. 예를 들어, "이 cmdb_ci_linux_server CI [91054fc24f22520053d6e1d18110c713] is missing record in cmdb_ci_computer table"이라는 메시지는 CMDB, cmdb_ci, cmdb_ci_hardware, cmdb_ci_server 및 cmdb_ci_linux_server 테이블에서 해당 sys_id의 기록을 삭제해야 함을 의미합니다(Computer 클래스는 계층 구조의 하드웨어 및 서버 클래스 사이에 있음).
스크립트된 감사 건너뜀
스크립트된 감사 결과가 준수 KPI에 포함되지 않은 경우 오류 메시지가 기록됩니다. 그 이유는 감사의 스크립트가 마지막 실행 날짜 필드를 채우도록 업데이트되지 않았기 때문일 수 있습니다. 마지막 실행 날짜 값이 없으면 CMDB 상태는 이러한 실행 결과를 최근 전체 감사 실행의 일부로 식별할 수 없으므로 해당 결과를 건너뜁니다.