Computer >> 컴퓨터 >  >> 프로그램 작성 >> Ruby

네임스페이스를 사용하여 모놀리식 애플리케이션에서 모니터링 데이터 구조화

네임스페이스란 무엇입니까?

AppSignal에서 모니터링하는 애플리케이션에서 발생하는 모든 일은 네임스페이스 아래에 기록됩니다. 네임스페이스는 폴더처럼 작동하며 이벤트, 문제 및 모니터링 데이터를 관리 가능한 청크로 그룹화합니다.

기본적으로 모든 애플리케이션은 세 가지 기본 네임스페이스로 시작합니다. web , backgroundfrontend .

  • 웹 네임스페이스는 모든 HTTP 요청을 보유합니다. Rails 또는 Sinatra와 같은 MVC 지향 프레임워크에서는 여기에 컨트롤러 작업이 포함됩니다.
  • 백그라운드 네임스페이스는 백그라운드 작업, 라이브러리 및 작업의 활동을 보유합니다.
  • 프론트엔드 네임스페이스는 JavaScript 통합을 위해 AppSignal에서 보낸 이벤트를 기록합니다.

AppSignal은 내장된 애플리케이션별 및 통합별 규칙을 사용하여 수신 이벤트를 매핑합니다. 그러나 이러한 매핑은 언제든지 변경할 수 있으며 애플리케이션 구조를 모델링하기 위해 새 네임스페이스를 생성할 수도 있습니다.

Ruby에서 네임스페이스 시도

Ruby on Rails(ROR) 애플리케이션에서 네임스페이스를 사용해 보겠습니다. rails new로 새로운 Rails 프로젝트를 생성한 후 Rails 통합을 설정하면 web 대시보드의 네임스페이스

AppSignal은 컨트롤러에서 트랜잭션을 수신하는 즉시 네임스페이스를 표시합니다.

나머지 기본 네임스페이스는 활동이 있을 때까지 나타나지 않습니다. 좀 더 흥미롭게 만들기 위해 백그라운드 네임스페이스에 무언가를 추가해 보겠습니다. 프로젝트에 Sidekiq를 추가한 후 대시보드의 모습입니다(예제 저장소에서 코드 확인).

AppSignal은 Sidekiq를 작업 프로세서로 인식하기 때문에 백그라운드 네임스페이스에 작업을 할당합니다. AppSignal은 널리 사용되는 대부분의 백그라운드 프로세서와 통합되지만, 생략된 경우에는 언제든지 작업에 계측을 수동으로 추가할 수 있습니다.

사용자 지정 네임스페이스 생성

대규모 모놀리식 애플리케이션에서는 기본 네임스페이스가 너무 일반적으로 느껴질 수 있습니다. 대형 웹사이트는 일반적으로 다른 웹 서비스 중에서 정적 콘텐츠, 동적 페이지, API 끝점을 제공합니다. 이 대부분은 모두 web에서 끝납니다. 네임스페이스.

또한 응용 프로그램의 모든 부분에는 다른 우선 순위가 있습니다. 로그인 페이지 문제는 내부 관리 패널의 문제보다 훨씬 시급합니다. 그러나 AppSignal은 네임스페이스 내의 모든 문제를 동일하게 취급합니다. 활동이 많을 때는 가장 중요한 문제를 식별하기 어려울 수 있습니다.

따라서 우선 순위와 책임 영역별로 네임스페이스를 구성해야 합니다. 그런 다음 별도의 알림 정책을 첨부하여 이해 관계자에게만 알릴 수 있습니다. 이 추론에 따라 login_page에 대한 사용자 지정 네임스페이스를 만들 수 있습니다. , api_endpointsadmin_panel .

Ruby에서 새 네임스페이스를 생성하려면 Appsignal.set_namespace를 사용합니다. . urgent_background라는 네임스페이스에 작업을 생성하는 다음 코드를 살펴보세요. :

class FetchPricesWorker
    include Sidekiq::Worker
 
    def perform
        Appsignal.set_namespace("urgent_background")
 
        # worker code ...
 
    end
end

이 변경 사항을 적용하고 앱을 다시 시작하면 다음과 같은 새 작업이 새로 생성된 네임스페이스에 나타납니다.

대시보드에서 작업 이름을 확인하여 실제 작업이 기록되었음을 확인할 수 있습니다.

사용자 지정 네임스페이스는 모든 통합에서도 작동합니다.

네임스페이스 무시

