시즈오카시에서 웹 개발하고 있는 프리랜서의 kazuomatz입니다.

표제대로, Exception Notification 되는 것의 존재도 알면서 좀 더 자신들의 운용에 맞는 형태로 Slack500 라는 Gem을 만들어 보았습니다.

계기는, Rails의 심각한 취약성 대응이나, AWS S3 서명 버전 2(SigV2) 사용 중지 *1등에 대응하기 위해서, Rails와 그 동료들(=Gem)을 갱신할 때, 그 영향 범위를 망라할 수 없기 때문이었습니다.

글쎄, RSpec 드디어 일이지만, 역시 이러한 업데이트에 의해 초래되는 것은 예측할 수 없는 경우도 있으므로, 업데이트 후의 운용 중, 재빨리 에러를 검지해 대응한다고 하는 대증요법적 어프로치도 생각 하려고 생각했습니다.

*1) 2020년 6월 24일 이행도 계속해서 연명되었습니다

개요

Slack500의 기능으로서는 심플하고 Controller로 rescue_from으로 예외를 캐치 한 앞에서 Slack500의 함수를 부르는 만들기입니다.

에러의 내용을 파악하기 위해서 최소한 필요한 내용을 통지합니다.

사용법

Gemfile에 추가하고,

Gemfile

gem 'slack_500'

bundle.

$ bundle

또는,

$ gem install slack_500

그런 다음 구성 파일을 작성하기 위해 rake 작업을 실행합니다.

$ rake slack_500:config

/config/initializers/slack_500.rb 파일이 가능하기 때문에 파일을 편집.

/config/initializers/slack_500.rb

require 'slack_500'
Slack500.setup do |config|
    # pretext
    config.pretext = 'Slack Report Title'

    # タイトル
    config.title = 'Rendering 500 with exception.'

    # メッセージの左に表示されるバーのカラー
    config.color = '#FF0000'

    # フッターに表示する文字列
    config.footer = 'via Slack 500 Report.'

    # WebHook URL
    # see https://slack.com/services/new/incoming-webhook
    config.webhook_url = "https://hooks.slack.com/services/xxxxxxxxx/xxxx"
end

구현 방법

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base

  if Rails.env.production?
    # Exceptionを補足
    rescue_from Exception, with: :rescue_500
  end

  :
  :

  def rescue_500(exception)

    # Slackに通知
    Slack500.post(request,exception)

    render 'error/500', status: :internal_server_error, layout: 'application'
    end

  :
  :

end

사용해 보았던 점

생각 밖으로 날아온다

테스트 해보니 이야기 입니다만, 날 수 있습니다. 파라미터에 의한 예외, nil 예외 등. 오류를 밟아준 사용자에게 감사하면서 수정합니다.

Slack 울리지 않는 상황이라면, 밤도 잠들 수 없는 상황이 되고, Slack님에게도 트래픽 부담을 걸어 버리므로, 이용은 계획적으로 부탁합니다.

아무렇지도 않게 크롤러로부터의 액세스로 통지가 날아 온다

예기치 않은 쿼리 매개 변수로 인한 예외 및 문자 코드 인코딩 예외 (incompatible character encodings : UTF-8 and ASCII-8BIT), Response를 JSON 만 제공하지만 크롤러가 text/html을 요청하여 예외 등을 찾을 수 있습니다. 네. 테스트 해보니 이야기 입니다만.

SEO적으로 영향이 있는 경우도 있으므로, 에러를 파괴하는 것이 좋을 것입니다. 안심해도 좋을 수도 있으므로 User Agent를 통지하기로 결정할 수 있도록 했습니다.

요약

전제로서 통상의 테스트로 망라할 수 없는 경우를 상정한 도입이라고 생각하는 것이 좋을 것입니다. 옛날 전에는, Gem이 가득 있어 Rails 굉장히라고 이야기였습니다만, 최근에는, Gem의 작자도 메인터넌스를 포기해 버리는 케이스도 많아져 온 것 같은 생각도 합니다. Gem의 의존관계가 복잡해져서 부주의하게 bunlde update하면 ​​움직이지 않게 되는 케이스도 상당히 증가해 온 것 같은···.

그런 것을 포함하여 Slack500에서 운용을 해 나가고 싶습니다.