TL;DR: Graph'ın TAP geçişi için son tarih 3 Aralık 2024'tür ve dizin oluşturucuların yaklaşık %34'ü yükseltildi, bu da sorgu hacminin %81,6'sını oluşturuyor. Soru-Cevap tartışması, varsayılanlarla başlama ve sorgu hacmine göre ayarlama yapma önerisiyle birlikte, özellikle RAV (Makbuz Toplama Kuponu) istekleri ve birleştirilmemiş ücretlerin yönetimi ile ilgili olmak üzere TAP'ın yapılandırma ayarlarına odaklandı.
Herkese merhaba, Indexer Ofis Saatleri toplantı tutanakları, Oturum 184'e hoş geldiniz!
Video linki: https://youtu.be/w0LZkVJemPY
Persistence Labs COO'su Jeroen Develter ile GRTiQ podcast'ini izleyin. Jeroen'in web3 yolculuğu geleneksel finans ve danışmanlık dünyasında başladı ve kripto para birimi ve blockchain dünyasına sıçradı.
Önemli depolara ilişkin en son güncellemeler
- Geth'in yeni sürümü v1.4.12:
- Tarih: 2024-11-19 13:53:28 UTC
- Bu sürüm, kullanımdan kaldırılan kişisel RPC ad alanını ve –unlock komutunu kaldırarak anahtar yönetiminde önemli değişiklikler yapıldığını gösterir. Ayrıca optimizasyonlar, veritabanı iyileştirmeleri ve çeşitli hata düzeltmelerinin yanı sıra izleyici yapılandırmasında önemli değişiklikler de içerir.
- Acil durum göstergesi: sarı
- Acil Sebep: Anahtar yönetimi değişiklikleri kullanıcı ayarlaması gerektirir.
- Reth yeni sürüm v1.1.2
- Tarih: 11-2024 16:27:10 UTC
- Bu sürümde performans iyileştirmeleri, hata düzeltmeleri ve yeni hard fork için önemli hazırlıklar yer alıyor. Bu değişiklikler özellikle yük işi alımını optimize eder ve bekleyen işlem sıralamasını ele alır, bu da OP-reth kullanıcılarının güncel kalmasını kritik hale getirir.
- Acil durum göstergesi: kırmızı
- Acil sebep: OP-reth kullanıcıları için hard fork hazırlığı.
- sfeth/fireeth: yeni sürüm v2.8.0:
- Tarih: 14.11.2024 14:55:01 UTC
- CombinedFilter, işlem işleme sırasında istikrarı artırmak için sıfır güvenlik kontrollerini entegre eder. Ek olarak, alt akışlara ve ölçüme yönelik güncellemeler, ölçüm işlevselliğinde iyileştirmeler içerir.
- Acil durum göstergesi: sarı
- Acil sebep: Acil bir tehdit değil, istikrarı iyileştirin.
- Avalanche: Yeni sürüm v1.11.13:
- Tarih: 2024-11-18 22:24:03 UTC
- Bu sürüm, platforma yeni API'lerin yanı sıra RPCChainVM ölçüm başlatma ve uyumluluk iyileştirmelerine yönelik düzeltmeler sunar. Uyumluluğu ve kararlılığı artırmak için Operatörün en son eklenti sürümüne güncellenmesi önerilir.
- Acil durum göstergesi: sarı
- Acil Sebep: Önemli düzeltmeler ve yeni özellikler hemen ilgilenilmesini gerektirir.
- Dizin Oluşturucu Hizmeti ve Aracısı (TS): Yeni sürüm v0.21.8:
- Tarih: 2024-11-18 19:23:13 UTC
- Bu sürüm bazı küçük güncellemeler içerir, alt grafik yüksekliği çakışma mesajlarını önemsiz göstererek kullanıcı arayüzünü geliştirir ve indeks aracısındaki yoklama aralığı parametresini düzeltir. Sistem performansını veya güvenliğini etkileyen hiçbir kritik değişiklik bulunamadı.
- Acil durum göstergesi: yeşil
- Acil neden: Düşük etkili değişiklik, kritik sorun yok.
- Dizin Oluşturucu Hizmeti ve Tıklama Aracısı (RS): Yeni sürüm indexer-tap-agent-v1.7.3:
- Tarih: 13.11.2024 19:04:13 UTC
- Sürüm 1.7.3, işlem sürecini etkileyebilecek yönetilen bağdaştırıcı kontrollerini kaldırarak bir hatayı çözer. Sorunsuz işlevsellik sağlamak için tüm operatörlerin bu değişikliği incelemesi gerekir.
- Acil durum göstergesi: sarı
- Acil neden: Önemli düzeltme, kritik değil ancak mümkün olan en kısa sürede güncellenmesi önerilir.
Protokoldeki önemli değişikliklerle ilgili en son güncellemeler
- The Graph'ta gelişmiş tahkim: Çalışma grubunun başlatılması, tahkim komitesinin genişletilmesi ve süreç güncellemeleri
- Yeni Tahkim Çalışma Grubu, yeni bir analist göreve getirilene kadar geçici olarak Tahkim Analistinin görevlerini üstlenecek.
- Tahkim panelinin genişletilmesi, The Graph'ın tahkimde yüksek standartları koruma konusundaki kararlılığını güçlendiriyor.
- Tahkim süreci, iyileştirilecek alanların belirlenmesi amacıyla aktif olarak incelenmektedir.
- SSS ve referans materyalleri için forum gönderisine bakın.
- #GDR-19 anlaşmazlığına ilişkin bilgi talebi
- Bu anlaşmazlık GDR-18 ile ilgilidir çünkü aynı indeksleyici daha önce kesintiye yol açan davranışı tekrarlamıştır.
- Genel: Yerel olmayan zincirler için hardhat-secure-accounts kullanın #1070 (açık)
- Genel: Ateşleme sürümünü 0.15.7 #1069'a yükseltin (Açık)
- Düzeltme: Dağıtım komut dosyasına eksik parametreler eklendi ve SubgraphService çalıştırmalarının sayısı 50 kata düşürüldü #1062 (Açık)
Bugünün tartışması, GraphOps'tan Ana ve Semiotic Labs'tan Gustavo'nun katılımıyla TAP geçişiyle ilgili soru-cevap olacak. TAP, Grafiği sorgulamak için yeni bir mikro ödeme sistemidir.
🚨 Dizin oluşturucuların 3 Aralık 2024'ten önce TAP'a geçmesi gerekiyor.
Oturum, tartışmadan bazı arka plan bilgileri ile birlikte bu bölüme kopyalanan Ana'nın IOH TAP geçişi Soru-Cevap notları tarafından yönlendirildi. Yorumlar hafifçe düzenlendi
Ana |GraphOps: TAP'ın ne olduğuyla başlayalım?
TAP (Zaman Çizelgesi Toplama Protokolü) Genel Bakış:
- Eski Skaler ödeme sisteminin yerini alır.
- Verimli mikro ödemeler, azaltılmış zincir içi işlemler ve makbuzlar üzerinde indeksleyici kontrolü gibi temel özelliklere sahiptir.
- Dizin oluşturucunun birden fazla ağ geçidinden gelen sorguları kabul etmesine izin vererek merkezi olmayan ağ geçitlerini etkinleştirir.
Dizin oluşturucunun ne yapması gerekiyor?
- Indexer-agent'ı (sürüm 0.21.4 veya üzeri) çalıştırmak için dizin oluşturucu yığınını güncelleyin, Rust sürümünü çalıştırmak için indexer-service'i değiştirin ve yeni bileşen indexer-tap-agent'ı ekleyin.
- Dizin oluşturucu deposu (dizin oluşturucu-aracı)
- Indexer-rs kod tabanı (indexer-service ve indexer-tap-agent)
- kaynak:
- Kubernetes kullanıyorsanız launchpad-charts/graph-network-indexer'ı kullanın
- Docker Compose kullanıyorsanız StakeSquid yığınını kullanın
- TAP Geçiş Kılavuzu
Mickey |The Graph |E&N: Dizin oluşturucu son teslim tarihini kaçırırsa ne olur? Ağ geçidi, yükseltilinceye kadar yeni sorguları onlara yönlendirmez veya...?
- Gustavo | Göstergebilim Laboratuvarları: Ağ geçidi şu anda Skaler ve TAP için makbuzlar sağlıyor. Son tarihe ulaştığımızda ağ geçidi yalnızca TAP makbuzlarını destekleyecektir. Sürümünüz 1.0'dan düşükse artık sorgu almayacaksınız.
- Ana: Teşekkürler, bu mantıklı. Dolayısıyla sorgu almaya devam etmek istiyorsanız geçiş yapmanız gerekir.
Mickey |Grafik |E&N: Dizin oluşturucuların yüzde kaçının dizin oluşturucu-rs/tap'a taşındığını söylemenin bir yolu var mı?
- Ana: Bir indeksleyicinin TAP'a taşınıp taşınmadığını anlamanın bir yolu, GraphSeer'deki indeksleyici yapılandırma dosyasında TAP READY etiketli bir rozetin bulunmasıdır.
- Gustavo: Semiotic olarak bu sayıyı yakından takip ediyoruz, indeksleyicinin 1.0'dan daha yüksek bir sürüm çalıştırıp çalıştırmadığını kontrol ediyoruz. İzlediğimiz 88 dizin oluşturucudan 30'u, dizin oluşturucunun 1.0 veya üzeri sürümünü çalıştırıyor; bu da dizin oluşturucuların yaklaşık %34'ünü oluşturuyor.
- Ayrıca her sorgu için geçen ay sunulan sorgu sayısını da takip ediyoruz; dolayısıyla şu anda sorguların %81,6'sı TAP üzerinden çalışıyor.
- Ana: Sanırım, en yüksek sorgu hacmine sahip indeksleyicinin yükseltildiğini söylüyorsunuz.
- Gustavo: Evet. İlk 10 indeksleyiciden 9'u yükseltildi. Aslında ilk 14 indeksleyiciden 13'ü yükseltildi.
Mickey |The Graph |E&N: Benim izlenimim, pek çok indeksleyicinin yükseltme sorunları yaşadığı yönünde - bu izlenim doğru mu ve eğer öyleyse, herkesin daha önce Yükseltilmesi için 3 Aralık'taki son tarih gerçekçi mi? (gölgeleme yok, sadece bunun yeterince kararlı olup olmadığını merak ediyorum)
- Gustavo: Sanırım çoğu sorguyu [taşıma] yolunda ilerliyoruz. Dizin oluşturucuların %100'ünü 3 Aralık'taki son tarihten önce taşımak biraz zor ama %95'e kolayca ulaşabileceğimizi düşünüyorum. %100'e ulaşmaya çalışabilmemiz için sizi desteklemek için buradayız.
Mickey |Grafik |E&N: Neden 88 [dizin oluşturucu]? Bunlar yalnızca sorguya gerçekten hizmet edenler mi?
- Gustavo: Tüm aktif indeksleyicileri kontrol etmek için Hizmet Kalitesi (QoS) alt grafiğini kullanıyoruz, yani temel olarak geçen ay bir sorgu sunmuşlarsa 88 listesinde görünürler. Biz esas olarak sorgularla ilgileniyoruz ve sorguyu sunan indeksleyicinin en son sürümü kullanması bizi memnun ediyor.
paka |E&N: Ayrıca sorgu trafiğinin çoğunun TAP'a taşınacağından da eminim.
Mickey |Grafik |E&N: Tamam, anladım! İyi strateji.
Mickey |The Graph |E&N: Sorularını bildiren ancak henüz yükseltme yapmamış olan geciken kişilerle bireysel olarak iletişime geçecek misiniz?
- Gustavo: İletişim kurduğumuz dizin oluşturucularla iletişim kurma sürecindeyiz. Elimizde bir liste var ve en büyüğünden başlayarak her biriyle iletişime geçiyoruz. Şu anda henüz yükseltilmemiş en büyük iki tanesi Yükseltme Dizini Oluşturucu [Edge & Node] ve Pinax'tır. 1.0'ın ötesindeki sürümlere yükseltmeleri destekleyebilmeleri için Edge ve Node ile yakın işbirliği içinde çalışıyoruz. O indexer ile iletişim halinde olduğumuz sürece, en yüksek hacimli sorgulardan en az hacimli sorgulara doğru tek tek çalışacağız.
Ana: Dizin oluşturucular, taşınan herhangi bir dizin oluşturucuyu yardım için işaretleyebilir. Herhangi bir sorunuz varsa lütfen bizimle iletişime geçmekten çekinmeyin.
Gustavo | Semiotic Labs: Herhangi birinin sorusu varsa, bunları The Graph Discord'daki 📁︱indexers ve 📁︱indexers-yazılım kanallarında yanıtlayacağım.
- Toplanmamış ücretler ve RAV talepleri:
- Sorun: Dizin oluşturucular, özellikle rav_request_trigger_value çok düşük ayarlanmışsa, toplanmamış ücretlerinde bir artış görebilir.
- Açıklama: rav_request_trigger_value, indeksleyicinin gönderenden ne zaman Makbuz Toplama Kuponu (RAV) istediğini belirler (göndereni bir ağ geçidi olarak düşünebilirsiniz). Bu değer çok düşükse, tetikleyici yeterince sık karşılanamayabilir ve bu da ücretlerin toplanmadan birikmesine neden olabilir.
- Çözüm: max_amount_willing_to_lose_grt / tetikleyici_değer_divisor olarak hesaplanan rav_request_trigger_value'nuzu güncelleyin.
Ana: Buraya koyduğum bir gösterge paneli var; Toplanmamış panelde tetikleyici değerleri görebilirsiniz. Benim durumumda RAV tetikleme değeri 3'tür. Çalışma şekli, yeni bir fiş alındığında değerinin birleştirilmemiş giderlere eklenmesi ve toplam birleştirilmemiş giderlerin tetik değerini aşıp aşmadığının sistem tarafından sürekli kontrol edilmesi şeklindedir.
Tetikleme koşulu karşılandığında, alındının zaman içinde ne kadar geriye bir alındı olarak kabul edileceğini belirlemek için zaman damgası arabelleği kontrol edilerek bir RAV isteği oluşturulur ve RAV isteği alma sınırına göre alınma sayısını sınırlayacaktır.
Yapılandırmaya hızlı bir şekilde göz atarsak, burada önemli olan birkaç şey vardır:
- max_amount_willing_to_lose_GRT
- tetikleyici_değer_bölen
Bu ikisi tetikleme değerini belirler.
- timestamp_buffer_secs, yani makbuzun dikkate alındığı zaman
- max_receipts_per_request, böylece RAV 10000'e kadar makbuz içerebilir
Herhangi bir makbuz geçersizse, bunlar dizin oluşturucu meta veri veritabanındaki Scaler TAP makbuzları geçersiz tablosunda ayrı olarak depolanır. max_receipt_value_GRT bu değerden yüksek olduğunda fiş geçersiz olur.
Yapılandırma: maximal-config-example-toml
Gustavo: Burada neler olup bittiği ve neden bu kadar çok konfigürasyona sahip olduğumuz hakkında konuşmak istiyorum. Çoğu dizin oluşturucu için bu yapılandırmalar büyük sorgu hacimlerine sahip olmadıkları için sorun olmayacaktır.
Saniyede çok fazla ayırmanız veya çok fazla sorgunuz varsa, bu biraz zorlaşabilir, bu yüzden bunları güncellemeniz ve yapılandırmanız gerekir. Genel olarak önce varsayılanları deneyip görmenizi öneririm. Geçerli varsayılan değerler şunlardır:
- max_amount_willing_to_lose_GRT = 20
- tetikleyici_değer_bölen = 10
- Bu, özetlenmemiş faturalarınızın (özetlenmemiş masraflar olarak da bilinir) toplam tutarı 2 GRT'ye ulaştığında, bunları özetlemeye çalışacağımız anlamına gelir. Ancak değer her zaman 2'den büyükse bu değerleri değiştirmeniz gerekir.
- max_amount_willing_to_lose_GRT'yi mümkün olduğunca düşük tutmaya çalışın. Ancak RAV isteği başarısız olursa ve büyük bir indeksleyici olduğunuz için o sırada çok sayıda alındı bilgisi alırsanız, göndereni çok hızlı bir şekilde engellemiş olursunuz.
- timestamp_buffer_secs = 60
- request_timeout_secs = 5
- max_receipts_per_request = 10000
İlk 15-20 indeksleyicinin bu değerleri güncellemesi gerekiyor.
Pierre | Chain-Insights.io: İdeal değerlerim nelerdir? Varsayılan benim için hala iyi mi? RAV isteklerim yok gibi görünüyor.
İlk 15-20 indeksleyicinin bu değerleri güncellemesi gerekiyor.
Pierre | Chain-Insights.io: İdeal değerlerim nelerdir? Varsayılan benim için hala iyi mi? RAV isteklerim yok gibi görünüyor.
Gustavo: Bir kontrol edeyim... Tetikleyici değer Toplam Toplanmamış maliyet. Öncelikle birkaç güncelleme yapalım. Hangi sürümü kullanıyorsunuz?
Pierre: En son sürüm.
Gustavo: Normalde RAV tetikleyicisine ulaştığınızda, bir RAV isteği oluşturmaya çalışması gerekir. Eğer bu olmazsa araştırma yapmamız gerekir.
Pierre | Chain-Insights.io: Benim için değil:
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
Gustavo: Yani tetikleme değeriniz 10 civarında, değil mi?
Pierre şunu paylaştı: Evet, 20 / 2
Gustavo: Yani yalnızca belirli bir tahsis için 10 GRT'ye veya 10.000 makbuza ulaştığınızda bir RAV isteğini tetiklersiniz. Sorgu hacminiz nedeniyle yaklaşık 0,1 veya:
max_amount_willing_to_lose_grt: 1 trigger_value_divisor: 10 max_receipts_per_request: 1000
Pierre şunu paylaştı: Tamam, teşekkür ederim.
Gustavo: Saniyede bu kadar çok sorgunuz yoksa, daha fazla RAV isteğiniz olması veya daha büyük bir tetikleme değerine sahip olmanız gerekir.
Bu, kaç tahsisinizin açık olduğuna, saniye başına aldığınız sorgu sayısına, tahsis başına saniye başına sorgu sayısına ve sahip olduğunuz patlamalara bağlıdır.
TAP'ta, belirli bir zamanda toplamanın ardından, o zamandan önceki zaman damgalarını içeren makbuzlar çalışmayacaktır. Geçersiz sayılıyorlar, bu yüzden bu tampona sahibiz. Makbuzları yalnızca 60 saniye sonra kabul ediyoruz. Bunun nedeni, farklı bilgisayarlar arasında saatleri senkronize etmenin zor olmasıdır. Ağ geçidi size bir makbuz gönderir ve saatinizden 5 saniye önce veya sonra olabilen bir zaman damgası tanımlar.
Varsayılan değerleri, saniyede 1-2 sorgu ve her 15 dakikada bir 1 RAV isteği olmak üzere arada bir yerde olacak şekilde ayarladık. Ancak, belleğiniz bu miktardan daha azsa, daha düşük bir max_amount_willing_to_lose_grt değerine güncelleme yapmanız gerekebilir. Bu sayıyı aşarsanız daha fazlasına güncelleme yapmanız gerekebilir.
Gemma | LunaNova: Bu değerler tahsis başına mı yoksa tüm tahsisler genelinde mi?
calinah | GraphOps: ödev başına
Pierre | Chain-Insights.io: Aşağıdaki sürümlere güncelledikten sonra:
Gemma|LunaNova: Bu değerler tahsis başına mı yoksa tüm tahsisler genelinde mi?
calinah | GraphOps: ödev başına
Pierre | Chain-Insights.io: Aşağıdaki sürümlere güncelledikten sonra:
calinah |GraphOps: Harika, kabul oranınız arttı.
Gustavo: Evet, bu iyi. Yani kontrol paneli için yapmak istediğiniz şey, toplanmamış ücretin her zaman 0,1'de kalmasıdır, böylece her RAV talebinizde biraz azalır ve 15 dakika sonra başka bir RAV talebini tetiklemeye yetecek kadar makbuzunuz olur.
Josh Kauffman |StreamingFast.io: Herkes bu değerler için belirlediği değerleri paylaşabilir mi?
Marc-André |Ellipfra: Referans olması açısından kampanyamda bu değerleri kullandım. Bunları özellikle önermiyorum çünkü az çok rastgele ayarlanıyorlar. max_willing_to_lose ağ geçidinin çok sık reddedilmesini önlemek için çok yüksek, bir noktada onu düşürmeyi planlıyorum:
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
- Gönderenin reddedilmesi sorunu:
- Gönderen, tap.sender_aggregator_endpoints'te listelenmiyor.
- Gönderenin emanet bakiyesi ödenmemiş masrafları karşılamaya yetmiyor.
- Toplanmamış ücretler max_fee_per_sender sınırını aşıyor.
- Sorun: Dizin oluşturucuda gönderen reddi yaşanabilir ve bu da sorgu işlemede ve gelirde kesintiye neden olabilir.
- Reddetme nedeni: Gönderenlerin reddedilmesinin üç ana nedeni vardır:
- Çözüm: Her ret nedenine özel çözüm:
- Tap.sender_aggregator_endpoints bölümünde gönderenin doğru şekilde yapılandırıldığını doğrulayın.
- Emanet fonlarıyla ilgili olası sorunları araştırın ve yeterli bakiyeyi sağlayın.
- Toplanmamış masraflar sık sık sınıra ulaşıyorsa max_amount_willing_to_lose_grt ayarını gözden geçirin ve gerekiyorsa düzenleyin.
- NOT: Dizin oluşturucu TAP aracısı her zaman aşağıdaki adla başlayacaktır:
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 at tap-agent/src/agent/sender_accounts_manager.rs:311 in ractor::actor::Actor with id: "0.0"
tap.sender_aggregator_endpoints'te olmayan veya env vars aracılığıyla INDEXER_TAP__SENDER_AGGREGATOR_ENDPOINTS__ için
- Dizin oluşturucu aracısında toplama-makbuz uç noktası hatası:
- indeksleyici aracısı toplama-makbuz uç noktası:
{"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."}
Gustavo: Bir göndereni reddetmenizin nedeni, gönderenin size ödeme yapmamış olması, dolayısıyla yeterli emanete sahip olmaması veya sizden kaybetmeye hazır olduğunuz bir tutarı istemesidir. Olabilecek başka bir şey de bunun için geçersiz makbuz kullanmamızdır; bu nedenle, sahip olduğunuz geçersiz makbuzların sayısı, kaybetmek istediğiniz maksimum sayı ise, göndereni bunun için engellersiniz.
max_receipt_value_grt ile ilgili hızlı bir güncelleme, bunun yalnızca bu hizmet için geçerli olmasıdır. TAP'ın minimum düzeyde güvenilir olması için bunların mikro ödemeler olması gerekir; dolayısıyla ağ geçidi size bir makbuz gönderdiğinde, bu, geçersiz bir makbuz olarak değerlendirilmeden kabul edecekleri maksimum makbuz değeridir.
Geçersiz bir makbuz, aldığınız, bir sorgu yaptığınız ve ardından makbuzun geçersiz olduğunu keşfettiğiniz makbuzdur.
Ana: Geçersiz makbuzlarda, koşullar değişirse geçerli olacak mı, yoksa makbuz geçersiz olarak işaretlendikten sonra yeniden deneme yapılmayacak mı?
Gustavo: Tekrar deneme yok. Bu tablo yalnızca günlük kaydı için kullanılır, böylece veritabanına erişebilir ve ne olduğunu ve makbuzun neden başarısız olduğunu görebilirsiniz.
Ana: Bu mantıklı. Ayrıca TAP kontrol panelinde gönderenin engellenip engellenmediğini görebilirsiniz.
- RAV istek hatası:
- Sorun: RAV istekleri sırasındaki hatalar toplama işlemini kesintiye uğratabilir.
- Hata örneği: RAV isteğinin geçerli bir makbuzu yok gibi görünüyor... rav_request_trigger_value değerini artırarak bunu düzeltebilirsiniz.
- Açıklama: Bu hata, yetersiz rav_request_trigger_value değerinin, alındının RAV isteğine dahil edilmesini engellediğini gösterir.
- Çözüm: Çözüm, hata mesajında verilmiştir – rav_request_trigger_value değerini artırın.
- Yazılım sürümü: Dizin oluşturucu aracısı, dizin oluşturucu hizmeti ve tap aracısı için gerekli yazılım sürümünü kullanın.
- Yapılandırma dosyası izlenecek yol:
- Paylaşılan konfigürasyon: indexer-service ve tap-agent ortak bir TOML konfigürasyon dosyasını paylaşır.
- Blockchain adresi ve uç nokta:
- Önemli: Doğru sözleşme adresini, ağ geçidi uç noktasını ve zincir kimliğini kullanın.
- Günlük düzeyinde yapılandırma: RUST_LOG ortam değişkenini uygun günlük kaydına ayarlamak için RUST_LOG=indexer_tap_agent=debug,info kullanın.
- Metrikler ve Grafana kontrol panelleri:
- Metrik uç noktası: Tüm bileşenler, Prometheus'un 7300 numaralı bağlantı noktasındaki metrikleri açığa çıkarır.
- Grafana kontrol paneli: indexer-rs/docs/dashboard.json
Pierre | Chain-Insights.io: Şimdi, 3 Aralık'a kadar yalnızca bir gönderici aktif mi?
# collect-receipts-endpoint: " " DEPRECATED # collect-receipts-endpoint: " " DEPRECATED gateway-endpoint: " " gateway-endpoint: " "
- Ana: Bildiğim kadarıyla bu doğru, yani yalnızca kenar ve düğüm göndericileri aktif ve herkes tarafından kullanılıyor. GraphOps, Aralık ayının sonundan Ocak ayının başına kadar ağ geçidimize bazı indeksleyicilerin eklenmesini umuyor.
Pierre: Bu iyi mi yoksa tahsilat uç noktasını etkinleştirmeye geri dönmeli miyim?
Pierre: Bu iyi mi yoksa tahsilat uç noktasını etkinleştirmeye geri dönmeli miyim?
- Ana: Ağ geçidi uç noktasını kullanmak harika. Temel olarak bilmeniz gereken tek şey, hangi CLI bayrağını kullanacağınızı seçebilmenizdir, ancak ne olursa olsun aynı hatayı göreceksiniz ki bu kafa karıştırıcı bir hatadır, dolayısıyla burada hiçbir şey yapmanıza gerek yoktur.
Ana: Geçiş yapan indeksleyicilerden bazılarının, buldukları şeyler hakkında paylaşmak istedikleri yorumları var mı?
- Marc-André |Ellipfra: Gösterge tablolarını ayarlamak ve izlemek çok önemlidir. Her sürümde daha kararlı hale geliyor, ancak asla bilemezsiniz.
Gustavo: Eğer herhangi bir özellik isteğiniz veya nasıl daha iyi yapılandırılacağına dair fikirleriniz varsa, lütfen indeksleyici-rs deposunda bu sorunu dile getirmekten çekinmeyin.
Sistemi daha iyi, teknolojiyi daha istikrarlı hale getirebilmek ve daha iyi bir seviyeye ulaşabilmek için her sorunu ve özellik talebini incelemekten mutluluk duyuyoruz. TAP'ı ayrıntılı olarak tartışmak üzere zaman ayırdığınız için teşekkür ederiz.
#blockchaindataindex#web3dataanalytics#TheGraph
Tüm Yorumlar