Sidekiq 로깅

워커 컨텍스트

로그에서 워커에 대한 좀 더 많은 정보를 얻기 위해 ApplicationContext의 형식으로 작업에 메타데이터를 추가합니다. 대부분의 경우, 요청에서 작업을 예약할 때 이미 해당 컨텍스트가 요청에서 유도되어 예약된 작업에 추가됩니다.

작업이 실행될 때 예약될 때 활성화되어 있던 컨텍스트가 복원됩니다. 따라서 해당 컨텍스트는 실행 중인 작업 내부에서 예약된 다른 작업으로 전파됩니다.

이 모든 것은 대부분의 경우에 작업에 컨텍스트를 추가하기 위해 우리가 아무것도 할 필요가 없다는 것을 의미합니다.

그러나 작업이 예약될 때 컨텍스트가 없을 수도 있고, 무효일 가능성이 높은 컨텍스트가 있는 경우가 있습니다. 이러한 경우에 우리는 로그에 잘못된 메타데이터를 피하고 주의를 기울이기 위해 RuboCop 규칙을 추가했습니다.

우리의 대부분의 cop들과 마찬가지로, 이를 비활성화하는 것에 대해 완전히 타당한 이유가 있습니다. 이 경우에는 요청에서의 컨텍스트가 올바르다는 것일 수도 있습니다. 또는 이미 cops에서 잡히지 않은 방법으로 컨텍스트를 지정했을 수도 있습니다. 어쨌든, cops를 비활성화할 때 어떤 컨텍스트를 사용할지 가리키는 코드 코멘트를 남겨주세요.

컨텍스트를 제공할 때는 네임스페이스 및 프로젝트의 경로가 미리로딩되었는지 확인하세요. 이는 모든 Routable에 정의된 .with_route 스코프를 사용하여 수행될 수 있습니다.

크론 워커

크론잡 큐(include CronjobQueue)에 있는 워커의 컨텍스트는 자동으로 지워집니다. 심지어 요청에서 스케줄링하더라도 그렇습니다. 이는 다른 작업이 크론 워커에서 스케줄링될 때 잘못된 메타데이터를 피하기 위해 수행합니다.

크론 워커 자체는 인스턴스 전역으로 실행되므로 사용자, 네임스페이스, 프로젝트 또는 컨텍스트에 추가해야 하는 다른 리소스에 대해 범위가 지정되지 않습니다.

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

그래서 워커 내부에서 어디에서든 다음 중 하나의 메서드를 사용하여 컨텍스트를 표시해야 합니다:

작업을 예약하는 코드를 with_context 헬퍼로 감싸기: ```ruby 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 ```
```
컨텍스트를 제공하는 일괄 스케줄링 메서드 사용: ruby def schedule_projects_in_batch(projects) ProjectImportScheduleWorker.bulk_perform_async_with_contexts( projects, arguments_proc: -> (project) { project.id }, context_proc: -> (project) { { project: project } } ) end
또는 지연을 사용하여 스케줄링하는 경우: ruby 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 } }
    )

첫 번째 인수의 Enumerable로부터의 개별 객체는 두 개의 블록으로 전달됩니다.

작업이 예약되어야 하는 인수 목록을 반환해야 하는 arguments_proc.
작업의 컨텍스트 정보를 반환해야 하는 context_proc 입니다.

인수 로깅

Sidekiq 작업 인수는 기본적으로 로깅되나, SIDEKIQ_LOG_ARGUMENTS가 비활성화된 경우에는 로깅되지 않습니다.

기본적으로 숫자형 인수만 로깅되지만, 다른 타입의 인수는 민감한 정보를 포함할 수 있기 때문에 이를 무시하려면 loggable_arguments를 사용하세요. (숫자형 인수는 여기에 명시할 필요가 없습니다.)