Maskeleme ve saklama

Maskeleme depolamadan önce çalışır

Prompt'lar ve tamamlamalar mcpd'nin tuttuğu en değerli ve en tehlikeli şeydir. Maskeleme, alım hattının üçüncü aşamasıdır ve yazmadan öncedir, yani bir kuralın eşleştiği değer veritabanına hiç ulaşmaz.

Sıralama işin özüdür. Sonradan temizlenen bir değer yine de diskte, önden yazma günlüğünde ve büyük olasılıkla dün geceki yedekte bulunmuştur. Hiç yazılmamış olmak, sonradan silinmiş olmaktan başka bir güvencedir ve soran birine açıkça söyleyebileceğiniz tek güvence odur.

Maskeleme varsayılan olarak açıktır. Sizi ancak yapılandırdıktan sonra koruyan bir araç kimseyi korumaz. --no-redact veya MCPD_NO_REDACT onu kapatır; bu yalnızca yukarı akışta bir şey zaten maskeliyorsa akla yatkındır.

Maskeleme, telin daemon tarafındaki ucudur. Diğer ucu SDK'lar tutar: MCPD_CAPTURE_PAYLOADS=false veya kodda capture_payloads, prompt'ları ve tamamlamaları sürecin içinde tutar. Span yine süresi, durumu, kullanımı, modeli, ilişkilendirmesi ve hatalarıyla gelir; input ve output ise kuyruğa alınmadan önce düşürülür, yani ağı hiç geçmezler. Baytları hiç göndermemesi gereken bir ekip bunu ayarlar, hassas bir şey taşımayan bir span da kendisi için yeniden dahil olabilir.

Varsayılan kurallar

Bir kural, küçük harfli alt dizelerden ve bir moddan oluşur. Bir anahtar, adı küçük harfe çevrildiğinde bunlardan herhangi birini içeriyorsa eşleşir. X-API-Key, authorization ve customer_email adlarının, her yazım biçimi ve önek sıralanmadan yakalanmasının nedeni, eşleşmenin alt dize üzerinden olmasıdır.

Eşleşen bir anahtar bir nesne veya dizi tutuyorsa, altındaki her şey de maskelenir. {"credential": {"value": "hunter2", "note": "prod"}} yalnızca adı tehlikeli görünen alanı değil, iki alanı da kaybeder.

Sınırı açıkça söylemekte fayda var: kurallar değerlerle değil, anahtar adlarıyla eşleşir. Bir kullanıcının bir prompt'un ortasına yapıştırdığı ve content adlı bir anahtarın altında saklanan bir API anahtarı burada hiçbir şeyle eşleşmez. Maskeleme, kimlik bilgilerinin ve tanımlayıcıların yapılandırılmış biçimde toplanmasını durdurur. Bir içerik tarayıcısı değildir ve onu öyle saymak sizi yanıltır.

Dört mod

Yerleşik kurallar dördün üçünü kullanır. Varsayılan olarak hiçbir şey düşürülmez: drop, sizin ekleyeceğiniz ve bir alanın varlığının bile tutmak istediğinizden fazla olduğu bir kural için oradadır.

$ curl -s "$MCPD/v1/api/traces/$TRACE" | jq .spans[0].input{  "question": "Where is my order A-1042?",  "api_key": "[redacted]",  "email": "al…om",  "user_id": "sha256:9f2c1b7d4a08e5c3f6b1d0a4"}

Özet neden anahtarlı

Özetleme bir alanı kullanışlı tutar. Tek bir anahtar altında eşit girdiler eşit özetler verir, yani maskelenmiş bir kullanıcı kimliğine göre gruplayabilir, bir hataya kaç farklı kişinin denk geldiğini sayabilir ve birini bir oturum boyunca izleyebilirsiniz; kim olduklarını tutmadan.

Anahtarsızken bu özellik bir açıktır. Tanımlayıcılar küçük ve tahmin edilebilir kümelerden gelir; özete ve bu kaynak koda sahip olan biri, biri tutana kadar adayları özetleyebilir. Özeti yalnızca zahmetli değil, geri çözülemez yapan şey anahtardır.

