2020년 10월 20일엔지니어링

양방향 통신을 위해 ServiceNow와 Elasticsearch를 연결하는 방법

Elastic Stack(ELK)은 수년 동안 통합 가시성과 보안을 위해 사용되어 왔으며, 이제는 두 가지를 즉시 사용할 수 있는 솔루션으로 제공하고 있습니다. 그러나 문제를 식별하고 근본 원인을 찾는 것은 프로세스의 일부일 뿐입니다. 조직은 일상적인 워크플로우에 Elastic Stack을 통합하여 이러한 문제를 신속하게 해결하고자 하는 경우가 많습니다. 여기에는 일반적으로 어떤 형태로든 티켓팅/문제 추적 프레임워크와의 통합이 포함됩니다. 어떤 팀은 Slack이나 이메일을 사용하는 반면, 다른 팀은 ServiceNow나 Jira와 같은 도구를 사용합니다. 이 3부로 구성된 시리즈에서는 문제 관리를 자동화하기 위해 ServiceNow와 Elasticsearch를 설정하는 과정과 함께 문제를 시각화하고 표시 및 관리하기 위한 Canvas 워크패드를 구성하는 방법을 보여드립니다.

첫 번째 블로그에서는 Elasticsearch와 ServiceNow 간에 양방향 관계를 설정하는 방법에 대해 알아보려고 합니다. ServiceNow는 서비스 데스크 기능에 자주 사용되는 인기 있는 워크플로우 관리 도구입니다. 기본적인 아이디어는 (1) 머신 러닝에 의해 작동되는 이상 징후 기반 경보를 통해 자동으로 티켓을 생성하고 (2) 티켓이 업데이트될 때마다 Elasticsearch를 자동으로 업데이트한다는 것입니다. 이 작업을 왜 하려고 할까요? 문제 탐지에서 조사 및 관리에 이르기까지 전체 에코시스템에 대한 전체적이고 종합적인 개요를 얻기 위해서입니다. 이 프로세스의 일부로 다음과 같은 복원력 메트릭을 계산하려고 합니다.

평균 확인 시간(MTTA) — 응답성을 추적하는 데 사용되는 주요 메트릭입니다. MTTA가 높으면 팀이 경보 오버플로를 겪고 있으므로 응답하는 데 시간이 너무 오래 걸린다는 것을 나타낼 수 있습니다.
평균 해결 시간(MTTR) — 티켓이 해결되는 데 걸리는 시간을 확인하기에 좋습니다. 이 값은 티켓이 'In Progress(진행 중)' 상태에서 'Resolved(해결됨)' 또는 'Closed(종결됨)' 상태로 전환되는 데 걸리는 평균 시간을 기준으로 계산됩니다.
평균 고장 간격(MTBF) — 무엇인가가 얼마나 탄력적인지 이해하는 데 유용합니다. MTBF가 낮을수록 더 빨리 더 자주 고장이 난다는 의미입니다. 이 값은 시간 단위로 측정되며 총 실행 시간을 오프라인 상태의 문제 수로 나누어 계산합니다.

단일창에서 작업하는 것은 수많은 도구들 사이를 왔다 갔다 하는 것보다 언제나 더 낫습니다. 데이터를 식별하고 검색하는 데 사용되는 동일한 도구에서 MTTA, MTTR 및 MTBF를 파악하면, 해당 팀이 특정 애플리케이션, 서비스, 프로젝트, 팀, 부서 또는 어떤 엔티티가 위의 복원력 메트릭에 어떻게 영향을 미치기 시작하는지를 알 수 있습니다. Kibana에서 동일한 데이터를 다른 관점으로 보게 되면, SRE, SOC 분석가 및 경영진을 위해 조정된 인사이트를 제공할 수 있습니다.

예제 프로젝트

이 블로그에서는 Elasticsearch, ServiceNow 및 Heartbeat(Elastic의 가동 시간 모니터)를 사용하여 다음과 같은 상황이 발생하도록 설정하겠습니다.

Heartbeat가 온라인 상태 및 응답성을 보장하기 위해 애플리케이션을 지속적으로 모니터링합니다.
Watcher(Elasticsearch에 기본 탑재되는 경보 프레임워크)는 애플리케이션이 5분 이상 다운된 경우 ServiceNow에서 문제 티켓을 생성하지만, 경보 피로를 줄이기 위해 특정 애플리케이션에 대해 ServiceNow에서 열려 있는 티켓이나 활성 상태의 티켓이 없는 경우에만 이 작업을 수행합니다.
알렉스(접니다!)가 자신에게 티켓을 할당하고 메모를 추가함으로써 티켓에 대한 작업을 시작합니다.
ServiceNow에서 티켓이 업데이트될 때마다 레코드가 Elasticsearch에서 업데이트됩니다.
알렉스의 경영진이 Canvas를 사용하여 열려 있는 티켓, MTTA, MTTR, MTBF, 어느 애플리케이션이 가장 문제가 되는지 등을 추적합니다.

