Valitse kysymykseen sopiva signaali
OpenTelemetry erottaa muun muassa metriikat, lokit ja jäljet. Ne täydentävät toisiaan takaamatta täydellistä näkyvyyttä. Dokumentoi aikajakso, mittauspisteet ja rajaukset; keskiarvo voi piilottaa hitaat pyynnöt.
| Kysymys | Hyödyllinen signaali | Rajoitus |
|---|---|---|
| Kuinka moni pyyntö epäonnistuu? | Koostetut metriikat | Määritä virheet, kattavuus ja jakso. |
| Mihin aika kului? | Jälki ja vaiheiden kestot | Otanta ja mittaamattomat riippuvuudet. |
| Mitä tapahtui? | Rakenteinen loki | Ei salaisuuksia tai liikaa tietoa. |
| Toimiiko käyttäjäpolku? | Toiminnallinen tarkistus | Yksi tapaus ei kata kaikkea käyttöä. |
Tee diagnoosista käyttökelpoinen
- Mittaa liikenne, virheet ja kestojakaumat normalisoidun toiminnon mukaan. Vältä käyttäjätunnisteita ja muuttuvia URL-osoitteita metriikan luokittelussa.
- Yhdistä tapahtumiin korrelaatiotunniste ja palveluversio. Tarkista kontekstin välitys ja otanta ennen puuttuvan jäljen selvittämistä.
- Liitä hälytykseen vaikutus, vastuuhenkilö ja ensimmäinen toimi. Käytä omia testitilejä ja vältä peruuttamattomia toimintoja.
Suojaa tiedot ja tarkista tulos
Älä lokita salasanoja, tokeneita tai arkaluonteisia sisältöjä. Rajaa käyttöoikeudet ja säilytys. HTTP-onnistuminenkin voi sisältää väärän liiketoimintatuloksen; testaa myös odotetut ehdot ja oikeudet hallitusti.
Alkuperäiset lähteet
Yhdistä telemetria käyttäjätehtävään
Mittarit, lokit ja jäljitykset vastaavat erilaisiin kysymyksiin. Korkea käyttöaika voi peittää epäonnistuneen uloskirjautumis- tai kirjautumisprosessin. Määritä käyttäjien odottama tulos ja mittaa sitten kutsut, jotka sen tuottavat.
- Valitse onnistumisen, viiveen ja käyttäjälle näkyvän epäonnistumisen ilmaisin.
- Levitä korrelaatiota palveluiden välillä ja rajoita arkaluonteisten tietojen määrää jäljityksissä.
- Harjoittele riippuvuusvirhettä nähdäksesi, johtavatko hälytykset toimintaan ja ymmärrettävään heikentyneeseen tilaan.
Ensisijainen lähde: OpenTelemetry — Observability primer. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Keruun katkos: lokien ja puuttuvien tapahtumien täsmäytys
Erota tuotetut, vastaanotetut ja käytettävät tapahtumat; hiljaisuus ei osoita häiriöiden puuttumista.
- Kartoita sovellus, kerääjä ja tallennus vastuineen. Valmistele rajallinen kuvitteellinen tapahtumajono vakailla tunnisteilla ilman salaisuuksia tai asiakastietoja. Säilytä tapahtuma- ja havaintoaika: keruun viive ei automaattisesti tarkoita menetystä.
- Katkaise testissä kohde ja palauta se. Tarkkaile jonon täyttymistä, yrityksiä, hylkäyksiä ja käynnistystä. Pysyvä jono voi vähentää menetyksiä, mutta on rajallinen ja riippuu tallennuksesta; määritä täyden jonon toiminta. Tarkista ettei keruu hiljaisesti estä palvelua.
- Täsmäytä vertailujoukko luettaviin tapahtumiin samalla havaintokatkaisulla. Laske toistot, viiveet ja puutteet erikseen; verkkokuittaus ei todista lopullista käytettävyyttä. Ilman luotettavaa vertailua kattavuus on tuntematon, ei nolla menetystä tai häiriötä.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"expected_ids": [
"E1",
"E2",
"E3"
],
"received_ids": [
"E1",
"E1",
"E3"
],
"received_rows": 3,
"unique_received": 2,
"missing_ids": [
"E2"
],
"observation_cutoff": "same_for_both_sets"
}Odotettu päätös
Kuvitteellinen esimerkki: E1, E2 ja E3 odotetaan, mutta E1, E1 ja E3 saapuvat. Kolme riviä ei todista täydellisyyttä: E1 toistuu ja E2 puuttuu havaintokatkaisulla.
Todistavatko kolme riviä kolme säilytettyä tapahtumaa?
Eivät. Kaksi riviä voi toistaa tunnisteen ja peittää puutteen. Vertaa tunnisteita, havaintoikkunaa ja ketjun vaiheita.
Ensisijainen lähde: OpenTelemetry — Collector resiliency. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Hylätyt aliverkkotunnukset: CNAME-viitteen hallittu poisto
Yhdistä DNS-nimet hallittuihin resursseihin ja sulje riippuvuudet ennen resurssin vapautusta.
- Kirjaa nimi, CNAME-ketju, tarjoajan resurssi ja omistaja. Vertaa DNS-vyöhykettä valtuutetun tilin inventaarioon. HTTP-virhe, NXDOMAIN tai puuttuva resurssi vaatii selvityksen, ei todista haltuunoton mahdollisuutta. Suojaukset riippuvat tarjoajasta.
- Poista DNS-viite tai ohjaa se hallittuun kohteeseen ennen resurssin vapautusta. Huomioi aiemmat TTL-arvot ja välimuistit; tarkista auktoritatiivinen DNS ja useita resolvereita. Säilytä tarvittavat omistajuuden vahvistukset äläkä poista kaikkia TXT-tietueita.
- Tarkista linkit, uudelleenohjaukset, OAuth-paluuosoitteet, webhookit ja evästeiden verkkotunnukset. Jos resurssi on jo vapautettu, korjaa DNS ja tutki altistuminen poikkeamaprosessissa. Täsmäytä DNS ja resurssit jokaisen poiston jälkeen.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Odotettu päätös
Kuvitteellinen esimerkki: portal.example osoittaa poistettuun resurssiin. Poista CNAME tai valitse hallittu kohde; puuttuva resurssi ei yksin todista ulkopuolisen haltuunottoa.
Ensisijainen lähde: Microsoft — Prevent dangling DNS entries. Aiheeseen liittyvä menetelmä: lue käytännön opas.
API-uusinnat: laske koko aikabudjetti
Erota kutsut, odotukset ja koko polku.
Kuvitteellinen opetustapaus: luvut eivät kuvaa CIE:tä tai asiakkaita.
Kuvitteellinen malli: neljä enintään 250 ms:n kutsua ja odotukset 100, 200, 400 ms. Jitter, yhteys, jonot ja paikallinen tarkistus puuttuvat.
- Yrityksiä yhteensä
- 41 + 3
- Odotus yhteensä (ms)
- 700100 + 200 + 400
- Mallin aikabudjetti (ms)
- 17004 × 250 + 700
| Vaihe | Kutsun enimmäisaika (ms) | Seuraava odotus (ms) |
|---|---|---|
| Yritys 1 | 250 | 100 |
| Yritys 2 | 250 | 200 |
| Yritys 3 | 250 | 400 |
| Yritys 4 | 250 | 0 |
| Yhteensä | 1000 | 700 |
- Kutsuaika1 000
- Odotusaika yhteensä700
- Kokonaismääräaika (ms)1 500
Tarkistukset ennen johtopäätöstä
- 1 000 + 700 = 1 700 ms ylittää 1 500 ms:n määräajan.
- Välitä kokonaismääräaika ja estä kaksoisvaikutukset; timeout ei todista etäpään peruutusta.
Kokeile uusintojen aikabudjettia
n × T + W × (2^(n−1) − 1)
Aiheeseen liittyvä menetelmä: lue käytännön opas.
Lähteet: tiedot, käyttö ja rajat
Aineisto tarkistettu .
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
| Lähde ja tarkoitus | Tarkistettu tieto tai vertailukohta | Käyttö käytännössä | Huomioitava rajoitus |
|---|---|---|---|
| NIST · SP 800-61 Rev. 3 Prepare incident response within cybersecurity risk management. |
Revision 3 was published in April 2025 and supersedes Revision 2. It is a CSF 2.0 Community Profile. | Rehearse containment decisions, evidence preservation, communication and recovery. Compare planned actions with evidence produced during the exercise. | Reading the guide does not validate a local plan. Contacts, emergency access and dependencies need local testing. |
| Google · Core Web Vitals Distinguish loading, responsiveness and visual stability. |
Good thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile, segmented by mobile and desktop. | Separate field measurement from laboratory tests. Record period, URL, device, population and sample size before comparing changes. | These thresholds are not measured results for this site. A good lab score alone does not establish visitor experience. |
API: vanhentuminen ja poistuminen
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
Announced retirement and continuity to verify
A Sunset field signals intent; it establishes neither actual shutdown nor guaranteed continuity until then. Prepare dependencies, data and access to move.
- Identify the announcement’s exact scope and owner.
- Keep dates and updates with receipt evidence.
- Test exit, in-flight operations and removal of obsolete access.
Compare deprecation and retirement announcements →
IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23
IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23