Yerleşik anahtar kaynak koddaki bir sabittir, yani herkese açıktır. Bir şeyi özetleyen her dağıtımda kendi anahtarınızı ayarlayın.

Anahtarı döndürmek bağı bilerek koparır. Her özet değişir, yani döndürmeden önce yazılmış satırlar sonra yazılanlarla artık birleştirilemez. Döndürmenin amacı budur ve bedeli de budur. Takvime bakıp alışkanlıktan değil, bağın kopmasını istediğinizde döndürün.

Döndürmeden önce bu bedelin ikinci yarısını okuyun. Özneye göre silme, saklanan özetle eşleşir; yani eski anahtarla yazılmış her satır, yeni anahtar yürürlüğe girdiği andan itibaren bir silme talebinin erişemeyeceği yerdedir. mcpd size olanın bu olduğunu söyleyemez, çünkü hangi anahtarın hangi satırı yazdığını hiçbir yer kaydetmez. Yapabildiği tek şey, ortaya çıkan sıfırın bir yanıt yerine geçmesine izin vermemektir ve aşağıdaki sıfır bölümü bu reddin kendisidir.

Yalnızca span'ler değil, her sinyal

Bir sır, bir prompt'tan geçtiği kadar kolay bir log satırından da sızar; bu yüzden aynı maskeleyici, girişte altı sinyalin hepsinin üzerinden geçer:

• Span'ler: input, output, attributes ve metadata.
• Loglar: yapılandırılmış fields.
• Metrikler: labels.
• Puanlar: metadata.
• Geri bildirim: metadata ve serbest metin comment.
• Yön notları: cümlenin kendisi, text alanında.

Bir span'in adı ve bir log kaydının mesajı maskeleyiciden geçirilmez. Bunlar payload değil tanımlayıcıdır ve yeniden yazmak gruplamayı bozardı. Bir span adını bir müşterinin e-posta adresinden kurmayın.

Çalıştırma deposu maskelenmez

Kalıcı çalıştırmalar istisnadır ve bu bilerek böyledir. Çalıştırma deposu bir çalıştırmanın girdisini, durum verisini, çıktısını ve ilişkilendirmesini, her adımın girdisini, çıktısını ve hatasını gönderildikleri gibi, user_id özetlenmeden tutar. Bunlar iş akışının çalışma durumudur: sonraki bir adım onları geri okur ve maskeleyicinin yeniden yazdığı bir değer çalıştırmanın yaptığı şeyi değiştirirdi. Bir çalıştırmanın trace deposuna yazdığı span'ler olağan alım yolundan geçer, bu yüzden trace deposu onları diğer her span gibi maskelenmiş ve özetlenmiş olarak tutar. Aşağıdaki bölümlerin anlattığı gibi saklama ve silme çalıştırma deposunu da kapsar ve bir çalıştırmanın API üzerinden her okunuşu denetim günlüğüne kaydedilir.

Uzun dizeler ve derin belgeler

Bir kural eşleşse de eşleşmese de her şeye iki sınır uygulanır.

128 KiB'den uzun her tek dize kesilir ve sonuna … [N bytes truncated] eklenir, böylece okuyan kişi değerin kısa değil eksik olduğunu bilir. Kesme bir karakter sınırına denk gelir, hiçbir zaman çok baytlı bir kod noktasının içine değil. Kaçak tek bir prompt veritabanınızın boyutunu belirlememelidir.

Gezinme 32 derinliğinde durur ve altında kalan her şey [too deeply nested] ile değiştirilir. Açık bir alım portuna ulaşan patolojik veya kendine gönderme yapan bir belge bir CPU'yu meşgul edemez.

Saklama

--retention-days veya MCPD_RETENTION_DAYS, verdiğiniz gün sayısından eski sinyalleri siler. Vermezseniz hiçbir şey silinmez. Varsayılan olarak veriyi tutmak doğru yöndür: geçen ayın trace'lerini sessizce atan bir aracı en kötü anda fark edersiniz.

