Automate는 한밤중에도 Dynatrace 문제 경고를 해결하고 ServiceNow에 보고합니다!

현대적인 IT 운영은 가시성과 효율성 간의 공생 관계를 장려하기 때문에 이 영역에서는 관측성 툴을 자동화와 통합하는 것이 무엇보다 중요합니다. 관측성 툴은 복잡한 시스템의 성능, 상태, 동작에 대한 심층적인 인사이트를 제공하므로 조직은 문제가 확대되기 전에 문제를 사전에 파악하고 수정할 수 있습니다. 

이러한 툴은 자동화 프레임워크와 원활하게 통합되어 기업이 실시간으로 역동적인 변화를 모니터링하고 대응할 수 있도록 합니다. IT 팀은 관측성과 자동화 간의 이러한 시너지 효과를 통해 변화하는 상황에 신속하게 적응하고, 다운타임을 최소화하고, 리소스 활용도를 최적화할 수 있습니다. 관측성 데이터를 기반으로 대응을 자동화함으로써 조직은 민첩성을 강화하고, 수동 개입을 줄이며, 안정적이고 탄력적인 인프라를 유지 관리할 수 있습니다. 본질적으로 관측성과 자동화를 함께 사용하는 것은 빠르게 변화하는 오늘날의 복잡한 기술 환경에서 선제적이고 대응력이 뛰어나며 간소화된 운영 환경을 구현하는 데 필수적입니다.

이 블로그 포스트에서는 베어 메탈 및 가상 머신 모두에서 프로세스를 모니터링하는 것을 포함하여 일반적인 활용 사례를 살펴보겠습니다. 여기서는 환경 모니터링을 위해 세심하게 구성된 전문화된 서비스 제품군을 포함하는 호스트에 배포된 바이너리 파일인 Dynatrace의 OneAgent를 활용하는 데 초점을 맞출 것입니다. 이러한 서비스는 텔레메트리 메트릭을 능동적으로 수집하여 하드웨어, 운영 체제, 애플리케이션 프로세스 등 호스트의 다양한 측면에 대한 인사이트를 캡처합니다.

이 활용 사례에서의 목표는 NGINX 웹 서버 프로세스에 대해 특별히 호스트 수준의 모니터를 설정하는 것입니다. 정의된 룰을 통해 이벤트 소스를 해당 작업과 연결하는 프레임워크인 Event-Driven Ansible의 구현 과정을 살펴보겠습니다. 이 인스턴스에서 이벤트 소스는 Dynatrace입니다.

구성이 완료되면 다음 시나리오를 시뮬레이션할 것입니다.

1. NGINX 웹 서버에서 예기치 않은 다운타임이 발생합니다.
2. Dynatrace OneAgent에서 지원하는 프로세스 모니터는 실패한 NGINX 프로세스를 즉시 감지하고 Dynatrace 플랫폼에서 문제 경고를 생성합니다.
3. Event-Driven Ansible에서 사용하는 Rulebook에 정의된 Dynatrace 소스 플러그인은 오류 이벤트를 능동적으로 폴링합니다.
4. Event-Driven Ansible은 이벤트에 대한 응답으로 다음 작업을 수행하는 작업 템플릿을 실행합니다.
   • ServiceNow 인시던트 티켓 생성을 시작합니다.
   • NGINX 프로세스를 다시 시작하려고 합니다.
   • 인시던트 티켓 상태를 'In Progress(진행 중)'로 업데이트합니다.
   • NGINX 프로세스가 성공적으로 복원된 경우에만 티켓을 종료합니다.

아래의 흐름도는 이러한 통합 구성 요소 간의 상호작용을 보여줍니다.

시작하기 전에 Event-Driven Ansible의 핵심 개념에 해당하는 몇 가지 용어를 익히는 시간을 갖겠습니다.

용어:

Ansible Rulebook은 이벤트 소스와 특정 조건이 충족될 때 수행할 작업에 대한 자세한 룰 기반 지침을 모두 포함하여 높은 수준의 유연성을 제공합니다.

의사 결정 환경은 Event-Driven Ansible 컨트롤러에서 사용되는 Ansible Rulebook을 실행하도록 제작된 컨테이너 이미지입니다. 

