요약: The Graph의 TAP 마이그레이션 마감일은 2024년 12월 3일이며, 인덱서의 약 34%가 업그레이드되어 쿼리 볼륨의 81.6%를 차지합니다. Q&A 토론에서는 특히 RAV(Receipt Aggregation Voucher) 요청 및 집계되지 않은 요금 관리와 관련된 TAP의 구성 설정에 중점을 두고 기본값으로 시작하고 쿼리 볼륨에 따라 조정하라는 권장 사항을 제시했습니다.
안녕하세요 여러분, Indexer Office Hours 회의록, 세션 184에 오신 것을 환영합니다!
영상 링크: https://youtu.be/w0LZkVJemPY
Persistence Labs의 COO인 Jeroen Develter와 함께 GRTiQ 팟캐스트를 시청하세요. Jeroen의 web3 여정은 전통적인 금융, 컨설팅 세계에서 시작하여 암호화폐와 블록체인의 세계로 뛰어들었습니다.
중요한 저장소에 대한 최신 업데이트
- Geth 새 버전 v1.4.12:
- 날짜: 2024-11-19 13:53:28 UTC
- 이 릴리스에서는 더 이상 사용되지 않는 개인 RPC 네임스페이스와 –unlock 명령을 제거하여 키 관리에 대한 중요한 변경 사항을 나타냅니다. 또한 최적화, 데이터베이스 개선, 다양한 버그 수정은 물론 트래커 구성에 대한 중요한 변경 사항도 포함되어 있습니다.
- 비상 표시기: 노란색
- 긴급 이유: 키 관리 변경에는 사용자 조정이 필요합니다.
- Reth 새 버전 v1.1.2
- 날짜: 2024-11-19 16:27:10 UTC
- 이번 릴리스에는 성능 개선, 버그 수정, 새로운 하드 포크에 대한 중요한 준비가 포함되어 있습니다. 이러한 변경 사항은 특히 페이로드 작업 획득을 최적화하고 보류 중인 트랜잭션 순서를 해결하므로 OP-reth 사용자가 최신 상태를 유지하는 것이 중요합니다.
- 비상 표시기: 빨간색
- 긴급한 이유: OP-reth 사용자를 위한 하드포크 준비.
- sfeth/fireeth: 새 버전 v2.8.0:
- 날짜: 2024-11-14 14:55:01 UTC
- CombinedFilter는 거래 처리 중 안정성을 높이기 위해 안전 검사를 전혀 통합하지 않습니다. 또한 하위 스트림 및 dmetering 업데이트에는 측정 기능 개선이 포함됩니다.
- 비상 표시기: 노란색
- 긴급한 이유: 즉각적인 위협이 아니라 안정성이 향상되었습니다.
- 눈사태: 새 버전 v1.11.13:
- 날짜: 2024-11-18 22:24:03 UTC
- 이 릴리스에서는 플랫폼에 새로운 API가 도입되었으며 RPCChainVM 지표 초기화에 대한 수정 사항과 호환성 개선 사항이 포함되었습니다. 호환성과 안정성을 높이기 위해 Operator를 최신 플러그인 버전으로 업데이트하는 것이 좋습니다.
- 비상 표시기: 노란색
- 긴급 이유: 중요한 수정 사항과 새로운 기능에는 즉각적인 주의가 필요합니다.
- 인덱서 서비스 및 에이전트(TS): 새 버전 v0.21.8:
- 날짜: 2024-11-18 19:23:13 UTC
- 이 릴리스에는 몇 가지 사소한 업데이트가 포함되어 있으며 하위 그래프 높이 충돌 메시지를 무시하여 사용자 인터페이스를 개선하고 인덱스 에이전트의 폴링 간격 매개변수를 수정합니다. 시스템 성능이나 보안에 영향을 미치는 중요한 변경 사항은 발견되지 않았습니다.
- 비상 표시기: 녹색
- 긴급 이유: 변경 영향이 적고 심각한 문제가 없습니다.
- 인덱서 서비스 및 클릭 에이전트(RS): 새 버전 indexer-tap-agent-v1.7.3:
- 날짜: 2024-11-13 19:04:13 UTC
- 버전 1.7.3에서는 트랜잭션 처리에 영향을 미칠 수 있는 관리형 어댑터 검사를 제거하여 버그를 해결합니다. 모든 운영자는 원활한 기능을 보장하기 위해 이 변경 사항을 검토해야 합니다.
- 비상 표시기: 노란색
- 긴급 이유: 중요한 수정 사항이며 중요하지는 않지만 최대한 빨리 업데이트하는 것이 좋습니다.
프로토콜의 중요한 변경 사항에 대한 최신 업데이트
- The Graph의 향상된 중재: 실무 그룹 출범, 중재 위원회 확장 및 프로세스 업데이트
- 새로운 중재 실무 그룹은 새로운 분석가가 합류할 때까지 일시적으로 중재 분석가의 직무를 맡게 됩니다.
- 중재 패널의 확장은 중재에서 높은 기준을 유지하려는 The Graph의 약속을 강화합니다.
- 개선이 필요한 부분을 파악하기 위해 중재 프로세스를 적극적으로 검토하고 있습니다.
- FAQ 및 참조 자료는 포럼 게시물을 참조하세요.
- 분쟁 #GDR-19에 관한 정보 요청
- 이 분쟁은 동일한 색인 작성기가 이전에 슬래싱을 초래한 동작을 반복했기 때문에 GDR-18과 관련이 있습니다.
- 일반: 로컬이 아닌 체인 #1070에는 hardhat-secure-accounts를 사용하십시오(공개).
- 일반: Bump Ignition 버전 0.15.7 #1069(공개)
- 수정 사항: 배포 스크립트에 누락된 매개변수를 추가하고 SubgraphService 실행 횟수를 50배로 줄였습니다. #1062(열기)
오늘의 토론은 GraphOps의 Ana와 Semiotic Labs의 Gustavo와 함께하는 TAP 마이그레이션 Q&A입니다. TAP는 The Graph를 쿼리하기 위한 새로운 소액 결제 시스템입니다.
🚨 인덱서는 2024년 12월 3일 이전에 TAP으로 마이그레이션해야 합니다.
세션은 토론의 일부 배경 정보와 함께 이 섹션에 복사된 Ana의 IOH TAP 마이그레이션 Q&A 노트를 바탕으로 진행되었습니다. 댓글은 가볍게 수정했습니다
Ana |GraphOps: TAP가 무엇인지부터 시작해볼까요?
TAP(타임라인 집계 프로토콜) 개요:
- 기존 Scalar 결제 시스템을 대체합니다.
- 효율적인 소액 결제, 온체인 거래 감소, 영수증에 대한 인덱서 제어 등의 주요 기능을 갖추고 있습니다.
- 인덱서가 여러 게이트웨이의 쿼리를 허용하도록 허용하여 분산형 게이트웨이를 활성화합니다.
인덱서는 무엇을 해야 합니까?
- indexer-agent(버전 0.21.4 이상)를 실행하도록 인덱서 스택을 업데이트하고, Rust 버전을 실행하도록 indexer-service를 교체하고, 새 구성 요소 indexer-tap-agent를 추가합니다.
- 인덱서 저장소(indexer-agent)
- Indexer-rs 코드 베이스(indexer-service 및 indexer-tap-agent)
- 의지:
- Kubernetes를 사용하는 경우 launchpad-charts/graph-network-indexer를 사용하세요.
- Docker Compose를 사용하는 경우 StakeSquid 스택을 사용하세요.
- TAP 마이그레이션 가이드
Mickey |The Graph |E&N: 인덱서가 마감일을 놓치면 어떻게 되나요? 게이트웨이는 업그레이드될 때까지 새로운 쿼리를 라우팅하지 않습니다. 아니면...?
- Gustavo |Semiotic Labs: 게이트웨이는 현재 Scalar 및 TAP에 대한 영수증을 제공합니다. 마감일에 도달하면 게이트웨이는 TAP 영수증만 지원합니다. 버전이 1.0 미만인 경우 더 이상 문의를 받을 수 없습니다.
- 아나: 고마워요, 그렇군요. 따라서 계속해서 쿼리를 받으려면 마이그레이션해야 합니다.
Mickey |The Graph |E&N: indexer-rs/tap으로 이동된 인덱서의 비율을 알 수 있는 방법이 있습니까?
- Ana: 인덱서가 TAP으로 마이그레이션되었는지 확인하는 한 가지 방법은 GraphSeer의 인덱서 구성 파일에 TAP READY라는 레이블이 붙은 배지가 있는지 확인하는 것입니다.
- Gustavo: Semiotic에서는 이 수치를 면밀히 추적하여 인덱서가 1.0보다 높은 버전을 실행하고 있는지 확인하고 있습니다. 우리가 추적하는 88개의 인덱서 중 30개는 인덱서 버전 1.0 이상을 실행하고 있으며 이는 인덱서의 약 34%를 차지합니다.
- 또한 지난 달 각 쿼리에 대해 제공된 쿼리 수를 추적하고 있으므로 현재 쿼리의 81.6%가 TAP를 통해 실행되고 있습니다.
- Ana: 제 생각에는 쿼리 볼륨이 가장 높은 인덱서가 업그레이드되었다는 말씀이신 것 같아요.
- 구스타보: 그렇죠. 상위 10개 인덱서 중 9개가 업그레이드되었습니다. 실제로 처음 14개의 인덱서 중 13개가 업그레이드되었습니다.
Mickey |The Graph |E&N: 많은 인덱서가 업그레이드하는 데 문제가 있는 것 같습니다. 그 생각이 맞습니까? 그렇다면 모든 사람이 업그레이드할 수 있는 마감일인 12월 3일이 현실적인가요? (음영 없음, 이것이 충분히 안정적인지 궁금합니다)
- 구스타보: 대부분의 쿼리가 제대로 진행되고 있다고 생각합니다. 12월 3일 마감일 이전에 인덱서를 100% 마이그레이션하는 것은 다소 어렵지만 95%까지는 쉽게 도달할 수 있다고 생각합니다. 우리는 100%에 도달할 수 있도록 여러분을 지원하기 위해 왔습니다.
Mickey |The Graph |E&N: 왜 [인덱서]가 88개인가요? 이것이 실제로 쿼리를 제공하는 것입니까?
- 구스타보: 우리는 QoS(서비스 품질) 하위 그래프를 사용하여 모든 활성 인덱서를 확인하므로 기본적으로 지난 달에 쿼리를 제공한 경우 88 목록에 나타납니다. 우리는 주로 쿼리에 관심을 갖고 있으며, 쿼리를 제공하는 인덱서가 최신 버전을 사용하고 있다면 만족합니다.
paka |E&N: 또한 대부분의 쿼리 트래픽이 TAP으로 유입될 것이라고 확신합니다.
미키 |더 그래프 |E&N: 알겠습니다! 좋은 전략.
미키 |더그래프 |E&N: 문의는 했으나 아직 업그레이드하지 못한 후발자에게 개별적으로 연락을 주나요?
- 구스타보: 연락한 인덱서들과 연락을 취하는 중입니다. 우리는 목록을 가지고 있으며 가장 큰 것부터 시작하여 각각에게 연락하고 있습니다. 현재 아직 업그레이드되지 않은 가장 큰 두 가지는 Upgrade Indexer [Edge & Node]와 Pinax입니다. 우리는 Edge 및 Node와 긴밀히 협력하여 1.0 이상의 버전으로의 업그레이드를 지원할 수 있도록 하고 있습니다. 해당 인덱서와 연결되어 있는 한, 제공되는 볼륨이 가장 높은 쿼리부터 볼륨이 가장 적은 쿼리까지 하나씩 작업합니다.
Ana: 인덱서는 마이그레이션된 인덱서에 도움을 요청하는 것을 환영합니다. 질문이 있으시면 언제든지 문의해 주세요.
Gustavo | 기호학 연구실: 질문이 있는 분은 The Graph Discord의 📁︱indexers 및 📁︱indexers -소프트웨어 채널에서 답변해 드리겠습니다.
- 집계되지 않은 요금 및 RAV 요청:
- 문제: 특히 rav_request_trigger_value가 너무 낮게 설정된 경우 인덱서에서 집계되지 않은 요금 정체를 볼 수 있습니다.
- 설명: rav_request_trigger_value는 인덱서가 보낸 사람에게 RAV(Receipt Aggregation Voucher)를 요청하는 시기를 결정합니다(보낸 사람을 게이트웨이로 생각할 수 있음). 이 값이 너무 낮으면 트리거가 충분히 자주 충족되지 않아 롤업되지 않고 요금이 누적될 수 있습니다.
- 해결 방법: max_amount_willing_to_lose_grt / Trigger_value_divisor로 계산된 rav_request_trigger_value를 업데이트하세요.
Ana: 여기에 대시보드가 있어요. 집계되지 않은 패널에서 트리거 값을 볼 수 있습니다. 제 경우에는 RAV 트리거 값이 3입니다. 작동 방식은 새 영수증이 수신되면 해당 값이 집계되지 않은 비용에 추가되고 시스템은 집계되지 않은 총 비용이 트리거 값을 초과하는지 지속적으로 확인하는 것입니다.
트리거 조건이 충족되면 타임스탬프 버퍼를 확인하여 수신이 수신으로 간주되는 시간을 결정하기 위해 RAV 요청이 생성되고 RAV 요청 수신 제한에 따라 수신 수를 제한합니다.
구성을 간략하게 살펴보면 여기서 중요한 몇 가지 사항이 있습니다.
- max_amount_willing_to_lose_GRT
- Trigger_value_divisor
이 두 가지가 트리거 값을 결정합니다.
- timestamp_buffer_secs, 즉 영수증이 고려되는 시간
- max_receipts_per_request, RAV에는 최대 10000개의 영수증이 포함될 수 있습니다.
잘못된 영수증이 있는 경우 인덱서 메타데이터 데이터베이스의 Scaler TAP 잘못된 영수증 테이블에 별도로 저장됩니다. max_receipt_value_GRT가 이 값보다 높으면 영수증이 유효하지 않습니다.
구성: maximal-config-example-toml
구스타보: 여기서 무슨 일이 일어나고 있는지, 그리고 왜 구성이 많은지에 대해 이야기하고 싶습니다. 대부분의 인덱서에서는 쿼리 볼륨이 크지 않기 때문에 이러한 구성은 문제가 되지 않습니다.
초당 할당량이 너무 많거나 쿼리가 너무 많으면 약간 어려울 수 있으므로 이러한 항목을 업데이트하고 구성해야 합니다. 일반적으로 먼저 기본값을 사용해 보고 확인하는 것이 좋습니다. 현재 기본값은 다음과 같습니다.
- max_amount_willing_to_lose_GRT = 20
- Trigger_value_divisor = 10
- 즉, 요약되지 않은 영수증(요약되지 않은 요금이라고도 함)의 총액이 2 GRT에 도달할 때마다 합산을 시도한다는 의미입니다. 그러나 값이 항상 2보다 큰 경우에는 이 값을 변경해야 합니다.
- max_amount_willing_to_lose_GRT를 최대한 낮게 유지하세요. 하지만 RAV 요청이 실패하고 대규모 인덱서이기 때문에 그 당시 영수증을 많이 받으면 발신자를 매우 빠르게 차단하게 됩니다.
- timestamp_buffer_secs = 60
- request_timeout_secs = 5
- max_receipts_per_request = 10000
처음 15~20개의 인덱서는 이러한 값을 업데이트해야 합니다.
피에르 | Chain-Insights.io: 나의 이상적인 가치는 무엇입니까? 기본값이 여전히 나에게 좋은가요? RAV 요청이 없는 것 같습니다.
처음 15~20개의 인덱서는 이러한 값을 업데이트해야 합니다.
피에르 | Chain-Insights.io: 나의 이상적인 가치는 무엇입니까? 기본값이 여전히 나에게 좋은가요? RAV 요청이 없는 것 같습니다.
구스타보: 확인해 보겠습니다... 트리거 값 총 집계되지 않은 비용입니다. 먼저 몇 가지 업데이트를 살펴보겠습니다. 어떤 버전을 사용하고 있나요?
피에르: 최신 버전이에요.
구스타보: 일반적으로 RAV 트리거에 도달하면 RAV 요청 생성을 시도해야 합니다. 이런 일이 발생하지 않으면 조사를 해야 합니다.
피에르 | Chain-Insights.io: 나에게는 해당되지 않음:
tap: max_amount_willing_to_lose_grt: 20 tap.rav_request: trigger_value_divisor: 2 timestamp_buffer_secs: 60 request_timeout_secs: 5 max_receipts_per_request: 10000
구스타보: 그러면 트리거 값이 약 10이군요, 그렇죠?
Pierre 게시: 예, 20/2
구스타보: 따라서 특정 할당에 대해 10 GRT 또는 10000 영수증에 도달한 경우에만 RAV 요청을 트리거합니다. 쿼리 양으로 인해 약 0.1 또는 다음을 권장합니다.
max_amount_willing_to_lose_grt: 1 trigger_value_divisor: 10 max_receipts_per_request: 1000
Pierre가 게시한 내용: 알겠습니다. 감사합니다.
구스타보: 초당 쿼리 수가 많지 않으면 RAV 요청이 더 많거나 트리거 값이 더 커야 합니다.
이는 열려 있는 할당 수, 수신하는 초당 쿼리 수, 할당당 초당 쿼리 수 및 버스트에 따라 달라집니다.
TAP에서는 특정 시점에 집계한 후 해당 시점 이전의 타임스탬프가 포함된 영수증은 작동하지 않습니다. 유효하지 않은 것으로 간주되므로 이 버퍼가 있는 것입니다. 60초 후에만 영수증을 받습니다. 이는 서로 다른 컴퓨터 간에 시계를 동기화하는 것이 어렵기 때문입니다. 게이트웨이는 영수증을 보내고 타임스탬프를 정의합니다. 타임스탬프는 시계 전후 5초일 수 있습니다.
우리는 기본값을 초당 1-2개의 쿼리와 15분마다 1개의 RAV 요청 사이로 설정했습니다. 그러나 메모리 양이 이보다 적다면 더 낮은 max_amount_willing_to_lose_grt로 업데이트해야 할 수도 있습니다. 이 숫자를 초과하면 더 많은 숫자로 업데이트해야 할 수도 있습니다.
Gemma | LunaNova: 이 값은 할당당입니까, 아니면 모든 할당에 걸쳐 있습니까?
calinah | GraphOps: 할당별
Pierre | Chain-Insights.io: 다음 버전으로 업데이트한 후:
Gemma|LunaNova: 이 값은 할당당인가요, 아니면 모든 할당에 걸쳐 있나요?
calinah | GraphOps: 할당별
Pierre | Chain-Insights.io: 다음 버전으로 업데이트한 후:
calinah |GraphOps: 좋습니다. 승인률이 향상되었습니다.
구스타보: 네, 좋아요. 따라서 대시보드에 대해 원하는 것은 집계되지 않은 요금이 항상 0.1로 유지되어야 한다는 것입니다. 따라서 RAV 요청이 있을 때마다 요금이 조금씩 낮아지고 15분 후에는 또 다른 RAV 요청을 트리거할 만큼 충분한 영수증을 갖게 됩니다.
Josh Kauffman |StreamingFast.io: 누구든지 이 값에 대해 설정한 것을 공유할 수 있습니까?
Marc-André |Ellipfra: 참고로 저는 캠페인에 이 값을 사용했습니다. 나는 그것들이 다소 무작위로 설정되기 때문에 특별히 권장하지 않습니다. max_willing_to_lose는 게이트웨이를 너무 자주 거부하는 것을 피하기 위해 매우 높으며, 어느 시점에서는 이를 낮출 계획입니다.
max_amount_willing_to_lose_grt = "1000.0" [tap.rav_request] timestamp_buffer_secs = 30 trigger_value_divisor = 50 request_timeout_secs = 20 max_receipts_per_request = 2000
- 발신자 거부 문제:
- 발신자가 tap.sender_aggregator_endpoints에 나열되지 않습니다.
- 발송인의 에스크로 잔액이 미결제 비용을 충당하기에 부족합니다.
- 집계되지 않은 수수료가 max_fee_per_sender 한도를 초과합니다.
- 문제: 인덱서에서 보낸 사람이 거부되어 쿼리 처리 및 수익이 중단될 수 있습니다.
- 거부 이유: 발신자가 거부되는 세 가지 주요 이유는 다음과 같습니다.
- 해결 방법: 각 거부 사유에 대한 구체적인 해결 방법:
- tap.sender_aggregator_endpoints 섹션에서 발신자가 올바르게 구성되었는지 확인하세요.
- 에스크로 자금에 대한 잠재적인 문제를 조사하고 적절한 잔액을 보장합니다.
- 집계되지 않은 요금이 한도에 자주 도달하는 경우 max_amount_willing_to_lose_grt 설정을 검토하고 조정하세요.
- 참고: 인덱서 TAP 에이전트는 항상 다음 이름으로 시작됩니다.
2024-11-13T08:41:31.200776Z ERROR indexer_tap_agent::agent::sender_accounts_manager: There was an error while starting the sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490, denying it. Error: No sender_aggregator_endpoints found for sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490 in ractor::actor::Actor with id: "0.0" at tap-agent/src/agent/sender_accounts_manager.rs:311 2024-11-13T08:41:31.200776Z ERROR indexer_tap_agent::agent::sender_accounts_manager: There was an error while starting the sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490, denying it. Error: No sender_aggregator_endpoints found for sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490
tap.sender_aggregator_endpoints에 없거나 env vars를 통해 INDEXER_TAP__SENDER_AGGREGATOR_ENDPOINTS__의 경우
- 인덱서 에이전트의 영수증 끝점 수집 오류:
- 인덱서-에이전트의 수집-수신-엔드포인트 错误:
{"level":40,"time":1731239677641,"pid":1,"hostname":"graph-network-indexer-agent-0","name":"IndexerAgent","msg":"The option '--collect-receipts-endpoint' is deprecated. Please use the option '--gateway-endpoint' to inform the Gateway base URL."}
구스타보: 당신이 보낸 사람을 거부하려는 이유는 보낸 사람이 당신에게 돈을 지불하지 않아서 에스크로가 충분하지 않거나 당신이 잃을 의향이 있는 금액을 요구하기 때문입니다. 발생할 수 있는 또 다른 문제는 이를 위해 잘못된 영수증을 사용한다는 것입니다. 따라서 잘못된 영수증 수가 손실될 수 있는 최대값에 도달하면 해당 발신자를 차단하게 됩니다.
max_receipt_value_grt에 대한 빠른 업데이트는 이것이 해당 서비스에만 적용된다는 것입니다. TAP가 최소한의 신뢰를 받으려면 소액 결제여야 하므로 게이트웨이가 영수증을 보내면 이는 유효하지 않은 영수증으로 간주되지 않고 수락할 수 있는 최대 영수증 값입니다.
유효하지 않은 영수증은 귀하가 받은 영수증이며, 문의한 후 영수증이 유효하지 않음을 발견한 것입니다.
Ana: 유효하지 않은 영수증의 경우 조건이 변경되면 적용되나요, 아니면 영수증이 유효하지 않은 것으로 표시되면 재시도가 없나요?
구스타보: 재시도는 없습니다. 이 테이블은 로깅에만 사용되므로 데이터베이스에 액세스하여 무슨 일이 일어났는지, 영수증이 실패한 이유를 확인할 수 있습니다.
아나: 그렇군요. 또한 TAP 제어판에서 보낸 사람이 차단되었는지 확인할 수 있습니다.
- RAV 요청 오류:
- 문제: RAV 요청 중 오류로 인해 집계 프로세스가 중단될 수 있습니다.
- 오류 예: RAV 요청에 유효한 영수증이 없는 것 같습니다... rav_request_trigger_value를 늘려 이 문제를 해결할 수 있습니다.
- 설명: 이 오류는 rav_request_trigger_value가 부족하여 수신이 RAV 요청에 포함되지 않음을 나타냅니다.
- 해결 방법: 오류 메시지에 해결책이 제공됩니다. rav_request_trigger_value를 늘리세요.
- 소프트웨어 버전: indexer-agent, indexer-service 및 tap-agent에 필요한 소프트웨어 버전을 사용합니다.
- 구성 파일 연습:
- 공유 구성: indexer-service 및 tap-agent는 공통 TOML 구성 파일을 공유합니다.
- 블록체인 주소 및 엔드포인트:
- 중요: 올바른 계약 주소, 게이트웨이 엔드포인트 및 체인 ID를 사용하세요.
- 로그 수준 구성: 적절한 로깅을 위해 RUST_LOG 환경 변수를 설정하려면 RUST_LOG=indexer_tap_agent=debug,info를 사용합니다.
- 측정항목 및 Grafana 대시보드:
- 지표 끝점: 모든 구성 요소는 Prometheus의 포트 7300에 지표를 노출합니다.
- Grafana 대시보드: indexer-rs/docs/dashboard.json
Pierre | Chain-Insights.io: 이제 12월 3일까지 한 명의 발신자만 활성 상태인가요?
# collect-receipts-endpoint: " " DEPRECATED # collect-receipts-endpoint: " " DEPRECATED gateway-endpoint: " " gateway-endpoint: " "
- Ana: 제가 아는 한, 이것이 맞습니다. 따라서 에지 및 노드 발신자만 활성화되어 모든 사람이 사용합니다. GraphOps는 12월 말부터 1월 초까지 일부 인덱서가 게이트웨이에 추가되기를 희망합니다.
피에르: 이게 좋은가요, 아니면 수령-수령 엔드포인트 활성화로 되돌려야 하나요?
피에르: 이게 좋은가요, 아니면 수신 수령 엔드포인트 활성화로 되돌려야 하나요?
- Ana: 게이트웨이 엔드포인트를 사용하는 것이 좋습니다. 기본적으로 알아야 할 유일한 것은 사용할 CLI 플래그를 선택할 수 있다는 것입니다. 그러나 혼란스러운 오류인 동일한 오류가 표시되므로 여기서는 아무것도 할 필요가 없습니다.
Ana: 마이그레이션한 인덱서 중 일부가 발견한 내용에 대해 공유하고 싶은 의견이 있나요?
- Marc-André |Ellipfra: 대시보드를 설정하고 모니터링하는 것은 매우 중요합니다. 각 릴리스마다 더욱 안정적이 되고 있지만 알 수는 없습니다.
구스타보: 기능 요청이나 더 나은 구성 방법에 대한 아이디어가 있는 경우 언제든지 indexer-rs 저장소에 문제를 제기해 주세요.
우리는 시스템을 개선하고 기술을 더욱 안정적으로 만들고 더 나은 수준에 도달할 수 있도록 모든 문제와 기능 요청을 기꺼이 검토합니다. 시간을 내어 TAP에 대해 자세히 논의해 주셔서 감사합니다.
#blockchaindataindex#web3dataanalytics#TheGraph
모든 댓글