Tarama, sorgu anında değil, daemon içinde saatlik bir zamanlayıcıyla çalışır. Bir saklama taraması çok sayıda satır silebilir ve bu iş asla birinin isteğinin içine düşmemelidir. Her tarama tek bir işlemde, received_at değeri kesim noktasından eski olan span'leri, logları, metrikleri ve trace satırlarını, kendi zaman damgası eski olan puanları, geri bildirimleri ve yön notlarını kaldırır, sonra kaç satırın gittiğini loglar. Tam metin dizini girdileri, onları adlandıran satırlar hâlâ dururken önce temizlenir, böylece hiçbir şey öksüz kalmaz.

Aynı tarama, aynı pencereyle, çalıştırma deposunu da budar. Kökü kesim noktasından önce sona ermiş her kalıcı çalıştırmayı, alt çalıştırmalarıyla ve onlar için saklanan her şeyle birlikte siler; bunu, çalışırken worker'ları bekletmemek için parti parti yapar. Sona ermemiş bir çalıştırma, ne kadar uzun süredir bekliyor olursa olsun hiçbir zaman silinmez. Tanımlar budanmaz.

Tarama, yalnızca varsayılanı değil, --project ile adlandırılan projeyi ve yapılandırma dosyasının projects bloğundaki her projeyi kapsar. Orada kendi retention_days değerini ayarlayan bir proje o değere göre, geri kalanlar daemon'unkine göre süpürülür. İkisinde de olmayan, yalnızca bir gönderenin adlandırdığı bir projenin penceresi yoktur ve hiç budanmaz. Bu, tek bir daemon birkaç ekibe hizmet ettiğinde önemlidir: otuz gün tutmayı kabul etmiş bir ekip, taramanın okuduğu tek ayar başka bir ekibinki olduğu için verisini sessizce tutmaya devam etmez, hiçbir yere yazılmamış bir ekip ise her şeyi tutar.

Bir kişiyle ilgili silme talebi

DELETE /v1/api/subjects/{user_id}, bir kişiyle ilgili bir talebi tek çağrıda yanıtlar. Tanımlayıcıyı, ölçümlemenizin ayarladığı biçimde gönderin. Daemon, alımda uyguladığı özetlemenin aynısını uygular, yani user_id alanını özetleyen bir dağıtımda sizin önceden özetlemeniz gerekmez.

Silmenin birimi satır değil, çalıştırmadır. Genelde yalnızca kök span bir user_id taşır, prompt'u ve yanıtı tutanlar ise alt span'lerdir; yani özneyi adlandıran satırları silmek payload'ı yerinde bırakırdı. Bir çalıştırma, trace izdüşümü özneyi adlandırdığında veya span'lerinden herhangi biri adlandırdığında kapsama girer ve o zaman çalıştırmanın tamamı gider:

• O çalıştırmanın her span'i, taşıdığı girdiler ve çıktılarla birlikte.
• Ona bağlı loglar, metrikler, puanlar, geri bildirimler ve yön notları.
• Bir span_id adlandıran ve trace_id adlandırmayan sinyaller. Öznenin çalıştırmasının tek bir adımına iliştirilmiş bir puana veya log satırına, yalnızca trace kimlikleri üzerinden değil, kapsamdaki çalıştırmaların span kimlikleri üzerinden de erişilir.
• Bağlanacağı bir çalıştırma olmadan kişiye karşı kaydedilmiş log satırları, kendi user_id alanlarıyla eşleştirilir.
• Kişinin yazdığı geri bildirim, nereye bağlı olursa olsun author_id ile eşleştirilir. O satır kişinin kendi metnini tutar ve başkasının çalıştırmasına bağlı olabilir; eskiden hayatta kaldığı yer burasıydı.
• Kapsamdaki bir çalıştırmadan alınmış veri kümesi öğeleri. Bunlar silinmez, boşaltılır. Bundan sonraki ikinci bölüm nedenini anlatır.
• Kalıcı çalıştırmaları sunan bir daemon'da, ilişkilendirmesi user_id değerini taşıyan ve sona ermiş her çalıştırma, alt çalıştırmalarının tüm ağacıyla ve çalıştırma deposunun onlar için tuttuğu her şeyle birlikte. Eşleşme, çalıştırmayı başlatırken verdiğiniz biçimle yapılır, çünkü çalıştırma deposu onu özetlemeden tutar. O kişinin sona ermemiş bir çalıştırmasına dokunulmaz: onu silmek, parçası olduğu iş akışını bozardı. runs_in_flight içinde sayılır ve note içinde adlandırılır, böylece onu iptal edebilir ya da bitmesine izin verebilir ve isteği yeniden gönderebilirsiniz.