최종 결과는 다음 Canvas 대시보드와 같게 됩니다.

이 시리즈가 끝날 때까지 Canvas에서 만들게 될 문제 관리 대시보드.

이 프로젝트에는 몇 가지 섹션이 있습니다.

ServiceNow 설정
Elasticsearch를 자동으로 업데이트하도록 ServiceNow에서 비즈니스 규칙 구성
애플리케이션을 모니터링하도록 Heartbeat 설정
Elasticsearch 인덱스 구성
지속적으로 메트릭을 계산할 수 있는 몇 가지 데이터 트랜스폼 생성
머신 러닝과 경보를 사용하여 ServiceNow에서 자동으로 티켓 생성(티켓이 없는 경우에만)
피벗 및 Canvas 표현식과 같은 고급 Elasticsearch SQL을 사용하여 위의 Canvas 대시보드 만들기

따라가며 작업할 Elasticsearch 배포가 없는 경우, Elastic Cloud에서 Elasticsearch Service의 무료 체험판을 실행하거나 로컬에서 무료로 설치할 수 있습니다. 또한 ServiceNow 인스턴스가 없는 경우, 개인 개발자 인스턴스를 실행할 수 있습니다.

ServiceNow 준비
문제 양식 개인화

이 블로그에서는 완전히 새로워진 따끈따끈한 ServiceNow 인스턴스가 있다고 가정합니다. 대부분의 경우는 그렇지 않지만요. 그러나 이 작업 단계는 기존 설정에서도 아주 간단합니다. 우선 다음과 같이 Incident 앱을 업데이트하여 Application(애플리케이션)이라는 새 필드를 추가하고 어떤 애플리케이션에 문제가 있는지 추적합니다.

ServiceNow에서 Incident 앱을 엽니다.
임시 문제를 만듭니다. 값은 별로 중요하지 않습니다.
FormDesign 마법사로 이동합니다.

ServiceNow FormDesign 마법사.

간단히 진행하기 위해, String(스트링) 필드만 추가하여 해당 애플리케이션 이름을 추적하겠습니다. 실제 프로덕션 설정에서는 애플리케이션을 ServiceNow 내의 특정 엔티티로 설정하는 것이 가장 좋습니다. 다음 설정으로 새 String(스트링) 필드를 구성합니다.

ServiceNow에서 스트링 속성 구성.

이 필드를 저장한 후 문제 양식으로 돌아가서 아이콘을 사용하여 현재 있는 필드를 개인화합니다.

ServiceNow에서 선택한 필드 개인화.

이 시점에서, 우리는 새로운 특정 필드가 포함된 Incident(문제) 양식을 갖게 되었습니다. 이를 통해 어떤 애플리케이션에 문제가 있는지를 알아내게 됩니다. 이제 ServiceNow를 구성하여 어떠한 방식으로든 문제가 업데이트될 때 자동으로 Elasticsearch를 업데이트하도록 해야 합니다.

Elasticsearch가 생성한 문제에 대한 ServiceNow 사용자 생성

문제의 원인을 파악하는 것이 중요하며, 이 작업을 수행하기 위해 ServiceNow는 Caller(호출자) 필드를 사용합니다. 티켓을 만들 때 자동으로 생성된 티켓임을 알 수 있도록 이 필드를 설정해야 합니다. 새 사용자를 생성하려면, ServiceNow 내의 Users 앱으로 이동한 후 다음 필드를 이용해 새 사용자를 생성하고 저장합니다.

Id: elastic_watcher
이름: Elasticsearch Watcher
이메일: admin@elasticutilities.co

ServiceNow 양방향 통신

ServiceNow에서 문제를 생성하는 것은 간단한 REST API POST 요청이지만, 자동으로 Elasticsearch를 업데이트하도록 ServiceNow를 구성하는 것은 약간 다릅니다. ServiceNow 비즈니스 규칙을 활용해 보겠습니다. 이 규칙은 문제 테이블을 '모니터링'하고 지정된 몇 개의 필드 중 하나라도 변경되면 변경 사항을 Elasticsearch로 인덱싱하는 일부 논리를 실행하게 됩니다. Elasticsearch에는 자격 증명이 필요하므로 다음 작업을 적절하게 수행해야 합니다.

