AWS의 LLM 관찰 가능성: 감사 에이전트 코어 범위 대상

AWS의 LLM 관측 가능성 에 대한 실질적인 대답은 "CloudWatch 대시보드 열기"가 아닙니다. 먼저 Amazon Bedrock AgentCore가 스팬을 제공해야 하는 위치를 확인한 다음 증거를 포함할 수 있는 모든 대상을 검색하고, 세션 및 추적 ID를 확인하고, 오래된 관찰을 거부하고, 의도한 외부 결과에 대한 별도의 영수증에 추적을 결합합니다. AgentCore의 대상은 변경될 수 있으므로 순서가 중요합니다. 현재 AWS 문서에 따르면 지원되는 새 에이전트는 에이전트별 로그 그룹에 범위를 보낼 수 있지만 이전 구성은 공유 aws/spans 그룹을 사용할 수 있습니다. 0.18.0 이전의 ADOT 버전은 통합 대상 설정을 무시합니다. 설정을 변경해도 이전 범위는 이동되지 않습니다. 따라서 오늘의 로그 그룹에 대해서만 쿼리하면 누락된 증거가 정확히 이전 구성에 있던 위치에 있더라도 잘못된 "원격 측정 없음" 진단이 생성될 수 있습니다. 이 가이드는 해당 경계에 대한 콘텐츠 없는 감사를 구축합니다. 리소스 ID, 버전, 대상, 타임스탬프, 상관 관계 식별자, 실행 상태 및 부울 결과 수신을 사용합니다. 프롬프트, 응답, 도구 인수 또는 비밀이 필요하지 않습니다. 실종을 선언하기 전에 증거를 찾으세요 AgentCore 관찰 가능성 AgentCore 리소스에 대한 기본 지표를 제공하고 Amazon CloudWatch에 지표, 범위 및 로그를 저장합니다. 중요한 경계는 기본 제공 측정항목이 애플리케이션 추적과 동일하지 않다는 것입니다. AWS는 메모리 리소스의 기본 범위를 문서화하는 반면, 에이전트 런타임 및 게이트웨이 추적 세부 정보는 계측에 따라 다릅니다. 그러면 세 가지 별도의 질문이 생성됩니다. 1. AWS 관찰 경로가 활성화되어 있습니까? CloudWatch 트랜잭션 검색이 활성화되어 있어야 하며 추적 세그먼트 대상은 CloudWatch Logs여야 합니다. 2. 현재 범위는 어디에 배치되어야 합니까? 대답은 통합 대상 설정, 지역 지원, 에이전트 기간, 실행 역할 및 ADOT 버전에 따라 다릅니다. 3. 기록 범위는 어디에 남을 수 있습니까? AWS는 기존 범위 데이터를 마이그레이션하지 않기 때문에 전환 이전에 사용된 모든 대상은 조사 기간의 일부로 유지됩니다. 그만큼 AgentCore 구성 가이드 특히 유용한 운영 경계를 제공합니다. 에이전트별 통합 전달에는 aws opentelemetry distro =0.18.0 가 필요합니다. 이전 버전에서는 구성을 무시하고 공유 그룹에 범위를 전달합니다. 동일한 가이드에는 관련 CloudWatch Logs 리소스 정책을 설치하기 위한 권한이 필요합니다. 쿼리하기 전에 이러한 사실을 사용하여 예상 목적지를 계산하십시오. 관찰 예상되는 현재 검색 범위 운영자 결론 거래 검색이 비활성화되었습니다. 아직은 믿을 만한 사람이 없습니다 설정 수정; 에이전트 상태를 추론하지 마세요. CloudWatch Logs로 라우팅되지 않은 추적 세그먼트 아직은 믿을 만한 사람이 없습니다 대상 전제조건 수정 통합 요청됨, 0.18.0 아래의 ADOT 공유 aws/spans 비어 있는 에이전트별 그룹은 쿼리 범위 오류입니다. 통합 활성 및 역할 정책 허용 에이전트별 런타임 로그 그룹 거기에서 현재 범위를 확인하세요. 검토 기간 동안 목적지가 변경되었습니다. 현재 및 이전 그룹 둘 다 검색하세요. 오래된 스팬은 착륙한 곳에 그대로 유지됩니다. 이 테이블은 의도적으로 단일 "원격 측정 존재" 확인이 아닙니다. 에이전트별 그룹의 누락된 기록은 설정 실패, 전달 차단, 이전 ADOT 버전 또는 공유 그룹의 올바른 기록 기록을 의미할 수 있습니다. 해당 주에는 다른 수리가 필요합니다. 목적지 전환 기록을 유지하세요 활성 설정을 유일한 정보 소스로 삼지 마십시오. Runbook 옆에 작은 전환 기록을 저장합니다. 레코드에는 프롬프트나 응답 콘텐츠가 없습니다. 이는 대시보드가 ​​나중에 재구성할 수 없는 쿼리 계획 질문(인시던트 창과 겹치는 대상은 무엇입니까?)에 대한 답변입니다. 마이그레이션 인식 AgentCore 감사 실행 이 기사에 사용된 감사에서는 11개의 고정 사례를 평가합니다. 입력 계약은 의도적으로 작습니다. 결정 순서는 구문보다 더 중요합니다. 생성된 픽스쳐에 대해 분류기를 실행합니다. 사례에는 비활성화된 트랜잭션 검색, 잘못된 추적 대상, 에이전트별 그룹에서만 쿼리된 이전 ADOT, 전환 후 기록 증거 생략, 전달 권한 부족, 현재 범위 누락, 오래된 증거, 상관 관계 끊어짐, 합법적인 승인 대기, 잘못된 완료 및 정상적인 마이그레이션 인식 결과가 포함됩니다. 이는 실제 AWS 계정에 대한 증거가 아닌 결정 테스트입니다. 자체 구성 및 카나리아 쿼리에서 입력을 조정합니다. 순서를 유지하십시오. 그렇지 않으면 일반 telemetry missing 판결이 운영자가 잘못된 장소를 검색했다는 훨씬 더 실행 가능한 사실을 숨길 수 있습니다. 세션 ID 유지, ID 추적 및 최신성 유지 AWS는 AgentCore 관측성을 계층 구조로 설명합니다. 즉, 세션에는 추적이 포함되고 추적에는 범위가 포함됩니다. 그만큼 원격 측정 문서 해당 계층 구조를 명시적으로 만듭니다. 요청 경로에서 ID가 유지되는 경우에만 유용합니다. ADOT 계측 AgentCore 런타임 호출의 경우 구성 가이드에는 두 가지 전파 세부 정보가 문서화되어 있습니다. 세션 ID가 다운스트림 원격 측정에 도달하도록 X Amzn Bedrock AgentCore Runtime Session Id 를 보냅니다. 추적 ID를 전파해야 하는 경우 traceId=<traceId 를 사용하여 런타임을 호출하십시오. 민감한 페이로드 컨텍스트가 아닌 해당 식별자가 있는지 여부를 기록합니다. 조인 가능한 세션이 없는 범위는 코드가 실행되었음을 증명할 수 있지만 세션 수준 인시던트 타임라인을 지원할 수는 없습니다. 건강하지 않은 correlation broken 로 분류하십시오. 신선함에도 마찬가지로 명시적인 계약이 필요합니다. 지난주에 발견된 추적은 현재 배달이 작동한다는 것을 증명하지 않습니다. 정의하다: 워크플로의 예상 흐름 및 사고 허용 범위에서 최대 수명을 선택합니다. 매분 카나리아의 경우 5분이 합리적입니다. 야간 배치에는 불합리합니다. "신선한" 상태를 검사할 수 있도록 판정과 함께 임계값을 저장합니다. 기다리는 것도 증거가 필요합니다. 추적에 소유자와의 제한된 승인 종속성이 표시되고 실행이 재개 가능한 경우 waiting 를 반환합니다. 새로운 도구 범위가 나타나지 않았다는 이유만으로 중단된 것으로 페이지를 표시하지 마십시오. 승인 기록이 없거나 모순되거나 만료된 경우 uncertain 를 반환하거나 Runbook에 따라 에스컬레이션하세요. 추적 후 결과 영수증 필요 전체 추적은 "계측된 실행 경로가 완료되었습니까?"라고 대답합니다. 반드시 “의도한 작업이 이루어졌습니까?”라고 대답하는 것은 아닙니다. 일반적인 오류에서 차이점을 확인할 수 있습니다. 대상이 객체를 커밋하기 전에 업로드 도구가 반환됩니다. API 메시지가 요청을 수락했지만 메시지가 의도한 채널에 도달하지 않습니다. 필요한 아티팩트가 원격 저장소에 속해 있는 동안 에이전트는 로컬 파일을 작성합니다. 다운스트림 트랜잭션이 이미 롤백된 후에 최종 모델 호출이 성공합니다. 승인 대기가 터미널 성공으로 잘못 변환되었습니다. AWS 규정 지침 LLM 증거와 다운스트림 영향의 상관관계를 권장합니다. 개인 정보 보호를 최소화하는 구현에서는 결과 영수증을 통해 이를 수행할 수 있습니다. 영수증은 객체 HEAD , 안정적인 키로 읽은 데이터베이스, 공개 API 가져오기, 체크섬 또는 대상 테스트 등 사용 가능한 가장 강력한 결정론적 검사를 통해 생성되어야 합니다. 개체 본문, 프롬프트, 응답 또는 암호를 포함해서는 안 됩니다. 두 가지 평결을 별도로 유지하십시오. 추적 증거 결과 영수증 상태 누락되었거나 오래되었습니다. 어느 관측가능성 증거가 불충분함 완벽한 없어진 false complete 기록된 승인을 기다리는 중 아직 예상되지 않음 waiting 완전하고 신선함 제시 및 검증됨 이 테스트 결과에 대한 healthy 마지막 행에는 범위가 지정됩니다. 모든 경로, 모든 작업 또는 의미론적 출력 품질이 아닌 고정된 카나리아 및 대상을 증명합니다. 콘텐츠 수집 없이 감사 채택 유용한 생산 영수증에는 실패 레이어를 구별할 만큼 충분한 데이터만 있으면 됩니다. 수정되거나 해시된 형식의 에이전트 리소스 및 엔드포인트 식별자 지역 및 관측시간 거래 검색 및 추적 대상 상태 ADOT 버전 및 통합 대상 설정; 현재 및 이전 대상 클래스; 조사창에서 두 목적지를 모두 검색했는지 여부; 최신 일치 카나리아 시간; 세션 ID 및 추적 ID의 존재; 실행 상태 및 제한된 승인 상태; 안정적인 운영 정체성과 결정론적인 결과 접수 상태. 이 영수증에서 프롬프트 텍스트, 모델 응답, 도구 인수, 자격 증명, 원시 헤더 및 고객 페이로드를 유지하세요. 특정 사고에 대해 심층적인 콘텐츠 검사가 필요한 경우 별도로 승인하고 범위를 지정하세요. 감사에도 한계가 있습니다. 모든 애플리케이션 경로에 대한 계측 적용 범위, 샘플링 완전성, CloudWatch 보존, 내보내기 복구 또는 의미론적 응답 품질을 입증하지는 않습니다. 선택한 증거 경로가 구성 및 검색 가능하고, 카나리아가 신선하고 상관 관계가 있으며, 선택한 외부 결과에 자체 영수증이 있음을 증명합니다. 이는 운영자가 잘못된 범위 대상을 검색했기 때문에 에이전트를 변경하는 비용이 많이 드는 범주 오류를 방지하기에 충분합니다. Sidewisp는 현재 비공개 프리뷰 단계입니다. 의도된 역할은 대상 적용 범위, 신선도, 상관 관계, 대기 상태 및 결과 확인과 같은 증거를 명확한 상태 보기로 전환하는 것입니다. Production AgentCore 및 CloudWatch 모니터링 어댑터는 현재 배송되지 않으므로 이 문서는 Sidewisp가 이미 이 감사를 실행했다는 주장이 아니라 지금 적용할 수 있는 운영 패턴입니다.