이벤트 소스 플러그인은 일반적으로 Python으로 구성되며 지정된 이벤트 소스에서 이벤트를 수집하는 데 사용됩니다. 또한 플러그인은 Red Hat Ansible Certified Content Collections를 통해 배포됩니다.

의사 결정 환경을 구축해야 합니다. 아래 빌드 파일 예시를 참조하십시오.

--- 
version: 3 

images: 
  base_image: 
    name: registry.redhat.io/ansible-automation-platform-24/de-minimal-rhel8:latest 

dependencies: 
  galaxy: 
    collections: 
      - ansible.eda 
      - dynatrace.event_driven_ansible 
  system: 
    - pkgconf-pkg-config [platform:rpm] 
    - systemd-devel [platform:rpm] 
    - gcc [platform:rpm] 
    - python39-devel [platform:rpm] 

options: 
  package_manager_path: /usr/bin/microdnf

의사 결정 환경 구성에 대한 추가 지침은 제공된 설명서를 참조하십시오. 의사 결정 환경을 생성한 후 컨테이너 이미지를 지정된 이미지 리포지토리로 푸시한 다음 Event-Driven Ansible 컨트롤러로 이미지를 풀링합니다.

의사 결정 환경이 구축되면 Event-Driven Ansible 컨트롤러에서 룰 활성화를 생성하게 됩니다. 이 활성화는 Rulebook을 캡슐화하여 특정 조건에서 실행되는 작업에 대한 자세한 지침과 함께 이벤트 소스를 정의합니다. 오토메이션 컨트롤러의 프로젝트 내 플레이북 구성과 유사하게 Event-Driven Ansible 컨트롤러는 프로젝트를 사용하여 Rulebook을 관리하고 포함합니다.

아래에는 Git 리포지토리에서 Rulebook과 플레이북을 구성하고 저장하기 위한 표준 디렉터리 계층 구조가 나와 있습니다.

Event-Driven Ansible 컨트롤러에서 프로젝트를 생성한 후에는 의사 결정 환경 내에서 실행되는 Rulebook에 의해 정의된 백그라운드 프로세스인 Rulebook 활성화를 생성해야 합니다.

이 활용 사례에서는 Dynatrace 플러그인을 Ansible 이벤트 소스로 사용하는 Rulebook을 구축하고, 조건이 충족될 때 수행할 작업을 지정합니다. 

일반적으로 소스 플러그인에는 세 가지 통합 패턴이 있습니다. 

1. 폴링
2. 웹후크
3. 메시징

활용 사례의 컨텍스트에서 Dynatrace 소스 플러그인은 Rulebook에 요약된 지정된 조건에 따라 능동적으로 폴링하여 이벤트를 효율적으로 검색합니다. 이 폴링 메커니즘은 Rulebook에 요약된 대로 delay 변수(Dynatrace 플러그인에 내재됨)를 도입합니다(Rulebook의 delay 변수 설정 참조). 

이 지연은 제한 메커니즘을 구현하여 플러그인의 동작을 규제하는 데 중요한 역할을 합니다. 기본적으로 이는 사전 정의된 간격으로 API 호출 실행을 오케스트레이션하므로 플러그인이 수신된 응답을 기반으로 새 이벤트를 생성할 수 있습니다. 이러한 의도적인 API 호출 페이싱은 전체 워크플로우를 관리 및 최적화하고, 속도 제한이 발생할 위험을 완화하고, 시스템이 원활하게 작동하도록 보장하는 데 중요한 역할을 합니다.

아래 Rulebook을 참조하세요.

--- 
- name: Watching for Problems on Dynatrace 
  hosts: all 
  sources: 
    - dynatrace.event_driven_ansible.dt_esa_api: 
        dt_api_host: "{{ dynatrace_host }}" 
        dt_api_token: "{{ dynatrace_token }}" 
        delay: "{{ dynatrace_delay }}" 

  rules: 
    - name: Look for open Process monitor problem 
      condition: event.title == "No process found for rule Nginx Host monitor" 
      action: 
        run_job_template: 
          name: Fix Nginx and update all 
          organization: "Default" 
          job_args: 
            extra_vars: 
              problemID: "{{ event.displayId }}" 
              reporting_host: "{{ event.impactedEntities[0].name }}"