Önce çalıştırma deposu silinir. Bir çalıştırmanın span'leri trace deposuna yazılana kadar onun giden kutusunda bekler; bu yüzden önce çalıştırmaları silmek hâlâ bekleyen her span'i siler, ardından trace deposundaki silme zaten yazılmış olanları kaldırır.

Yanıt ne taşır

Sinyal başına bir sayı, çalıştırma deposu için iki sayı ve yanlarında, bir sayının söyleyemediğini söyleyen altı alan: bilerek geride ne bırakıldığı ve küçük bir sayının “bu kişiyle ilgili burada hiçbir şey saklanmıyor” diye okunup okunamayacağı. deleted, altı sinyal sayısının toplamıdır; çalıştırma sayıları ve aspect_notes_erased onun yanında bildirilir, ona eklenmez.

$ curl -sX DELETE "$MCPD/v1/api/subjects/u_8841?project=checkout" | jq{  "project": "checkout",  "traces": 1,  "spans": 2,  "logs": 1,  "metrics": 0,  "scores": 1,  "feedback": 1,  "deleted": 6,  "runs_erased": 1,  "runs_in_flight": 0,  "dataset_items_erased": 1,  "aspect_notes_erased": 0,  "datasets": [    "checkout-regressions"  ],  "deletes_pending": false,  "unmatchable_identifiers": 0,  "note": "1 captured dataset cases were emptied in place rather           than deleted, so a regression test is not destroyed           without anyone being told. They hold no payload any           more."}

Alınmış öğeler silinmez, boşaltılır

Üretimden alınmış bir veri kümesi öğesi girdinin birebir kopyasını tutar, yani çalıştırmayı silip kopyayı bırakmak kişinin sözlerini veri kümesinde bırakırdı. Öğeyi tümden silmek başka türlü bir zarardır: birileri o çalıştırmayı bir hatanın geri gelmesini engellemek için almıştır ve onların regresyon testini haber vermeden yok etmek mcpd'nin kendi başına vereceği bir karar değildir.

Bu yüzden payload'ın üzerine yazılır ve satır yaşamaya devam eder. Öğe, girdisinin ve metadata'sının bulunduğu yerde {"erased": true} okur, kaynak çalıştırmaya olan bağı temizlenir ve yanıt kaç öğe olduğunu ve hangi veri kümelerini adlandırır. Öğe gözle görülür biçimde boştur ve bu, bir operatörün üzerine gidebileceği bir şeydir.

Bir öğe tümüyle erişim dışıdır ve nedeni kiracılıktır. Başka bir projeye ait bir veri kümesine alınmış bir öğe boşaltılmaz ve sayılmaz. Çağrı tek bir proje için yetkilendirilir ve tek bir projeye dokunur; bu sınırı aşan bir silme, okuyamadığınız bir veri kümesinin içinde ne olduğunu öğrenmenin bir yolu olurdu. Kişiyi o projeden de, oraya erişen bir anahtarla silin.

Yapmadıkları

Tek bir projeye dokunur. ?project= onu adlandırır ve siz vermediğinizde daemon'un varsayılan projesi kullanılır. O projeye erişemeyen bir anahtar 403 ile reddedilir ve hiçbir şey silinmez. Aynı kişinin, anahtarın açamadığı bir projedeki satırlarına ne dokunulur ne de sayılır, yani bir sayı öznenin başka bir yerde var olduğunu asla açık edemez. Bir kişiyi birkaç projeden silmek, her birine erişen bir anahtarla proje başına bir çağrıdır.

