İnternet kesilince sensör verileri kaybolmak zorunda mı?

Bağlantı kaybı ile ölçüm kaybını neden ayırmalıyız?

Uzak bir pompa istasyonu iki saat boyunca merkeze ulaşamadığında iki farklı durum mümkündür: cihaz ölçmeye devam etmiş fakat kayıtlar gönderilememiştir ya da ölçümler hiç saklanmamıştır. Merkezde her ikisi de boş grafik gibi görünebilir. Mimari bu farkı görünür kılmıyorsa operatörün elindeki pano, sistemin gerçekte ne bildiğini açıklamaz. Çözüm bağlantının her zaman açık kalacağını varsaymak değil, ölçümün yaşam döngüsünü bağlantı durumundan bağımsız tasarlamaktır.

Önce garanti sınırını yazın: hangi kayıt, hangi andan sonra korunmuş sayılacak? Sensör sürücüsünün belleğe yazması, yerel depolamanın işlemi tamamlaması ve merkezî veritabanının kaydı kabul etmesi ayrı olaylardır. Bu yazıdaki sayılar varsayımsal bir boyutlandırma örneğidir; Kugrul'un ölçülmüş kapasitesi veya mevcut kuyruk uygulaması değildir. Kabul hedefi, cihazın kalıcı olarak kabul ettiği kayıtların kesinti ve tekrar gönderim sonrasında hesap verilebilir olmasıdır. Sensörün kendisinde oluşan ve hiç okunamayan veri ayrıca değerlendirilir.

Bir ölçümün kimliği ve zamanı nasıl tasarlanır?

Yalnızca zaman damgasını anahtar yapmak kırılgandır. Saat geriye alınabilir, iki örnek aynı zaman çözünürlüğüne düşebilir veya cihaz yeniden başlayabilir. Örnek bir anahtar; cihaz kimliği, yeniden başlatma dönemini ayıran kalıcı ve benzersiz dönem kimliği, dönem içinde artan sıra numarasından oluşabilir. Dönem kimliğinin her açılışta gerçekten değişmesi ve aynı cihaz kimliğinin farklı fiziksel cihazlara yanlışlıkla verilmemesi gerekir. Yeniden denemede aynı olay aynı anahtarı taşımalıdır.

Olay zamanı ile merkezin kabul zamanını ayrı saklayın. İki saat önce ölçülen bir basıncın şimdi ulaşması, basıncın şimdi değiştiği anlamına gelmez. OpenTelemetry günlük veri modeli de olay ve gözlem zamanlarını ayrı alanlar olarak ele alır; bu ayrım telemetri tasarımı için yararlı bir başvuru noktasıdır. Saat eşitleme durumu ve zaman belirsizliği de kayda eklenebilir. UTC saklamak saat dilimi sunumunu kolaylaştırır; tek başına bozuk cihaz saatini düzeltmez. Grafik ve alarm kuralları hangi zamanı kullandığını belirtmelidir.

Bölüm kaynakları: OpenTelemetry — Logs Data Model ↗

RAM tamponu neden yeterli değildir?

RAM kuyruğu ağ kesintisini karşılayabilir, fakat aynı anda güç kesilirse içeriğini kaybeder. Kalıcı kuyrukta ‘yazıldı’ cevabının anlamı işletim sistemi ve depolama davranışıyla birlikte tanımlanır. Bir dosyaya ekleme çağrısının dönmesi, verinin güç kaybından sonra kesinlikle kalacağı anlamına gelmeyebilir. SQLite WAL belgeleri, işlem onayı ve eşitleme ayarlarının dayanıklılık üzerindeki etkisini açıklayan somut bir örnektir. WAL kullanmak tek başına her donanımda kayıpsızlık garantisi oluşturmaz; dosya sistemi ve depolama katmanı da doğrulanmalıdır.

Her örneği ayrı eşitlemek ile kayıtları küçük gruplar hâlinde kalıcılaştırmak arasında gecikme, yazma yükü ve kayıp penceresi açısından tercih vardır. Gruplama aralığı bir saniyeyse bu aralıkta yalnızca bellekte tutulan örnekler kalıcı kabul edilmiş gibi raporlanmamalıdır. Kuyruk dosyalarının sürümü, kısmi son kayıt, bozuk segment ve yeniden açılış taraması için davranış tanımlayın. Disk dolduğunda en eski veriyi sessizce silmek yerine durumu raporlamak veya önceden onaylanmış azaltma politikasını uygulamak gerekir.

Bölüm kaynakları: SQLite — Write-Ahead Logging ↗

48 saatlik kesinti için ne kadar depolama gerekir?