참고: Red Hat은 이 코드의 정확성에 대한 주장에 어떠한 명시적 지원도 제공하지 않습니다. 별도로 명시되지 않은 한 모든 콘텐츠는 지원되지 않는 것으로 간주됩니다.

위의 Rulebook에는 주의가 필요한 YAML 형식의 키 두 개가 있습니다. 하나는 rules 섹션의 조건 키입니다. event.title은 'No process found for rule Nginx Host monitor'입니다. 하지만 해당 문자열은 어디에서 가져온 것일까요? 

두 번째로, 오토메이션 컨트롤러에서 실행할 작업 템플릿을 호출하는 action 섹션에서 reporting_host 변수를 살펴봅니다. event.impactedEntities[0].name은 어디에서 가져올까요? 

이벤트 기반 자동화 프로세스에서 이러한 키의 정의와 활용도를 살펴보기 위해 블로그를 자세히 살펴보겠습니다.

대상 호스트에 설치(Dynatace OneAgent)한 후에 액세스 토큰을 생성해야 합니다. 토큰에 다음 권한이 있는지 확인합니다.

NGINX 프로세스에 대해 호스트 수준 프로세스 가용성 모니터 룰을 구성해야 합니다. NGINX를 실행하는 호스트 이름이 오토메이션 컨트롤러 내의 인벤토리에 지정된 호스트 이름과 일치하는지 확인합니다.

모니터를 설정한 후에는 관리형 호스트에서 NGINX 프로세스를 종료하여 Event-Driven Ansible에서 Rulebook 활성화를 통해 폴링된 페이로드를 테스트할 수 있습니다. 

Event-Driven Ansible에서 페이로드가 어떻게 표시되는지에 대한 예시 룰 감사를 참조하십시오.

위의 예시에서는 Dynatrace의 페이로드 이벤트 데이터가 JSON 형식임을 확인할 수 있습니다. 조건에 대해 event.title에 설정된 문자열을 사용하며, reporting_host 변수는 event.impactedEntities[0].name 값에 의해 동적으로 설정됩니다. 참고 ImpactedEntities.name[0].name은(는) 둘 이상의 호스트일 수 있습니다.

이제 조건 키 값 및 reporting_host 변수를 설정하는 방법을 이해했습니다. 다음 단계는 무엇입니까? 

이제 오토메이션 컨트롤러에서 작업 템플릿으로 실행하기 위한 플레이북을 평가해 보겠습니다. 이 플레이북은 NGINX 프로세스가 다운된 것으로 보고하는 Event-Driven Ansible에 의해 트리거된 이벤트 페이로드가 Dynatrace에서 감지될 때 사용됩니다.

--- 
- name: Restore nginx service create, update and close ServiceNow ticket after Ansible restores services 
  hosts: "{{ reporting_host }}" 
  gather_facts: false 
  become: true 
  vars: 
    incident_description: Nginx Web Server is down 
    sn_impact: medium 
    sn_urgency: medium 
  tasks: 
    - name: Create an incident in ServiceNow 
      servicenow.itsm.incident: 
        state: new 
        description: " Dynatrace reported {{ problemID }}" 
        short_description: "Nginx is down per {{ problemID }} on {{ reporting_host }} reported by Dynatrace nginix monitor." 
        caller: admin 
        urgency: "{{ sn_urgency }}" 
        impact: "{{ sn_impact }}" 
      register: new_incident 
      delegate_to: localhost 

    - name: Display incident number 
      ansible.builtin.debug: 
        var: new_incident.record.number 

    - name: Pass incident number 
      ansible.builtin.set_fact: 
        ticket_number: "{{ new_incident.record.number }}" 

    - name: Try to restart nginx 
      ansible.builtin.service: 
        name: nginx 
        state: restarted 
      register: chksrvc 

    - name: Update incident in ServiceNow 
      servicenow.itsm.incident: 
        state: in_progress 
        number: "{{ ticket_number }}" 
        other: 
          comments: "Ansible automation is working on {{ problemID }}. on host {{ reporting_host }}" 
      delegate_to: localhost 

    - name: Validate service is up and update/close SNOW ticket 
      block: 
        - name: Close incident in ServiceNow 
          servicenow.itsm.incident: 
            state: closed 
            number: "{{ ticket_number }}" 
            close_code: "Solved (Permanently)" 
            close_notes: "Go back to bed. Ansible fixed problem {{ problemID }} on host {{ reporting_host }} reported by Dynatrace." 
          delegate_to: localhost 

      when: chksrvc.state == "started"

