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]가 cmdb_ci_computer 테이블에 기록이 없습니다"라는 메시지는 CMDB, cmdb_ci, cmdb_ci_hardware, cmdb_ci_server 및 cmdb_ci_linux_server 테이블에서 해당 sys_id의 기록을 삭제해야 함을 의미합니다(컴퓨터 클래스는 계층 구조에서 하드웨어 클래스와 서버 클래스 사이에 있음).
스크립팅된 감사 건너뜀
스크립팅된 감사 결과가 준수 KPI에 포함되지 않으면 오류 메시지가 기록됩니다. 감사의 스크립트가 마지막 실행 날짜 필드를 채우도록 업데이트되지 않았기 때문일 수 있습니다. 마지막으로 실행된 날짜 값이 없으면 CMDB Health 는 이러한 실행 결과를 최근의 전체 감사 실행의 일부로 식별할 수 없으며 해당 결과를 건너뜁니다.