Elasticsearch에서 새 역할 및 사용자 생성(최소 권한 원칙)
ServiceNow에서 REST 메시지 및 인증 프로필 설정
비즈니스 규칙 생성

Elasticsearch 역할 및 사용자 생성

이것은 아주 잘 문서화되어 있는 과정이기 때문에 여기에 많은 시간을 할애하지는 않겠습니다. servicenow-incident-updates 인덱스 별칭 내에서만 문서를 색인화할 수 있는 역할이 필요합니다. 이 기능을 위해 최소 권한 원칙을 준수할 수 있는 구체적인 역할을 갖는 것이 좋습니다. 아래에서 옵션에 대해 간략히 설명해 놓았습니다. Kibana 또는 API를 이용하는 단계는 다음과 같습니다.

Kibana를 이용하는 방법

Management(관리) -> Role(역할)
Create role(역할 만들기)
필드를 다음 항목으로 설정
- Indices: servicenow-incident-updates
- Privileges: index

API를 이용하는 방법

이 작업을 위해 다음과 같이 Kibana의 Console을 사용할 수 있습니다.

POST /_security/role/servicenow_updater 
{ 
  "indices": [ 
    { 
      "names": [ "servicenow-incident-updates" ], 
      "privileges": ["index"] 
    } 
  ] 
}

이제 해당 역할을 가진 사용자를 생성합니다.

Kibana를 이용하는 방법

Management(관리) -> Users(사용자)
Create user(사용자 만들기)
필드를 다음 항목으로 설정
- 사용자 이름: ServiceNowUpdater
- 비밀번호: 상상력을 발휘해 보세요
- Role: servicenow_updater

API를 이용하는 방법

POST /_security/user/ServiceNowUpdater 
{ 
  "password" : "좋은 암호로 바꾸세요", 
  "roles" : [ "servicenow_updater" ], 
  "full_name" : "ServiceNow Incident Updater", 
  "email" : "admin@example.com" 
}

ServiceNow에서 Elasticsearch REST 메시지 및 인증 프로파일 생성

이제 Elasticsearch에서 이 기능에 대한 사용자를 설정했으므로 ServiceNow에서 작업할 수 있습니다. ServiceNow에서 REST Messages 앱을 열고 새 레코드를 만듭니다. 이름을 "Elasticsearch"로 설정하고 엔드포인트를 Elasticsearch 엔드포인트로 설정합니다. Elastic Cloud에서 이를 실행하고 있으므로, 저의 엔드포인트는 https://[CloudID].westeurope.azure.elastic-cloud.c...입니다.

다음 단계는 인증을 설정하는 것입니다. 이렇게 하려면 Authentication type(인증 유형)을 Basic으로 설정하고 Basic auth profile(기본 인증 프로필) 필드에서 돋보기 아이콘을 클릭합니다.

Authentication type(인증 유형)을 Basic으로 설정.

기본 인증 구성 레코드를 새로 만들어 보겠습니다. 이 레코드의 이름을 “ElasticsearchIncidentUpdater”로 설정하고 사용자 이름과 비밀번호 필드를 위에서 사용한 각 값으로 설정합니다. 저의 경우에는 다음과 같습니다.

사용자 이름: ServiceNowUpdater
비밀번호: [좋은 암호로 바꾸세요]

이 레코드를 저장하고 REST Message 앱의 Elasticsearch 레코드로 돌아갑니다. 새로운 기본 인증 프로필이 사용 중인지 확인합니다. “HTTP Methods(HTTP 메소드)” 섹션이 표시되면 Submit(제출)을 클릭한 다음 위에서 Elasticsearch라고 불렀던 REST Message를 다시 열어야 합니다.

그러면 다음과 같이 보여야 합니다.

ServiceNow의 레코드.

다음으로, ServiceNow에서 새로운 HTTP 메소드 레코드를 만들어 보겠습니다. 여기서 몇 가지 작업을 해야 하니 눈여겨 보세요.

