ServiceNow Service Mapping Patterns 심화 — Pattern Designer 로 여는 Identification·Connection·Extension 섹션과 디버깅
Pattern Designer 에서 NDL 오퍼레이션 시퀀스로 저작되는 pattern 의 내부 구조를 분해한다. Identification Section 이 CI payload 를 만드는 상류 로직이고 IRE Identification Rules 는 하류 dedup 엔진임을 층위로 구분하고, Connection Section 이 Service Mapping 전용으로 Create Connection 오퍼레이션을 통해 downstream CI 를 찾아 cmdb_rel_ci 관계를 기록하는 과정, Temporary Variables 와 CI Attributes 의 역할 차이, Debug Mode 로 step 단위 디버깅하는 실무, 그리고 Extension Section 으로 upgrade-safe 커스터마이징하는 전략까지 실무 관점으로 정리한다.
개요
Service Mapping 이 CSDM Application Service 를 채우는 방법 §2 는 top-down 런타임을 이렇게 설명했다 — “entry point CI 의 pattern 을 실행해 다음 connection 을 찾고, 새 connection 이 없어질 때까지 반복.” 그런데 pattern 내부는 블랙박스로 남겼다. 이 글이 그 박스를 연다.
본론 전에 두 가지 오해를 선제 정리한다.
오해 (a) — “pattern 의 Identification Section = IRE 의 Identification Rules”
이름이 비슷해서 자주 혼동되지만 층위가 전혀 다르다. Identification Section 은 pattern 내부 로직으로 CI payload 를 만드는 상류 작업이고, IRE Identification Rules 는 그 payload 가 들어온 뒤 기존 CI 와 매칭·중복 제거를 판단하는 하류 엔진이다. §3 이 이 구분을 케이스로 분해한다.
오해 (b) — “Discovery pattern 과 Service Mapping pattern 은 완전히 별개다”
아니다. Application pattern 은 Discovery 와 Service Mapping 이 공유한다. 둘의 차이는 Connection Section 에 있다 — Connection Section 은 Service Mapping 전용이며 horizontal Discovery 는 쓰지 않는다. §1·§2 가 Pattern Type 과 3섹션 anatomy 를 정리한다.
§1~§7 로 pattern 실행 메커니즘 전체를 분해한다.
OOTB(Out-of-the-Box, 기본 제공) Australia 기준입니다. Pattern Designer UI·섹션 구성·오퍼레이션·Debug 화면 라벨은 인스턴스 버전·플러그인(Discovery/Service Mapping)·Store 앱 버전에 따라 달라질 수 있으며, 정확한 테이블·필드·메뉴 경로는 대상 인스턴스에서 확인을 권장합니다.
§1 — pattern 이란: Pattern Designer 와 Pattern Type
pattern 은 네트워크에서 어떤 CI 를 찾고 어떤 credential 로 어떤 CMDB 테이블을 채울지 지시하는 오퍼레이션(step) 시퀀스다. Neebula Discovery Language(NDL) 로 작성되며 JavaScript 가 아니다 — ServiceNow 가 2014년 Neebula 를 인수하며 가져온 기술 유산이다. pattern-based discovery 에서 pattern 은 기존 probe/sensor 를 identification·exploration 단계에서 대체한다.
저작·편집은 Pattern Designer 라는 시각적 인터페이스에서 이루어진다. pattern 정의는 sa_pattern 테이블에 저장되는 것으로 알려져 있으나 인스턴스 확인을 권장한다. OOTB pattern 콘텐츠는 “Discovery and Service Mapping Patterns” Store 앱으로 배포·갱신되므로, family 릴리스 업그레이드와 별개 버전 사이클을 가진다.
pattern 은 CI Type 과 Pattern Type 에 바인딩된다. CI Type 은 pattern 이 식별·생성한 CI 가 안착할 CMDB 클래스를 결정한다(CMDB Class Hierarchy 와 sys_class_path 참조). Pattern Type 은 두 가지다.
| Pattern Type | 사용 주체 | 용도 |
|---|---|---|
| Infrastructure | Discovery 전용 | 네트워크·서버 등 인프라 장비를 수평 탐색(horizontal)해 CI 목록 생성 |
| Application | Discovery + Service Mapping 공유 | 앱·미들웨어를 식별하고 속성을 수집. Service Mapping 은 추가로 Connection Section 을 통해 서비스 의존 그래프를 구성 |
한 줄 요약: Discovery pattern 은 CMDB CI 데이터를 채우는 것(horizontal)이 목표이고, Service Mapping 은 CI 간 관계·의존성 구조를 구축하는 것(top-down)이 목표다.
§2 — pattern 의 3섹션 anatomy
pattern 은 명명된 섹션 으로 구성된다. 섹션은 세 가지다.
각 섹션의 역할을 정리하면 다음과 같다.
- Identification Section — 필수(baseline). 대상 호스트에서 명령·쿼리를 실행해 속성을 수집하고 CI 를 식별·생성한다. 이 단계에서 CI payload 를 만든다. 최소 하나의 Identification Section 이 성공해야 이후 섹션이 실행된다. 실패하면 나머지 모든 섹션이 차단된다.
- Connection Section (= Connectivity Section) — Service Mapping 전용. 현재 식별된 CI 가 다음에 무엇에 연결되는지 outgoing connection 을 탐색한다. horizontal Discovery 는 Connection Section 을 쓰지 않는다.
- Extension Section — 선택. Identification 이후 실행되어 추가 속성 수집이나 다음 계층 보강을 담당한다. OOTB baseline 과 분리 저장되므로 업그레이드에 안전하다(§7).
Connection 과 Extension 의 정확한 상대 실행 순서는 인스턴스에서 확인을 권장한다.
§3 — ★ pattern Identification Section vs IRE Identification Rules
개요에서 예고한 혼동을 케이스로 분해한다. 이것이 이 글에서 가장 중요한 구분이다.
상류 · payload 생성
pattern Identification Section
- pattern 내부 로직
- 대상에서 명령·쿼리를 실행해 속성 수집
- CI 를 식별·생성해 CMDB payload 를 만든다
- identification + extension 실행 완료 시점에 payload 가 CI attribute 에서 생성되어 IRE 로 전달
하류 · dedup·조정
IRE Identification Rules
- CMDB 엔진(Identification and Reconciliation Engine) 규칙
- payload 가 들어온 뒤 기존 CI 와 매칭
- insert(신규) / update(기존) / 중복 처리 판단
- source priority·reconciliation 은 IRE 의 몫
이름이 비슷하지만 상류(payload 생성) vs 하류(dedup·조정) 로 위치가 다르다. pattern Identification Section 이 만든 payload 가 IRE 로 넘어가야 비로소 IRE Identification Rules 가 동작한다. IRE 내부 동작·source priority·identifier entry 상세는 CMDB IRE · Discovery · Reconciliation이 SoT — 재설명하지 않는다.
§4 — Connection Section: top-down traversal 의 실체
cycle 20 §2 가 말한 “connection 탐색”이 실제로 구현되는 곳이 Connection Section 이다.
Connection Section 은 현재 식별된 CI 의 outgoing connection(다음 홉) 을 찾는다. 핵심 오퍼레이션은 Create Connection 이다 — connection type(예: Inclusion)과 entry point 를 선택해 다음 계층(예: App Server → Database)으로의 연결을 정의한다.
동작 흐름은 일반적으로 다음과 같다.
- 알려진 CI 에서 시작해 traffic·protocol rule·script 로 target 탐지
- 실시간으로 target 검증
- target CI 가 CMDB 에 있는지 확인 — 없으면 Discovery/pattern 으로 신규 생성
- 확정된 연결을
cmdb_rel_ci관계로 기록 (서비스 의존은 일반적으로Depends on::Used by타입)
관계 모델 자체의 구조와 3필드 의미는 CI Relationship vs Reference Field로 위임한다.
오설계 — Precondition/Match 누락
Connection Section 에 entry point 기준 Precondition·Match 조건을 제대로 걸지 않으면, 엉뚱한 outgoing connection 이 생성되거나 필요한 connection 이 누락될 수 있다(인스턴스 설정에 따라 다름). 흔한 실패 신호: No inclusion connection created from CI 메시지가 로그에 반복 등장.
§5 — step·operation 과 두 가지 변수
step 은 섹션 안의 최소 실행 단위로, 오퍼레이션 하나를 실행한다. Pattern Designer 에서 step 정의 시 operation 을 선택하면 그에 맞는 파라미터·변수 필드가 표시된다. step 은 순차 실행된다.
operation 의 예시(전수 목록이 아닌 대표 예시):
Parse Command Output— SSH/셸 명령 출력 파싱WMI Query— Windows 환경 WMI 조회Registry Query— Windows 레지스트리 값 읽기SNMP Query— SNMP 프로토콜 조회Parse Variable— 버전 문자열 등 값 추출Parse File— 파일 내용 파싱Set Parameter Value— 파라미터 값 설정
pattern 실행 중 데이터는 두 가지 형태로 관리된다.
| 구분 | 표기 | 용도 | 저장 대상 |
|---|---|---|---|
| Temporary Variable | $ 접두사 (예: $BuildInfo) | step 간 중간값 보관. identification 완료 전 데이터를 step to step 으로 전달 | 실행 메모리 — CMDB 에 직접 저장되지 않음 |
| CI Attribute | CI Type 의 CMDB 필드명 | 최종 CI 속성값. payload 가 이 값에서 생성됨 | CMDB CI 레코드 |
Pattern Designer 오른쪽 pills 영역에서 위 = CI attribute, 아래 = temporary variable 로 구분해 확인할 수 있다(인스턴스 UI 배치 확인 권장). 문자열 상수는 큰따옴표로 감싼다.
payload 생성 시점: identification + extension 실행이 끝나는 시점에 CI attribute 값들로부터 payload 가 구성되어 IRE 로 전달된다(§3 연결).
§6 — Pattern Designer 로 디버깅
Pattern Designer 에서 pattern 을 열면 섹션별 Debug 진입점을 제공한다. 경로는 일반적으로 Discovery Patterns 메뉴에서 pattern 을 선택하는 방식이다(인스턴스 메뉴 경로 확인 권장).
Debug Mode 절차
- Identification Section 선택 → Debug(Debug Mode) 버튼 클릭
- ’Debug Identification Section’ 팝업에서 host IP·MID Server(수정 가능)·entry-point 파라미터 입력
- Connect → Identification Section 먼저 실행, 이후 하위 Extension 실행
- 실행 완료 후 CI Attributes 와 Temporary Variables 값 확인
- 개별 step 은 Test 로 단독 실행 → 어느 step 에서 실패하는지 추적
흔한 에러와 점검 포인트
CI not identified (가장 흔함)
Identification Section step 확인. Debug 에서 Temporary Variable 값을 추적해 어느 step 이 빈 값을 반환하는지 확인.
Failed Exploring CI Pattern
pattern 탐색 자체 실패. MID Server 연결·credential·CI Type 매핑 점검.
IP·port 는 맞는데 이름이 틀림
connection 문제가 아닌 identification·naming 로직 오설정. Identification Section 내 이름 추출 step 과 CI attribute 매핑 점검.
핵심 원칙: 최소 하나의 Identification Section 이 성공해야 Extension 이 실행된다. ‘CI not identified’ 가 나머지 섹션 실행 전체를 막는 근본 이유가 여기에 있다.
pattern 실행 로그는 sa_discovery_log 테이블(인스턴스 확인 권장)에서 확인할 수 있는 것으로 알려져 있다. 공식 문서의 ‘Resolve pattern-related mapping errors’ 가이드를 함께 참고할 것을 권장한다.
§7 — 커스터마이징과 릴리스 현행성
커스터마이징 전략
OOTB pattern 라이브러리가 표준 장비·앱의 대부분을 커버한다. 커스터마이징이 필요할 때 선택지는 두 가지다.
오설계 — baseline 직접 수정
OOTB pattern 의 Identification/Connection Section(baseline)을 직접 수정하면 해당 pattern 이 ‘customer updated’ 로 표시된다. 이후 Store 앱 업그레이드의 버그픽스·개선이 자동으로 적용되지 않는다.
권장 — Extension Section 추가 또는 clone
Extension Section 추가: baseline 과 분리 저장되어 업그레이드에 안전. 속성 추가·다음 계층 보강에 적합. 더 큰 변경이면 OOTB pattern 을 clone(커스텀 접두사)해 사본에 작업.
릴리스 현행성 노트
major 기능 변경은 family 릴리스에 귀속된다. 대부분의 pattern 기능은 Store 앱으로 배포돼 릴리스와 별개 버전 사이클을 가지므로, 아래 내용은 인스턴스별 확인을 권장한다.
- Xanadu — Service Mapping role 이
service_mapping_admin/service_mapping_user로 개명. CAPI 기반 Cloud Discovery 가 pattern 기반 방식으로 이행. - Yokohama — Application Service 라벨이 ‘Service Instance’로 개명(테이블명
cmdb_ci_service_auto불변). cycle 20 에서도 같은 사실을 기록했다. - Zurich — AI-Powered Service Mapping·tag-based Service Mapping Workspace 도입. pattern 활성/비활성화 자체는 customization 으로 취급되지 않아 Store 앱 업데이트를 계속 받는다.
- Australia — Service Mapping Plus 의 Multi-Source Service Mapping 도입. top-down·tag·ML 결과를 composite 서비스맵으로 통합. cycle 20 말미가 예고한 방향이다.
학습 허브
이 글은 ServiceNow CMDB 완전 정리 학습 허브의 pattern 실행 내부편이다 — populate 실행편이 블랙박스로 남긴 ‘pattern 실행’ 내부를, Identification·Connection·Extension 3섹션 분해부터 Debug Mode 실무까지 이어서 연다.
참조
- ServiceNow Docs — Pattern-based discovery (Australia)
- ServiceNow Docs — Pattern Designer overview (Australia)
- ServiceNow Docs — Connection section in patterns (Australia)
- ServiceNow Docs — Debug a pattern (Australia)
- ServiceNow Docs — Resolve pattern-related mapping errors (Australia)
- ServiceNow Docs — Modify a pattern using extensions (Australia)
- ServiceNow Community — Pattern Designer 사용법·Connection Section 트러블슈팅 관련 커뮤니티 포럼