커스텀 네임스페이스의 또 다른 이점은 우리가 신경 쓰지 않는 애플리케이션 부분의 이벤트를 무시할 수 있다는 것입니다. 예를 들어 admin_panel의 이벤트를 무시하도록 선택할 수 있습니다. 완전히.

네임스페이스를 무시하려면 다음 세 단계를 거쳐야 합니다.

  1. 모니터링하지 않으려는 부분을 사용자 지정 네임스페이스에 할당합니다.
  2. 네임스페이스를 무시하도록 통합을 구성합니다.
  3. 앱을 다시 시작하세요.

Ruby의 경우 AppSignal 구성 파일에 ignore_namespaces 옵션을 추가합니다.

production:
  ignore_namespaces:
    - "admin_panel"

네임스페이스를 무시하면 소스의 모든 트랜잭션 및 범위 데이터를 건너뜁니다. 맞춤 측정항목 데이터는 계속 보고됩니다.

Elixir와 JavaScript 통합에는 유사한 옵션이 있습니다. 자세한 내용은 네임스페이스 무시 가이드를 확인하세요.

모놀리식 애플리케이션을 위한 네임스페이스

이제 네임스페이스가 어떻게 작동하는지 알았으므로 이를 사용하여 모놀리식 애플리케이션을 분할할 수 있는 몇 가지 방법을 살펴보겠습니다.

정해진 규칙은 없지만 분할은 두 가지 전략으로 요약됩니다. 시작점으로 둘 중 하나를 선택하거나 둘을 혼합하여 선택할 수 있습니다.

  • 역할별 :프로젝트 내의 기능적 또는 논리적 단위에 네임스페이스를 할당합니다. 따라서 billing과 같은 네임스페이스를 정의하는 것이 합리적일 수 있습니다. , sign_in 또는 sign_up , admin_panelhomepage . AppSigal 대시보드를 한 눈에 보면 애플리케이션의 각 부분에서 무슨 일이 일어나고 있는지 이해할 수 있습니다. 이 접근 방식은 코드가 명확한 경계로 잘 분할될 수 있을 때 잘 작동합니다.
  • 심각도별 :여기서 우리는 우선순위 지정 장치로 네임스페이스를 사용합니다. 코드의 어느 부분이 critical인지 설정하는 것은 귀하에게 달려 있습니다. , important , medium , 또는 low . 이 접근 방식을 사용하면 먼저 해결하려는 문제를 즉시 분류할 수 있습니다.

사용자 로그인 및 등록을 처리하는 컨트롤러가 있다고 가정합니다. 역할별로 분할하도록 선택할 때 user_login에 매핑할 수 있습니다. 네임스페이스.

# in Rails we use before_action callback to change
# the namespace before the request starts
class LoginController < ApplicationController
    before_action :set_appsignal_namespace
 
    def set_appsignal_namespace
        # Sets the namespace
        Appsignal.set_namespace("user_login")
    end
 
    # controller actions ...
end

그러나 우선순위 네임스페이스를 사용하는 것을 선호한다면 청구를 담당하는 컨트롤러는 아마도 critical 네임스페이스.

class BillingPageController < ApplicationController
    before_action :set_appsignal_namespace
 
    def set_appsignal_namespace
        Appsignal.set_namespace("critical")
    end
end

이들로부터 상속받은 컨트롤러는 부모와 동일한 네임스페이스를 공유합니다.

# any controllers that inherit from LoginController
# are also part of the "user_login" namespace
class RegistrationController < LoginController
 
    # there’s no need for before_action here
    # this controller already reports to the parent’s namespace
 
end

우리가 본 것처럼 작업과 작업은 자동으로 background에 할당됩니다. 네임스페이스. 가능할 때마다 우리는 그것들을 더 구체적인 것들에 할당해야 합니다. 예를 들어 데이터베이스 정리 작업은 database 다음과 같은 네임스페이스:

class ActiveJobDatabaseCleanupJob < ActiveJob::Base
  queue_as :default
 
  def perform(argument = nil, options = {})
    Appsignal.set_namespace("database")

우선 순위는 작업에도 적용됩니다. 중요하지 않은 작업을 low에 할당할 수 있습니다. 예를 들어 이 Rake 작업에서와 같이:

task :unimportant_job do
 
  # Run this rake job in the low namespace
  Appsignal.set_namespace("low")
 
  # job code ...
 
end

어떤 경우에는 수동 트랜잭션을 사용하여 작업을 기록하고 싶을 것입니다. 사용자 정의 메일러 작업을 코딩하는 다음 예와 같이 네임스페이스를 생성하는 동안 정의할 수 있습니다.