Hakkında hiçbir şey saklanmayan bir özne 404 değil, sıfırlar taşıyan bir 200'dür. İstediğiniz durum zaten geçerlidir ve bir 404, kimsenin sormaya hakkı olmayan bir soruyu yanıtlardı: o kişinin bu anahtarın görebildiği bir yerde var olup olmadığını. Bir zaman aşımından sonra tekrarın güvenli olmasının nedeni de budur. İkinci çağrı bir hata değil, ikinci bir taramanın daha küçük sayılarını bildirir.

Bu, bir kişiyi kendi sistemlerinizden silmenin yolu değildir. mcpd, mcpd'nin sakladığını siler. Başka bir OTLP endpoint'ine ilettiğiniz her şeyin orada da silinmesi gerekir ve mcpd ona ne olduğunu bilmez.

Anahtarlar ve bunun kaydı

Anahtarlar yapılandırıldığında silme bir admin anahtarı ister; admin anahtarı ayarlanmamışsa read anahtarlarına geri düşer, böylece mevcut bir dağıtım sahip olduğu erişimi korur. Eylem, proje ve isteyen anahtarın özetiyle birlikte denetim günlüğüne yazılır; reddedilmiş bir deneme de aynı şekilde kaydedilir. user_id özetlendiğinde satırın adlandırdığı şey özettir: denetim günlüğü anlattığı veriden uzun yaşar, yani oraya ham tanımlayıcıyı yazmak, kişinin kaldırmanızı istediği adı saklamanın budamadığı bir tabloda bırakırdı.

Tek seferde bir çalıştırma seçeneği de duruyor. DELETE /v1/api/traces/{trace_id} tek bir çalıştırmayı ve ona bağlı her şeyi tek bir işlemde kaldırır ve silinen satır sayısını döndürür.

Bir silmeden gelen sıfır, en çok kuşkulanılacak değerdir

Bir sıfır, bir operatörün bir kişiye “sizinle ilgili hiçbir şey tutmuyoruz” diye tekrarladığı şeydir ve bu endpoint'in kanıtlayamadığı tek sayıdır. Saklanan tanımlayıcılar maskeleme anahtarıyla özetlenir ve hangi anahtarın hangi satırı özetlediğini hiçbir yer kaydetmez, yani bir sıfır aynı ölçüde o satırlar yazıldıktan sonra anahtarın değiştiği anlamına da gelebilir. mcpd ikisini birbirinden ayıramaz. Yapabildiği şey, birincisi gibi okunan çıplak bir sıfırı hiçbir zaman geri vermemektir.

Aşağıda aynı özne, çalıştırma kaydedildikten sonra döndürülmüş bir maskeleme anahtarı altında siliniyor. Sayıların hepsi sıfır ve satır hâlâ orada:

$ curl -sX DELETE "$MCPD/v1/api/subjects/u_8841?project=checkout" | jq "{deleted, unmatchable_identifiers, note}"{  "deleted": 0,  "unmatchable_identifiers": 0,  "note": "Nothing matched. Stored identifiers are hashed with           the redaction key, so this means no stored identifier           hashes to this subject under the key in force now. It           does not mean nothing about this person was ever           stored: rows written under a different redaction key           cannot be matched by this endpoint."}

Notun kanıtlayabileceği şey projeye bağlıdır. Projedeki hiçbir şey kimseye atfedilmemişse, bir anahtar değişikliğinin gizleyebileceği bir satır yoktur ve not bunun yerine tam olarak bunu söyler. Aksi halde bir sıfır kanıtlanmamıştır: o satırların yazıldığı maskeleme anahtarını geri getirin ve isteği tekrarlayın.

Reddetmek yerine bildirir ve bu bilinçli bir ödünleşimdir. Reddetmek, bir zaman aşımından sonraki tekrarı bozardı; “hiç görülmedi” yanıtını “bir saat önce silindi” yanıtından farklı kılarak endpoint'i, bir kişinin bir proje tarafından bilinip bilinmediğini sormanın yoluna çevirirdi; ve maskeleme ayarı bir kez değişmiş bir dağıtımdaki her silmeyi, doğru biçimde hiçbir şeyle eşleşmeyenler dahil, engellerdi.

