기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Amazon EventBridge에서 이벤트 전송을 모니터링하는 모범 사례
<a name="eb-monitoring-events-best-practices"></a>

이벤트 기반 애플리케이션의 비즈니스 로직이 안정적으로 실행되도록 하려면 이벤트 전송 동작을 모니터링해야 합니다. EventBridge는 신뢰할 수 있는 이벤트 전송을 보장하기 위해, 문제를 조기에 모니터링, 감지 및 완화할 수 있는 지표를 제공합니다. 이러한 지표에는 다음이 포함됩니다.
+ `InvocationAttempts`, `SuccessfulInvocationAttempts`, `RetryInvocationAttempts`, `FailedInvocations` 등 카운터 기반 지표가 대상 스로틀링을 관찰하고 오류율을 계산할 수 있도록 합니다.
+ `IngestionToInvocationSuccessLatency`와 같은 지연 시간 기반 지표가 이벤트 전송 및 지연에 대한 인사이트를 제공합니다.

이러한 지표를 사용하면 이벤트 기반 아키텍처의 상태를 모니터링할 수 있으며, 성능이 저조하거나 크기가 작거나 응답이 없는 대상으로 인한 이벤트 전송 문제를 이해하고 완화할 수 있습니다. 예를 들어, 영구적으로 규모가 축소되거나 스로틀링된 대상은 과도한 재시도, 이벤트 전송 지연 및 영구적인 전송 실패로 이어질 수 있습니다.

여러 지표를 결합하여 전체적인 개요를 파악하고 이를 면밀히 모니터링하는 것이 좋습니다. 적절한 경보 및 대시보드를 설정하면 지속적인 문제를 조기에 해결할 수 있습니다.

특정 지표에 대한 자세한 내용은 [EventBridge 지표](eb-monitoring.md#eb-metrics) 섹션을 참조하세요.

## 이벤트 전송 실패 감지
<a name="eb-monitoring-events-best-practices-delivery-failures"></a>

EventBridge에는 규칙별로 대상 간접 호출, 즉 이벤트 전송 시도를 보고하도록 구성할 수 있는 지표가 포함되어 있습니다.

규칙 수준에서 다음 지표를 모니터링하는 것이 좋습니다.
+ `InvocationAttempts`로 이벤트 전달 재시도를 포함하여 EventBridge가 대상을 간접적으로 호출하려고 시도하는 총 횟수를 관찰합니다.
+ `SuccessfulInvocationAttempts`는 EventBridge가 이벤트를 대상에 성공적으로 전달한 간접 호출 시도 횟수입니다.
+ `RetryInvocationAttempts`는 이벤트 전송 재시도 횟수를 나타냅니다.

  `RetryInvocationAttempts`의 증가는 크기가 작은 대상의 초기 징후일 수 있습니다.

또한, 재시도 횟수가 증가하면 전송 문제의 첫 번째 징후가 될 수 있으므로, 모든 대상 간접 호출에 대한 성공적인 대상 간접 호출의 비율을 추적하는 단일 지표를 생성하는 것이 좋습니다. 예를 들어, CloudWatch에서는 다음 공식을 사용하여 `SuccessfulInvocationRate`라는 지표를 생성하는 지표 수학을 사용할 수 있습니다.

`SuccessfulInvocationRate` = `SuccessfulInvocationAttempts` / ` InvocationAttempts`

그런 다음, 요구 사항에 따라 특정 임곗값에 도달하면 알림을 생성하도록 CloudWatch 경보를 구성할 수 있습니다.

일시적인 트래픽 급증 또는 간접 호출 오류로 인해 `SuccessfulInvocationRate`가 가끔씩 감소하는 것은 정상으로 간주될 수 있지만, 지속적인 불일치는 잘못 구성된 대상을 나타내는 것이므로 공동 책임 모델의 일부로 해결해야 합니다.

지표 수학에 대한 자세한 내용은 *Amazon CloudWatch 사용 설명서*에서 [CloudWatch 지표에 수학 표현식 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 참조하세요.

기본적으로 EventBridge는 24시간 동안 최대 185회까지 이벤트 전송을 재시도합니다. EventBridge는 이러한 재시도 횟수를 소진한 후, 이벤트를 삭제하거나 Dead Letter Queue(DLQ)가 지정된 경우 해당 DLQ로 전송합니다. 자세한 내용은 [이벤트 전송 재시도](eb-rule-retry-policy.md) 단원을 참조하십시오. 이벤트가 전달되지 않아 손실되는 것을 방지하려면, 각 규칙 대상에 대해 Dead Letter Queue(DLQ)를 구성하는 것이 좋습니다. 자세한 내용은 [DLQ(Dead Letter Queue) 사용](eb-rule-dlq.md) 섹션을 참조하세요.

EventBridge가 지정된 대상에 전달하지 못하는 이벤트는 대상에 대한 Dead Letter Queue(DLQ)를 구성한 경우 `FailedInvocations` 지표와 `InvocationsSentToDlq` 지표에 보고됩니다. 애플리케이션에 `FailedInvocations` 또는 `InvocationsSentToDlq` 보고의 수가 많은 경우, 대상의 규모가 적절하게 조정되고 지정된 트래픽을 수신할 수 있는지 조사하는 것이 좋습니다.

## 이벤트 전송 지연 감지
<a name="eb-monitoring-events-best-practices-delivery-latency"></a>

또한 EventBridge는 이벤트 수집부터 대상에 성공적으로 전송하기까지 걸리는 시간, 즉 엔드 투 엔드 지연 시간을 관찰할 수 있는 지표를 제공합니다. 이는 `IngestionToInvocationSuccessLatency` 지표를 통해 달성할 수 있습니다. 이 지표는 예를 들어, 시간 초과 및 대상의 느린 응답으로 인해 재시도 및 전송 지연에서 기인하는 영향을 드러냅니다. `IngestionToInvocationSuccessLatency`에는 대상이 이벤트 전송에 성공적으로 응답하는 데 걸리는 시간이 포함됩니다. 이를 통해 EventBridge와 대상 간의 엔드 투 엔드 지연 시간을 모니터링하고, 대상 스로틀링이나 오류가 없더라도 대상의 성능 변동 및 저하를 감지할 수 있습니다.