Örnek sistemde 20 ölçüm kaynağının her biri saniyede bir kayıt üretsin. Sıkıştırılmamış, kodlanmış uygulama kaydının ortalama 160 bayt olduğunu varsayalım. Ham kuyruk hesabı B = kaynak sayısı × saniyedeki kayıt × kayıt boyutu × kesinti süresidir. Burada 20 × 1 × 160 × 172.800 = 552.960.000 bayt, yani 552,96 MB elde edilir. MB ondalık, MiB ikilik birimdir; bu tutar yaklaşık 527,34 MiB'dir. Gerçek boyut örnek dosyadan ölçülmelidir.

Yerel indeksler, segment başlıkları ve işletme payı için örnek olarak 1,8 katsayısı ayırırsak toplam 995.328.000 bayt olur. Bu katsayı evrensel bir gerçek değildir; gerçek dosya büyümesiyle doğrulanacak tasarım varsayımıdır. 2 GiB kullanılabilir kuyruk alanı seçmek bu örnekte pay bırakır, ancak işletim sistemi ve diğer uygulamalar için ayrılan alanı içermez. Kayıt sayısı ve ortalama boyutun artacağı durumları duyarlılık hesabına ekleyin. Sıkıştırma kazancını test etmeden kapasite garantisinin temeline koymayın.

MQTT QoS 2 bütün uygulamada tam bir kez işleme sağlar mı?

MQTT teslim seviyeleri, protokolde tanımlanan mesaj alışverişinin davranışıdır. Merkezî tüketicinin aldığı mesajı veritabanına yazıp yazmadığı veya yazdıktan sonra cevabını kaybedip kaybetmediği ayrı bir işlem sınırıdır. Bu nedenle MQTT QoS 2 seçildi diye bütün ölçüm hattında tam bir kez işleme iddiası kurulamaz. OASIS standardı, QoS davranışının tanımlandığı birincil kaynaktır. Uygulamada kaydın kalıcı kabulünden sonra aynı olay kimliğine bağlı bir kabul cevabı tasarlanmalıdır.

Aşağıdaki SQLite örneği tekil anahtarın tekrar gönderimi nasıl etkisizleştirdiğini gösterir. Aynı olay iki kez gelir, fakat satır sayısı bir kalır. Bu yalnızca örnekteki veritabanı eklemesi için geçerlidir; başka bir sisteme alarm gönderme gibi yan etkiler ayrıca tasarlanmalıdır. Aynı anahtar farklı bir değerle gelirse sessizce geçmek veri çatışmasını gizleyebilir. Üretim tasarımında mevcut kaydın özeti karşılaştırılır, farklı yük çatışma olarak kaydedilir ve cihazın hangi kabul cevabını beklediği açıklaştırılır.

CREATE TABLE readings (
  device_id TEXT NOT NULL,
  epoch TEXT NOT NULL,
  seq INTEGER NOT NULL CHECK (seq >= 0),
  event_time TEXT NOT NULL,
  received_time TEXT NOT NULL,
  value REAL NOT NULL,
  PRIMARY KEY (device_id, epoch, seq)
);
BEGIN IMMEDIATE;
INSERT INTO readings VALUES
 ('pump-07', 'boot-a', 81, '2026-10-19T10:00:00Z',
  '2026-10-19T12:00:00Z', 4.2)
ON CONFLICT (device_id, epoch, seq) DO NOTHING;
INSERT INTO readings VALUES
 ('pump-07', 'boot-a', 81, '2026-10-19T10:00:00Z',
  '2026-10-19T12:00:02Z', 4.2)
ON CONFLICT (device_id, epoch, seq) DO NOTHING;
COMMIT;
SELECT COUNT(*) AS stored_readings FROM readings;
-- Expected: 1. Same event delivered twice, stored once.

Bölüm kaynakları: OASIS — MQTT 5.0 ↗

Bağlantı gelince kuyruk ne kadar sürede boşalır?

Ağ yeniden geldiğinde eski kayıtların yanında yeni kayıtlar da üretilir. Etkin uygulama aktarım kapasitesini 64.000 bayt/s varsayarsak, 3.200 bayt/s canlı trafik çıkarıldıktan sonra geçmişi aktarmaya 60.800 bayt/s kalır. Ham 552.960.000 bayt için en iyi sabit hız yaklaşımı 9.094,74 saniye, yaklaşık 2,53 saattir. Bu hesap bağlantının kesintisiz ve kapasitenin sabit olduğu varsayımına dayanır; TLS, paket başlıkları ve tekrar iletimler zaten etkin kapasite ölçümüne yansıtılmalıdır.

Etkin kapasite canlı üretim hızından düşükse kuyruk hiç boşalmaz; yalnızca daha yavaş büyür. Canlı görünürlük ile tarihsel bütünlük için ayrı öncelikler tanımlanabilir. Örneğin canlı örnekler gecikmeden sunulurken geçmiş segmentler hız sınırıyla aktarılır; kullanıcı da eksik aralığın sonradan doldurulduğunu görür. Alarm motoru geçmişteki bir eşiği yeni oluşmuş olay gibi bildirmemelidir. Yeniden bağlanma fırtınasında bütün cihazların aynı anda yüklenmesini önlemek için dağıtılmış bekleme ve merkezde kota tasarlanır.

