Sidekiq 로깅

작업자 컨텍스트

로그에서 작업자에 대한 추가 정보를 얻기 위해, 메타데이터를 ApplicationContext 형태로 작업에 추가합니다.

대부분의 경우, 요청에서 작업을 예약할 때 이 컨텍스트는 이미 요청으로부터 유도되어 예약된 작업에 추가됩니다.

작업이 실행될 때, 예약되었을 때 활성 상태였던 컨텍스트가 복원됩니다. 이로 인해 실행 중인 작업 내에서 예약된 모든 작업에 컨텍스트가 전파됩니다.

이 모든 것은 대부분의 경우 작업에 컨텍스트를 추가하기 위해 특별한 조치를 취할 필요가 없음을 의미합니다.

하지만 작업이 예약될 때 컨텍스트가 없거나 존재하는 컨텍스트가 부정확할 가능성이 있는 일부 경우도 있습니다. 이러한 경우를 위해, 잘못된 메타데이터가 로그에 남지 않도록 주의를 기울이기 위해 RuboCop 규칙을 추가했습니다.

대부분의 우리의 경찰 규칙들과 마찬가지로, 이를 비활성화할 수 있는 완벽히 유효한 이유가 있습니다. 이 경우, 요청으로부터의 컨텍스트가 올바를 수 있습니다. 또는 아마도 경찰이 감지하지 못한 방식으로 이미 컨텍스트를 지정했을 수 있습니다. 어쨌든, 경찰을 비활성화할 때 사용할 컨텍스트를 지정하는 코드 주석을 남기십시오.

컨텍스트에 객체를 제공할 때는 네임스페이스와 프로젝트의 경로가 미리 로드되도록 해야 합니다. 모든 Routable에서 정의된 .with_route 범위를 사용하여 이를 수행할 수 있습니다.

크론 작업자

컨텍스트는 크론잡 큐의 작업자에 대해 자동으로 지워집니다 (include CronjobQueue), 요청에서 이를 예약할 때도 마찬가지입니다. 이는 크론 작업자로부터 다른 작업이 예약될 때 잘못된 메타데이터가 발생하는 것을 피하기 위해 수행합니다.

크론 작업자 자체는 인스턴스 전체에서 실행되므로, 사용자, 네임스페이스, 프로젝트 등 컨텍스트에 추가해야 하는 다른 리소스에 구속되지 않습니다.

그러나 그들은 종종 컨텍스트가 필요한 다른 작업을 예약합니다.

그래서 작업자 내에서 어딘가에 컨텍스트를 나타낼 필요가 있습니다. 이를 위해 작업자 내에서 다음 방법 중 하나를 사용하여 수행할 수 있습니다:

  1. 작업을 예약하는 코드를 with_context 헬퍼로 감싸세요:

      def perform
    deletion_cutoff = Gitlab::CurrentSettings
                        .deletion_adjourned_period.days.ago.to_date
    projects = Project.with_route.with_namespace
                 .aimed_for_deletion(deletion_cutoff)

    projects.find_each(batch_size: 100).with_index do |project, index|
      delay = index * INTERVAL

      with_context(project: project) do
        AdjournedProjectDeletionWorker.perform_in(delay, project.id)
      end
    end
  end

  2. 컨텍스트를 제공하는 배치 예약 메서드를 사용하세요:

      def schedule_projects_in_batch(projects)
    ProjectImportScheduleWorker.bulk_perform_async_with_contexts(
      projects,
      arguments_proc: -> (project) { project.id },
      context_proc: -> (project) { { project: project } }
    )
  end

    또는, 지연과 함께 예약할 때:

      diffs.each_batch(of: BATCH_SIZE) do |diffs, index|
    DeleteDiffFilesWorker
      .bulk_perform_in_with_contexts(index *  5.minutes,
                                     diffs,
                                     arguments_proc: -> (diff) { diff.id },
                                     context_proc: -> (diff) { { project: diff.merge_request.target_project } })
  end

대량으로 예약된 작업

대량으로 작업을 예약할 때, 이러한 작업은 포괄적인 맥락이 아닌 별도의 맥락을 가져야 합니다.

그럴 경우, bulk_perform_async는 bulk_perform_async_with_context 헬퍼로 대체할 수 있으며, bulk_perform_in 대신 bulk_perform_in_with_context를 사용합니다.

예를 들어:

    ProjectImportScheduleWorker.bulk_perform_async_with_contexts(
      projects,
      arguments_proc: -> (project) { project.id },
      context_proc: -> (project) { { project: project } }
    )

첫 번째 인수의 열거 가능한 각 객체는 2개의 블록으로 전달됩니다:

  • 작업을 예약하는 데 필요한 인수 목록을 반환해야 하는 arguments_proc.

  • 작업의 맥락 정보가 포함된 해시를 반환해야 하는 context_proc.

인수 로깅

Sidekiq 작업 인수는 기본적으로 로깅되며, SIDEKIQ_LOG_ARGUMENTS가 비활성화되지 않는 한 로깅됩니다.

기본적으로 로깅되는 유일한 인수는 숫자 인수입니다. 다른 유형의 인수는 민감한 정보를 포함할 수 있기 때문입니다. 이를 오버라이드하려면, 로깅할 인수의 인덱스와 함께 작업자 내부에서 loggable_arguments를 사용합니다. (숫자 인수는 여기서 지정할 필요가 없습니다.)

예를 들어:

class MyWorker
  include ApplicationWorker

  loggable_arguments 1, 3

  # object_id는 숫자이므로 로깅됩니다
  # string_a는 loggable_arguments 호출로 인해 로깅됩니다
  # string_b는 로그에서 필터링됩니다
  # string_c는 loggable_arguments 호출로 인해 로깅됩니다
  def perform(object_id, string_a, string_b, string_c)
  end
end