두 부분으로 구성된 이 시리즈의 첫 번째 부분에서 Ruby on Rails 애플리케이션에서 즉시 사용할 수 있는 많은 유용한 정보를 위해 AppSignal을 설정하는 방법을 다루었습니다. AppSignal은 자동으로 오류를 추적하고 성능을 모니터링하며 일부 종속성에 대한 지표를 보고할 수 있습니다.
그러나 많은 경우에 각 애플리케이션은 서로 다른 방식으로 작동하므로 일반적인 모니터링 이상의 기능이 필요합니다.
이 게시물에서는 Ruby on Rails 애플리케이션에 사용자 지정 계측 및 모니터링을 추가하는 방법을 살펴보겠습니다. 이렇게 하면 애플리케이션이 어떻게 작동하는지 더 깊이 이해할 수 있습니다.
코드를 따르려면 전제 조건:
- www.appsignal.com의 계정
- Docker 설치 및 실행(
docker-compose사용) )
이 게시물을 따라가려면 샘플 애플리케이션에서 자신의 AppSignal 계정으로 AppSignal을 설정해야 합니다.
맞춤형 계측 및 모니터링
기본적으로 제공되는 AppSignal 도구보다 더 많은 것이 필요한 경우 AppSignalgem을 사용하여 Rails 애플리케이션에 사용자 정의 도구를 추가할 수 있습니다.
강령의 일부를 계측
응용 프로그램에 새 기능을 추가하려고 한다고 가정해 보겠습니다. 사용자가 /posts를 방문할 때 모든 게시물을 보려면 제목이 특정 문자(또는 훨씬 더 복잡한 🪄)로 시작하는 게시물을 필터링할 수 있어야 합니다.
이 새로운 검색 기능은 이미 Post에 구현되었습니다. Post.where_title_starts_with 메서드가 있는 모델 . PostsController#index를 업데이트합시다. 특정 쿼리 매개변수가 있는 경우 새 방법을 사용하려면:
# app/controllers/posts_controller.rb
def index
starts_with = params[:starts_with]
@posts = if starts_with.present?
Post.where_title_starts_with(starts_with)
else
Post.all
end
end이것은 응용 프로그램의 핵심 부분이므로 성능이 어떻게 변하고 언제 성능이 변경되는지 알고 싶을 것입니다. AppSignal은 이를 위한 몇 가지 방법을 제공합니다.
먼저 Post.where_title_starts_with의 콘텐츠를 계측합니다. 방법. 코드 블록에 대한 통찰력을 얻으려면 계측 블록을 사용하여 코드 블록을 포장할 수 있습니다. 다음과 같이 방법을 업데이트하십시오.
# app/models/post.rb
def self.where_title_starts_with(letter)
Appsignal.instrument('Post.where_title_starts_with', "Fetch posts that start with letter") do
Analytics.track_post_title_search(letter.downcase)
select('*, pg_sleep(0.01)').where("title ILIKE :letter", letter: "#{letter.downcase}%").load
end
end
두 번째로 Analytics.track_post_title_search도 계측하고 싶습니다. app/services/analytics.rb 때문에 메서드가 호출되었습니다. 무거운 처리를 하고 있습니다. 이 경우 메서드 계측을 사용하여 전체 메서드를 보다 정확하게 계측합니다.
# app/services/analytics.rb
require 'appsignal/integrations/object'
class Analytics
def self.track_post_title_search(letter, sleep = sleep(1))
# Some heavy processing
sleep 1
end
appsignal_instrument_class_method :track_post_title_search
end통찰
위의 내용을 애플리케이션에 저장한 후 몇 분 후에 AppSignal 대시보드에서 사용할 수 있는 새로운 정보를 살펴보십시오(정보가 표시되지 않으면 도커 컨테이너를 다시 시작해야 할 수 있음). 검색 매개변수가 있는 게시물 색인 페이지를 방문하여 새 기능이 작동하는지 확인할 수 있습니다. https://localhost:3000/posts?starts_with=f
데이터베이스에 생성된 게시물의 수에 따라 /posts 엔드포인트가 훨씬 느려질 것입니다.
AppSignal에서 성능 문제('Performance' -> 'Issuelist')를 열고 PostsController#index를 보는 경우 작업을 수행하면 페이지 아래쪽에 '이벤트 타임라인'이 표시됩니다. 이렇게 하면 특정 코드를 실행하는 데 소요된 시간을 분석할 수 있습니다.
이 타임라인은 모든 성능 이벤트에 대해 존재하지만 여기에서 사용자 정의 계측 이벤트도 볼 수 있습니다. Post.where_title_starts_with를 호출하면 실행하는 데 8.84초 소요, Analytics.track_post_title_search에서 2.01초 사용 메서드 및 활성 레코드 쿼리에 의해 사용된 남은 시간. 추가 조사를 위해 개별 이벤트를 클릭하고 해당 성능에 대한 추가 정보를 볼 수도 있습니다. sql.active_record 이벤트.
AppSignal의 계측 도우미는 애플리케이션 코드에 대한 보다 자세한 분석을 제공하므로 애플리케이션의 성능에 영향을 줄 수 있다고 생각되는 특정 코드 조각에 대한 통찰력을 더 쉽게 얻을 수 있습니다. AppSignal의 계측 가이드에서 이에 대해 자세히 알아볼 수 있습니다.
예외 처리
코드의 성능을 모니터링하는 것 외에도 응용 프로그램이 예상대로 작동하지 않는 경우와 문제가 발생하는 부분도 알아야 합니다. 우리는 AppSignal이 ourcode에서 처리되지 않은 예외를 보고하는 방법을 이미 보았습니다. 그러나 항상 상자에서 나오는 것보다 더 많은 것이 있습니다.
간헐적인 오류를 일으키는 기존 코드를 제거하여 시작할 수 있습니다. 대시보드에서 오류를 볼 때 역추적에서 이 오류가 발생하는 위치를 확인합니다. app/controllers/pages_controller.rb 내부 if 제거 성명:
class PagesController < ApplicationController
def home
CreateRandomPostsJob.perform_later
end
end이제 개요 대시보드에서 애플리케이션의 오류율이 크게 떨어집니다.
현재 사용자가 존재하지 않는 게시물을 보려고 하면 응용 프로그램이 충돌합니다(예:https://localhost:3000/posts/doesnotexist. 대신 메시지를 표시할 수 있습니다. PostsController 내에서 이러한 일이 발생할 수 있는 위치에 추가 . #set_post 업데이트 방법:
# app/controllers/posts_controller.rb
class PostsController < ApplicationController
.
.
.
private
def set_post
@post = Post.find(params[:id])
rescue ActiveRecord::RecordNotFound => e
render json: { error: "Oops. That post isn't here" } , status: :not_found
end
.
.
end
예외를 수동으로 처리하기 때문에 AppSignal에 자동으로 보고되지 않습니다. Appsignal.set_error를 사용하여 수동으로 오류를 추적할 수 있습니다. .
오류를 추적하는 가장 쉬운 방법은 Appsignal.set_error(e)와 같은 함수의 유일한 인수로 오류를 추가하는 것입니다. . 또한 요청에 더 많은 컨텍스트를 추가할 수 있는 기능을 활용하고자 합니다. AppSignal을 사용하면 Appsignal.tag_request를 사용하여 자신의 임의 정보로 태그 이벤트를 수행할 수 있습니다. :
def set_post
Appsignal.tag_request(user_id: 'user-from-params', post_id: params[:id])
@post = Post.find(params[:id])
rescue ActiveRecord::RecordNotFound => e
Appsignal.set_error(e)
render json: { error: "Oops. That post isn't here" }, status: :not_found
end이제 https://localhost:3000/posts/doesnotexist를 방문하여 애플리케이션 충돌이 발생하지 않고 JSON 응답이 예상대로 반환되는지 확인하십시오.
통찰
존재하지 않는 게시물을 보려고 하면 추가된 업데이트로 인해 AppSignal에 오류가 보고됩니다. AppSignal 대시보드의 '오류 -> 문제 목록'에서 , 새로 보고된 오류(ActiveRecord::RecordNotFound ).
오류 세부 정보 페이지는 기본적으로 HTTP 메서드, 매개 변수 및 세션 데이터와 같은 요청에 대한 정보를 포함하는 오류에 대한 유용한 컨텍스트를 제공합니다. 맞춤 태그도 포함되어 있어 일치하는 태그로 모든 오류를 필터링할 수 있습니다.
요청에 태그를 지정했기 때문에 이 정보를 오류 및 기타 계측 이벤트에 추가합니다. 개별 게시물(예:https://localhost:3000/posts/1)을 몇 번 보면 성능 측정('Performance' -> 'Issue list' -> 'PostsController#show'). 가이드에서 트랜잭션 태그 지정에 대해 자세히 알아볼 수 있습니다.
트랜잭션에 사용자 지정 메타데이터를 추가하는 이 기능은 프로덕션에서 문제를 진단하는 데 도움이 되는 많은 기회를 제공합니다. 이에 대한 좋은 예는 Kubernetes 메타데이터를 오류에 추가하는 것입니다.
측정항목
이제 몇 가지 사용자 지정 계측 및 오류 모니터링이 있으므로 게시물 검색에 큰 폭의 스파이크가 발생하는 경우가 있음을 알 수 있습니다. 사용자가 검색할 때마다 Analytics#track_post_title_search 일부 계산을 수행하고 타사 서비스에 대한 API 호출을 수행하는 이 호출됩니다. 이 타사에는 API에 대한 속도 제한이 있습니다. 우리는 애플리케이션이 한계에 얼마나 근접했는지 주시하기 위해 얼마나 자주 호출되는지 추적하고자 합니다.
AppSignal을 사용하면 애플리케이션 전체에서 원하는 대로 맞춤 측정항목을 추적할 수 있습니다.
먼저 카운터와 태그를 사용하여 분석 서비스를 호출하는 빈도와 데이터를 추적합니다.
#app/services/analytics.rb
require 'appsignal/integrations/object'
class Analytics
def self.track_post_title_search(letter, sleep = sleep(1))
Appsignal.increment_counter("track_post_search", 1, { letter: letter })
# Some heavy processing
sleep 1
end
appsignal_instrument_class_method :track_post_title_search
end
두 번째로, PostsController#index에서 반환되는 게시물 수도 추적합니다. , 이것이 애플리케이션 동작의 핵심 부분이고 계속해서 성장한다는 것을 알고 있기 때문입니다.
#app/controllers/posts_controller.rb
class PostsController < ApplicationController
.
.
def index
.
.
Appsignal.set_gauge("posts_index", @posts.size, starts_with: params[:starts_with])
end
end애플리케이션에서 여전히 실행 중인 가짜 트래픽 스크립트는 일부 데이터를 생성하지만 더 다양하게 추가하기 위해 f,l 및v로 시작하는 게시물도 검색해 보겠습니다.
통찰
사용자 지정 메트릭을 보려면 AppSignal에서 사용자 지정 그래프가 있는 대시보드를 만들어야 합니다. 이것은 UI를 통해 수행할 수 있지만 이 예제에서는 하나만 가져옵니다. '대시보드' 섹션에서 '대시보드 추가'를 클릭하고 다음이 포함된 대시보드를 가져옵니다.
{
"title": "Post Search",
"description": "Sample dashboard about posts search activity",
"visuals": [
{
"title": "Analytics",
"line_label": "%name% %letter%",
"display": "LINE",
"format": "number",
"draw_null_as_zero": true,
"metrics": [
{
"name": "track_post_search",
"fields": [
{
"field": "COUNTER"
}
],
"tags": [
{
"key": "letter",
"value": "*"
}
]
}
],
"type": "timeseries"
},
{
"title": "Search",
"line_label": "%name% %starts_with%",
"display": "LINE",
"format": "number",
"draw_null_as_zero": true,
"metrics": [
{
"name": "posts_index",
"fields": [
{
"field": "GAUGE"
}
],
"tags": [
{
"key": "starts_with",
"value": "*"
}
]
}
],
"type": "timeseries"
}
]
}몇 분 안에 그래프에 데이터가 표시되어야 합니다. 선 위로 마우스를 가져가면 보고 있는 기간 내에 수집된 측정항목의 범례가 표시됩니다.
이것은 각 태그 값에 대해 다른 행을 표시합니다. 현재 우리의 가짜 트래픽은 e 문자만 검색하고 있습니다. , 하지만 다른 문자를 수동으로 검색했기 때문에 다른 데이터 포인트를 나타내는 각 문자에 대한 새 선이 그래프에 표시됩니다.
그것으로 충분하다고 생각하십니까? AppSignal에는 여기에서 다루지 않을 더 많은 맞춤형 계측 솔루션이 있습니다. 간단히 언급할 가치가 있는 것은 breadcrumbs입니다.Breadcrumbs를 사용하면 애플리케이션에서 작업 목록을 추적할 수 있으며, 그러면 오류로 보고됩니다. 오류가 발생한 원인에 대한 보다 구체적이고 순서화된 정보를 얻을 수 있습니다.
가이드에서 맞춤형 계측에 대한 모든 내용을 읽어보세요.
요약:AppSignal로 Ruby 앱을 위한 맞춤형 계측 및 모니터링
이 시리즈의 1부에서는 Ruby 애플리케이션을 위한 AppSignal의 기본 설정 및 사용을 다루었습니다.
이 부분에서는 이미 뛰어난 기본 모니터링 기능을 갖춘 애플리케이션을 가져와서 AppSignal gem을 사용하여 더 잘 만들었습니다.
AppSignal의 맞춤형 계측, 오류 추적 및 성능 모니터링 기능은 애플리케이션이 어떻게 작동하는지에 대한 통찰력을 제공합니다. 필요할 때 사용자가 제어할 수 있도록 하는 동시에 응용 프로그램에 즉시 사용할 수 있는 기능을 제공합니다.
코드가 어떻게 작동하는지 계속 주시하는 한 코드를 자유롭게 실행할 수 있습니다. 즐거운 코딩!
추신 Ruby Magic 게시물이 언론에 공개되는 즉시 읽고 싶다면 Ruby Magic 뉴스레터를 구독하고 게시물을 놓치지 마세요!