“HTTP Methods(HTTP 메소드)”라고 표시된 곳 옆에 있는 New(새로 만들기) 버튼을 클릭합니다.
이름을 UpdateIncident로 설정합니다.
HTTP 메소드를 POST로 설정합니다.
인증 유형이 상위에서 상속되도록 설정되었는지 확인합니다.
엔드포인트를 Elasticsearch 엔드포인트(포트 포함)로 설정한 다음 엔드포인트에/servicenow-incident-updates/_doc을 추가합니다(예: https://[CloudID].westeurope.azure.elastic-cloud.c...).
“Content-Type(콘텐츠 유형)”의 이름과 “application/json”의 값을 사용하여 HTTP 헤더를 생성합니다.

Content(콘텐츠) 필드를 다음으로 설정합니다.

{"@timestamp": "${timestamp}", "incidentID": "${incidentID}", "assignedTo": "${assignedTo}",  "description": "${description}",  "state": "${state}",  "updatedDate": "${updatedDate}",  "workNotes": "${workNotes}",  "app_name": "${appName}"}

New(새로 만들기) 버튼을 이용해 아래 스크린샷에 있는 특정 "Name(이름)"을 지정하여 다음 변수 치환을 생성합니다(변수 치환 UI 구성 요소가 표시되기 전에 Submit(제출) 버튼을 클릭하고 엔드포인트로 다시 돌어가야 할 수도 있습니다). “Related Links(관련 링크)”에 “Auto-generate variables(자동 생성 변수)”라는 링크가 있으며, 이 링크를 사용하는 것이 좋습니다.

치환 변수 생성

오른쪽 상단에 있는 Update(업데이트)를 클릭하면 REST 메시지 양식으로 돌아갑니다.
Update(업데이트)를 클릭하여 저장합니다.

됐습니다. 많은 작업을 진행했네요! 대부분은 따라하기 쉬워야 하지만 7단계와 8단계는 설명이 필요할 수 있으며, 이는 역순으로 수행하는 것이 가장 좋습니다. 8단계에서는 요청을 수행할 때 아웃바운드 REST 메시지의 내용에서 변수를 치환할 수 있도록 레코드에 변수를 추가합니다. 7단계에서는 이러한 변수를 활용하여 POST 요청의 콘텐츠 필드를 구축합니다. 이 콘텐츠 필드는 Elasticsearch로 전송된다는 점에 유의하시는 것이 중요합니다.

ServiceNow 비즈니스 규칙 생성

이 섹션은 문제가 생성되거나 업데이트될 때마다 Elasticsearch로 업데이트를 보낼 수 있도록 하는 핵심 구성 요소입니다. 이렇게 하려면 ServiceNow에서 Business Rules 앱을 열고 새 규칙을 만들어야 합니다. 이 작업에는 몇 가지 부분이 있는데, 실행할 테이블, 실행 시기, 실행 논리를 구성해야 합니다. 첫째, 이름이 필요합니다. 이름 필드를 "Elasticsearch Update Incident"로 설정하고 테이블을 "incident"로 설정합니다. 여기서 사용자 지정 스크립트를 사용할 예정이므로 “Advanced(고급)” 상자도 선택하는 것이 중요합니다.

다음과 같이 “When to run(실행 시기)” 상자를 설정합니다.

ServiceNow의 "When to run(실행 시기)" 상자.

이 구성은 문제가 삽입, 업데이트 또는 삭제된 후에 비즈니스 규칙이 실행됨을 의미합니다. 상태, 작업 메모, 할당된 위치 또는 업데이트된 필드가 업데이트될 때 규칙이 실행되어야 합니다.

다음 단계는 우리가 지금까지 해온 모든 것을 하나로 묶는 작업입니다. Advanced(고급) 탭으로 이동하여 스크립트를 이 코드 조각과 동일하게 설정해야 합니다.

(function executeRule(current, previous) { 
    try { 
        var r = new sn_ws.RESTMessageV2('Elasticsearch', 'UpdateIncident'); 
        r.setStringParameterNoEscape('incidentID', current.number); 
        r.setStringParameterNoEscape('description', current.description); 
        r.setStringParameterNoEscape('updatedDate', current.sys_updated_on); 
        r.setStringParameterNoEscape('assignedTo', current.getDisplayValue("assigned_to")); 
        r.setStringParameterNoEscape('state', current.getDisplayValue("state")); 
        r.setStringParameterNoEscape('workNotes', current.work_notes); 
        r.setStringParameterNoEscape('appName', current.u_application); 
        r.setStringParameterNoEscape('timestamp', new GlideDateTime().getValue()); 
        r.execute(); 
    } catch (ex) { 
    gs.info(ex.message); 
    } 
})(current, previous);

이 스크립트는 우리가 생성한 Elasticsearch REST 메시지를 사용합니다. 특히, UpdateIncident POST 요청을 사용하고, 문제의 관련 필드로 생성한 변수 치환을 문제의 필드에 채운 다음, 이를 Elasticsearch 내의 servicenow-incident-updates 업데이트로 전송합니다.

이제 저장하면 실행 준비가 끝납니다.

Heartbeat를 사용하여 애플리케이션 모니터링

가동 시간 모니터링에서 답변하는 질문 중 하나는 "작동 중인가, 다운되었는가?"입니다. Heartbeat가 생성하는 데이터를 사용하여 이 작업을 수행합니다. Heartbeat는 TCP, HTTP 또는 ICMP를 사용하여 엔드포인트를 주기적으로 ping하여 통합 가시성을 위해 스토리의 일부를 수집합니다. 호스트, 서비스, 웹사이트 또는 API가 활성 상태인지 여부를 파악하는 것은 에코시스템의 가용성을 이해하는 데 있어 중요합니다. Heartbeat는 응답 시간과 응답 코드를 수집하여 이 문제를 더욱 심화시킵니다. 이렇게 하면 로그, 메트릭 및 APM 데이터와 결합되어 간단하게 전체 상황을 이해하고 에코시스템에서의 활동을 상호 연관시킬 수 있습니다.

Heartbeat는 손쉽게 시작할 수 있습니다. Heartbeat 설명서의 단계를 따르기만 하면 됩니다.

이 프로젝트에서는 4가지 서비스를 확인할 수 있도록 Heartbeat를 설정했습니다. 다음은 heartbeat.yml 파일의 코드 조각입니다.

heartbeat.monitors: 
- name: "Authentication Service" 
  type: http 
  urls: ["192.168.1.38/status"] 
  schedule: '@every 1m' 
  check.response.status: 200   
- name: "Search Service" 
  type: http 
  urls: ["192.168.1.109/status"] 
  schedule: '@every 1m' 
  check.response.status: 200 
- name: "Frontend" 
  type: http 
  urls: ["192.168.1.95/status"] 
  schedule: '@every 1m' 
  check.response.status: 200 
- name: "API Gateway" 
  type: http 
  urls: ["192.168.1.108/status"] 
  schedule: '@every 1m' 
  check.response.status: 200

양방향 통신 연결 완료!

다 됐습니다! 이제 가동 시간 데이터를 Elasticsearch로 수집하고 있습니다. Elasticsearch는 양방향 통신을 위해 ServiceNow에 연결됩니다. 위에서 언급한 바와 같이, 이것은 세 개의 섹션으로 이루어진 시리즈의 일부입니다. 더 많은 내용을 알아볼 준비가 되셨다면, Elasticsearch를 설정하여 문제가 발생할 경우 ServiceNow에서 문제를 생성하는 것을 다루는 2부를 바로 읽어보세요!

한번 해보시겠어요? 가장 쉬운 방법은 Elastic Cloud를 사용하는 것입니다. Elastic Cloud 콘솔에 로그인하거나 14일 무료 체험판에 등록하시면 됩니다. 기존 ServiceNow 인스턴스로 위의 단계를 따르거나 개인 개발자 인스턴스를 실행할 수 있습니다.

또한 GitHub, Google Drive 등과 같은 다른 소스와 함께 ServiceNow 데이터를 검색하려는 경우, Elastic Workplace Search에 ServiceNow 커넥터가 미리 빌드되어 있습니다. Workspace Search는 모든 컨텐츠 소스에서 관련 결과를 포함하여 팀에게 통합 검색 환경을 제공합니다. 또한 Elastic Cloud 체험판에도 포함되어 있습니다.

Kibana 내의 Uptime 애플리케이션을 잊지 말고 확인해 보세요. 위에서 간단히 해본 Heartbeat 구성을 확장하여 사용자의 에코시스템을 향하게 하고 TLS 인증서 상태를 확인하는 동시에 작업 수행 상태를 모니터링할 수 있습니다.

Elasticsearch Platform

ELK Stack

Elastic Cloud

Observability

Security

Search

산업별

솔루션별

고객 스포트라이트

개발자

소통

학습

도움말

Elastic에서 어떤 일이 진행되고 있는지 확인

양방향 통신을 위해 ServiceNow와 Elasticsearch를 연결하는 방법

예제 프로젝트

ServiceNow 준비

문제 양식 개인화

Elasticsearch가 생성한 문제에 대한 ServiceNow 사용자 생성

ServiceNow 양방향 통신

Elasticsearch 역할 및 사용자 생성

Kibana를 이용하는 방법

API를 이용하는 방법

Kibana를 이용하는 방법

API를 이용하는 방법

ServiceNow에서 Elasticsearch REST 메시지 및 인증 프로파일 생성

ServiceNow 비즈니스 규칙 생성

Heartbeat를 사용하여 애플리케이션 모니터링

양방향 통신 연결 완료!

팔로우하기

회사 소개

참여하기

언론

파트너

신뢰 및 보안

IR 정보

EXCELLENCE AWARDS