class Job
    def perform
 
        # Create a transaction for this job and set the namespace
        transaction = Appsignal::Transaction.create(
            SecureRandom.uuid,
            "mailer",
            Appsignal::Transaction::GenericRequest.new(ENV.to_hash)
        )
 
        # job code ...
 
    end
end

네임스페이스 및 알림

팀의 모든 사람이 모든 문제에 대해 알림을 받을 필요는 없습니다. 프론트엔드 전문가는 백엔드 개발자만큼 백그라운드 작업에 신경 쓰지 않습니다. 그래도 그들은 백엔드에 문제가 있을 때 알고 싶어할 수 있습니다. 백엔드 개발자는 web에서 성능 문제에 대한 알림을 받고 싶어할 것입니다. 네임스페이스. 네임스페이스를 사용하면 알림을 적절한 사람에게 라우팅할 수 있습니다.

네임스페이스별 알림 설정

특정 네임스페이스에 대해서만 활성화되는 알림 그룹을 생성할 수 있습니다. 예를 들어 web의 오류에 대해 이메일을 보낼 수 있습니다. 네임스페이스를 사용하거나 frontend의 문제에 대해 #frontend Slack 채널로 메시지를 보냅니다. 네임스페이스.

네임스페이스별 알림 그룹을 만들려면 앱 설정> 알림> 알리미로 이동하고 통합 추가를 클릭하세요. .

통합 중 하나를 선택하고 해당 이름을 입력합니다. 보낼 메시지 유형과 네임스페이스를 선택합니다. 예를 들어 #frontend에 대한 Slack 알림을 생성해 보겠습니다. 채널.

아직 여기 있는 동안 백엔드 개발자를 위한 두 번째 알림을 만드세요.

팀에서 진행 중인 모든 정보를 최신 상태로 유지하는 데 필요한 만큼 알림을 구성할 수 있습니다.

네임스페이스별 알림 변경

인시던트가 생성되면 AppSignal은 알림 정책을 적용합니다. 이 정책은 오류가 발생한 네임스페이스를 기반으로 합니다. 각 네임스페이스에 대해 별도의 정책을 정의할 수 있습니다.

애플리케이션의 네임스페이스 기본값을 보려면 앱 설정> 알림> 네임스페이스 기본값으로 이동하세요. .

여기에서 모든 네임스페이스에 대한 오류 및 성능 알림을 사용자 지정하는 옵션을 찾을 수 있습니다.

  • 모든 경우 :인시던트가 트리거될 때마다 알림을 보냅니다. 쿨다운은 5분입니다.
  • 최초 배포 :애플리케이션 배포 후 첫 번째 오류를 알려줍니다.
  • 종료 후 첫 번째 :마감된 이슈가 다시 열릴 때 알림을 보냅니다.
  • 알리지 않음 :알림을 완전히 비활성화합니다.

네임스페이스별 트리거 생성

트리거는 AppSignal에 인시던트를 생성하고 메트릭이 사전 정의된 값을 초과하거나 미달할 때 알림을 보내도록 지시합니다. 애플리케이션의 다른 부분은 다른 임계값을 가질 수 있으므로 각 네임스페이스에 대해 별도의 트리거를 만들어야 합니다. 전형적인 예는 web에서 처리량이 너무 낮을 때 경고하는 트리거입니다. 네임스페이스.

트리거를 생성하려면 이상 감지> 트리거로 이동하고 첫 번째 트리거 추가를 클릭합니다. .

왼쪽 메뉴에서 작업 트리거 유형을 선택하고 관련 네임스페이스를 선택합니다. 그런 다음 경고를 트리거하는 임계값을 설정합니다.

여기에서 알림을 받아야 하는 그룹을 정의할 수도 있습니다. 완료하려면 트리거 저장을 클릭하세요. .

결론

네임스페이스를 사용하면 애플리케이션의 모니터링 데이터를 이해할 수 있습니다. 또한 세분화된 수준에서 알림 및 사건을 실행하고, 소음을 제한하고, 오탐지(false positive)를 방지하는 데 필수적입니다.

Ruby, Node.js, Elixir에서 커스텀 네임스페이스가 어떻게 작동하는지 확인한 후 다음을 읽고 네임스페이스 사용 방법을 계속 배우세요.

  • AppSignal의 네임스페이스
  • 네임스페이스로 그룹화
  • 웹훅 모니터링과 백그라운드 작업의 차이점
  • Gem 2.2 - 맞춤 네임스페이스!