Ne zaman kayıt silinir, ne zaman alarm üretilir?

Gönderim çağrısının başarılı olması silme için tek başına yeterli olmayabilir. Örnek tasarımda yerel kayıt, merkezde kalıcı kabul ve olay kimliği eşleşen cevap alındıktan sonra temizlenir. Toplu cevap kullanılıyorsa ‘şu sıraya kadar kabul edildi’ ifadesinin aralıksız kabulü mü yoksa görülen en büyük sırayı mı anlattığı açıklanmalıdır. Arada boşluk varken en büyük sıraya kadar silmek kayıp yaratır. Segment temizleme işlemi, aynı anda çalışan gönderici ve yeniden başlatma süreciyle tutarlı olmalıdır.

Kuyruktaki kayıt sayısı, en eski kaydın yaşı, kullanılabilir alan, son kalıcı kabul zamanı ve yeniden gönderim oranı birlikte izlenmelidir. Bağlantı var görünürken kabul sayacı ilerlemiyorsa sorun taşıma katmanının dışında olabilir. Bozuk segment bulunduğunda onu karantinaya almak, hatayı raporlamak ve sağlam segmentleri işlemeye devam etmek bir seçenek olabilir; sessiz atlama kabul edilen veri kaybını gizler. Ölçüm kaybı, veri gecikmesi ve bağlantı kaybı kullanıcıya ayrı durumlar olarak sunulmalıdır.

Kayıpsızlık iddiası hangi testlerden geçmeli?

Kontrollü bir deneyde giriş kayıtlarının kimliklerini bağımsız olarak üretin ve sayın. Ağ kesintisi, süreç çökmesi ve güç kaybını farklı noktalarda uygulayın; özellikle yerel yazım öncesi, işlem onayı sonrası ve merkezî kabul cevabı öncesi durumları ayırın. Yeniden açılışta beklenen kimlik kümesi ile merkezde saklanan kümeyi karşılaştırın. Yalnızca satır sayısına bakmak yeterli değildir: bir eksik ve bir çift kayıt birbirini sayısal olarak gizleyebilir. Yük özeti ve beklenen sıralar da karşılaştırılmalıdır.

Deneyin sonucu yalnızca ‘geçti’ olmamalıdır. Kaybolan kabul edilmiş kayıtlar, çatışan tekrarlar, kuyruk toparlanma süresi ve zaman bilgisi belirsiz kayıtlar ayrı raporlanmalıdır. Depolama doluluğu ile tekrarlanan yeniden başlatmaların birleştiği senaryolar ayrıca denenir. Aşağıdaki kabul listesi, sahada verilmiş bir ürün garantisini değil, geliştirme ve pilot görüşmesinde kullanılabilecek bir kontrol çerçevesini gösterir. Hedefler; gerçek cihaz, işletim sistemi, bağlantı ve veri hacmi üzerinde kanıtlandıktan sonra taahhüt hâline getirilebilir.

• Kabul edilmiş olay kimliklerinin tamamı merkezde bulunuyor; yük özetleri eşleşiyor.
• Aynı olayın yeniden gönderimi veri satırını çoğaltmıyor; farklı yük çatışma üretiyor.
• Kuyruk doluluğu, güç kesintisi ve geçmiş veri aktarımı ayrı gözlemleniyor.

Bu mimari Kugrul ile nasıl ilişkilendirilir?

Kugrul'un kamuya açık konumu, uzaktan veri toplama ve donanım-yazılım entegrasyonudur; erişimi pilot kapsamındadır. Buradaki kuyruk, MQTT ve kabul modeli bir tasarım incelemesidir; üründe bu algoritmaların aynen bulunduğu veya verilen sayısal kapasiteyi sağladığı söylenmez. İlk teknik görüşmeye kaynak sayısı, örnekleme ihtiyacı, beklenen en uzun kesinti, güç koşulları ve saklama hedefiyle gelmek gerekir. Böylece hazır işlev, cihaz uyarlaması ve yeni geliştirme ihtiyacı birbirinden ayrılabilir.

Uzaktan telemetri yetenekleri fiziksel veri yolunu, veri ve gözlemlenebilirlik çalışmaları ise merkezde kabul, gecikme ve eksik kapsamın izlenmesini değerlendirmek için ilgili alanlardır. Doğru soru ‘internetsiz çalışıyor mu?’ ile bitmez. ‘Hangi kayıt hangi hata sonrasında korunuyor, ne zaman kabul edilmiş sayılıyor ve bunu hangi deneyle gösterebiliyoruz?’ soruları teslim kapsamını somutlaştırır. Önerilen bir pilotta ölçüm üreticisi, cihaz, depolama ve merkez birlikte ele alınmalı; sorumluluğu belirlenmemiş hiçbir aktarım sınırı görünmez bırakılmamalıdır.