Bu isteğin eşleştiremeyeceği tanımlayıcılar

Bir döndürme görünmezdir. Tanımlayıcıların hiç özetlenip özetlenmediğine dair bir değişiklik görünmez değildir ve unmatchable_identifiers mcpd'nin görebildiği şeydir. Özetlenmiş bir tanımlayıcı sha256: önekinden tanınır, bu yüzden depo, tuttuğu tanımlayıcılardan kaçının bu isteğin taşıdığının tersi biçimde olduğunu sayar: özetlenmiş bir isteğe karşı düz metin satırlar veya tersi. O satırlar başka bir maskeleme ayarı altında yazılmıştır, özneye ait olabilirler ve bu istek onlara erişemez.

Sayım yalnızca sıfırda değil, her silmede çalışır ve aşağıdaki yanıt bunun nedenidir. Bu projeye önce maskeleme açıkken, sonra kapalıyken yazıldı. İstek daha yeni satırlarla eşleşti ve onları sildi; daha eski iki tanımlayıcı ise özetlenmiş, yani bu istek onlara hiçbir zaman erişemezdi. deleted ile duran bir sayım, eksiksiz bir yanıt gibi okunurdu:

$ curl -sX DELETE "$MCPD/v1/api/subjects/u_8841?project=checkout" | jq "{deleted, unmatchable_identifiers, note}"{  "deleted": 2,  "unmatchable_identifiers": 2,  "note": "2 stored identifiers in this project are in a form           this request could not match, so rows written under a           different redaction setting were not searched and rows           about this person may remain. Restore the redaction           setting those rows were written under and repeat the           request."}

Sayım, öznenin kendi satırları üzerinde değil, projenin tuttuğu her tanımlayıcı üzerindedir, yani o iki tanımlayıcı bambaşka birine ait olabilir. Söyleyebileceğinin en fazlası budur. Dışladığı şey, başarılı görünen bir silmeyi eksiksiz bir silme diye okumaktır.

Güvence üç arka uçta aynı değil

SQLite ve Postgres, size yanıt veren işlemin içinde siler. Yanıt geldiğinde satırlar gitmiştir ve deletes_pending değeri false olur.

ClickHouse böyle yapmaz. Orada silme eşzamansız bir mutasyondur: sunucu ifadeyi kabul eder ve arka planda uygular, yani yanıt diskten neyin çıktığını değil neyin eşleştiğini söyler. Bu silmeler deletes_pending değeri true olarak döner ve bu, mcpd'nin size iki güvenceden zayıf olanının yürürlükte olduğunu söylemesidir. Veri kümesi öğeleri o arka uçta istisnadır. Mutasyona uğratılmak yerine kendi anahtarları altında yeniden yazılırlar, yani yanıt gönderildiği andan itibaren her okuma boşaltılmış öğeyi döndürür. Bir mutasyon, tamamlanana kadar eski metni okunabilir bırakırdı.

Verinin belirli bir ana kadar gittiğini birine belgelemeniz gerekiyorsa, yazmanız gereken fark budur. ClickHouse'ta yanıt vermeden önce mutasyonun sunucuda tamamlandığını doğrulayın.

Port erişilebilir olmadan önce

Maskeleme, bir trace'in içindeki değerleri korur. Trace'i kimin okuyabileceği konusunda hiçbir şey yapmaz. mcpd, alım açıkken veya okuma API'si açıkken loopback dışı bir adrese bağlandığında başlangıçta uyarır, çünkü saklanan prompt'lar ve tamamlamalar o zaman porta erişebilen herkesçe okunabilir. Önce --ingest-key ve --read-key ayarlayın ve Docker ve Kubernetes sayfasını okuyun.

Sırada

• Baştan daha azını tutmak: Örnekleme.
• Her seçenek ve ortam değişkeni: Yapılandırma.
• Yoklamalar, yedekler ve yükseltmeler: İşletme.