"Red Hat은 이 코드의 정확성에 대한 주장에 어떠한 명시적 지원도 제공하지 않습니다. 별도로 명시되지 않은 한 모든 콘텐츠는 지원되지 않는 것으로 간주됩니다."

오토메이션 컨트롤러에 설정할 작업 템플릿 이름은 Rulebook의 run_job_template 섹션에 지정된 이름과 일치해야 합니다. 이 활용 사례 예시의 컨텍스트에서 저는 작업 템플릿 내에 설문조사를 통합하여 Rulebook에서 전달된 대로 시작 시 problemID 및 reporting_host[ 변수에 대한 프롬프트를 활성화하도록 선택했습니다.

Red Hat의 활용 사례가 유효해지려면 오토메이션 컨트롤러를 ServiceNow와 통합해야 하고 오토메이션 컨트롤러에 자동화 실행 환경이 있어야 하며, 이 환경에는 작업 템플릿과 함께 사용되도록 구성된 ITSM ServiceNow 컬렉션이 포함되어야 합니다. 또한 문제 해결 플레이북을 포함하는 오토메이션 컨트롤러에 프로젝트를 생성했는지 확인하고 NGINX 웹 서버를 호스팅하는 호스트 이름이 오토메이션 컨트롤러의 인벤토리에 포함되어야 합니다. 마지막으로, Event-Driven Ansible 컨트롤러를 오토메이션 컨트롤러와 성공적으로 통합했는지 확인합니다.

이제 모든 것이 올바르게 설정되었으므로 호스트에서 NGINX 프로세스를 종료하여 이를 테스트하고 다음을 관찰해야 합니다.

1. Dynatrace에서 생성된 경고:
    

   

   
    

2. Event-Driven Ansible의 룰 감사 이벤트:
    

   

   
    

3. 오토메이션 컨트롤러에서 문제 해결 작업 템플릿이 실행되는 작업 이벤트
    

   

   
   
    

4. Dynatrace에서 보고한 문제 호스트에서 NGINX 프로세스가 복원되면 인시던트 티켓이 열리고, 업데이트되고, 닫힙니다.
    

   

이 예시 활용 사례에서는 Dynatrace 플러그인 및 의사 결정 환경을 소개하고, 소스에서 샘플 페이로드 이벤트 데이터를 탐색하여 변수를 동적으로 채우는 방법을 보여줍니다. Dynatrace에서 NGINX 프로세스에 대한 호스트 수준 프로세스 모니터를 구현했습니다. 또는 애플리케이션 수준 모니터링을 위해 Dynatrace에서 합성 모니터를 사용할 수도 있습니다.

적응성의 중요성을 강조하는 Red Hat의 문제 해결 플레이북은 동적이며, 특히 Dynatrace에서 문제가 있는 것으로 보고된 호스트에서만 실행되도록 범위가 지정되어 있습니다. 이 예시는 광범위한 주제를 다루지만, 복잡한 태스크를 자동화하기 위해 처음부터 모든 것을 포괄하는 접근 방식이 필요한 것은 아니라는 점을 인식해야 합니다. 대신, 수정 사항을 자동화하는 방법을 학습하면서 시간이 지남에 따라 문제 해결 작업을 플레이북에 점진적으로 통합하는 것이 좋습니다. 처음에는 문제 해결 작업을 구현하기 전에 인시던트 티켓을 열어 점차 일반적인 문제의 자동화로 전환하도록 선택할 수 있습니다. 표준 애자일 원칙을 자동화 여정에 적용하면 반복적이고 유연한 접근 방식이 가능합니다. 이제 일반적인 문제를 새벽 3시에 수동으로 해결하는 시대가 저물어 가고 있으며, 효과적인 엔터프라이즈급 자동화 사례를 통해 편안한 잠을 이룰 수 있습니다.

손쉽게 자동화하세요! 

추가 리소스 및 다음 단계

Event-Driven Ansible에 대해 자세히 알아보고 싶으신가요? 

• Event-Driven Ansible 웹 페이지
• 자기 주도식 랩: Event-Driven Ansible 등을 사용한 핸즈온 경험 
• Event-Driven Ansible 동영상 재생 목록