ਸਿੱਖੋ ਕਿ ਟਾਈਮ-ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ ਮੇਟਰਿਕਸ, ਮਾਨੀਟਰਨਿੰਗ ਅਤੇ ਨਿਰੀਖਣਯੋਗਤਾ ਨੂੰ ਕਿਵੇਂ ਸੰਚਾਲਿਤ ਕਰਦੇ ਹਨ—ਤੇਜ਼ ਕੁਐਰੀਜ਼, ਬਿਹਤਰ ਕੰਪ੍ਰੈਸ਼ਨ, ਉੱਚ-ਕਾਰਡੀਨੈਲਿਟੀ ਲਈ ਸਮਰਥਨ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਅਲਰਟਿੰਗ।
ਮੇਟਰਿਕਸ ਉਹ ਨੰਬਰ ਹਨ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ ਸਿਸਟਮ ਕੀ ਕਰ ਰਹੀ ਹੈ—ਉਹ ਮਾਪ ਜਿੰਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਚਾਰਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ request latency, error rate, CPU ਵਰਤੋਂ, queue depth ਜਾਂ active users.
ਮਾਨੀਟਰਨਿੰਗ ਉਹ ਅਭਿਆਸ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਮਾਪ ਇਕੱਠੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਡੈਸ਼ਬੋਰਡਾਂ ਉੱਤੇ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਕੁਝ ਗਲਤ ਲੱਗੇ ਤਾਂ ਅਲਰਟ ਸੈਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜੇ checkout ਸੇਵਾ ਦੀ error rate ਵਧੇ, ਤਾਂ ਮਾਨੀਟਰਨਿੰਗ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਅਤੇ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਦੱਸਣੀ ਚਾਹੀਦੀ ਹੈ।
ਨਿਰੀਖਣਯੋਗਤਾ (observability) ਇੱਕ ਕਦਮ ਅੱਗੇ ਹੈ: ਇਹ ਤੁਹਾਡੀ ਯੋਗਤਾ ਹੈ ਕਿ ਤੁਸੀਂ ਦੇਖ ਕੇ ਸਮਝ ਸਕੋ ਕਿਉਂ ਕੁਝ ਹੋ ਰਿਹਾ ਹੈ—ਅਕਸਰ metrics, logs ਅਤੇ traces ਨੂੰ ਇਕੱਠਾ ਕਰਕੇ। ਮੇਟਰਿਕਸ ਦੱਸਦੇ ਹਨ ਕੀ ਬਦਲਿਆ, ਲੋਗ ਦਿੰਦੇ ਹਨ ਕੀ ਹੋਇਆ, ਅਤੇ ਟ੍ਰੇਸ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿਸ ਸੇਵਾ ਵਿੱਚ ਸਮਾਂ ਖਰਚ ਹੋਇਆ।
ਟਾਈਮ-ਸੀਰੀਜ਼ ਡੇਟਾ "value + timestamp" ਹੁੰਦਾ ਹੈ, ਜੋ ਲਗਾਤਾਰ ਆਉਂਦਾ ਹੈ।
ਉਸ ਸਮੇਂ-ਹਿੱਸੇ ਕਾਰਨ ਤੁਸੀਂ ਡੇਟਾ ਨਾਲ ਇਨ੍ਹਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਵਰਤੋਂ ਕਰਦੇ ਹੋ:
ਇੱਕ ਟਾਈਮ-ਸੀਰੀਜ਼ ਡੇਟਾਬੇਸ (TSDB) ਇਸ ਲਈ ਅਨੁਕੂਲ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਇਹ ਬਹੁਤ ਸਾਰੀ timestamped ਪੌਇੰਟਸ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ingest ਕਰੇ, ਉਨ੍ਹਾਂ ਨੂੰ ਕੁਪਯੋਗਤਾਪੂਰਕ ਸਾਂਭੇ ਅਤੇ ਸਮੇਂ ਦੀ ਰੇਂਜਾਂ ’ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕ੍ਵੈਰੀ ਦੇ ਸਕੇ।
ਇੱਕ TSDB ਆਪਣੇ ਆਪ instrumentation ਦੀ kami, unclear SLOs, ਜਾਂ ਸ਼ੋਰ ਵਾਲੇ alerts ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਲੋਗਸ ਅਤੇ ਟ੍ਰੇਸ ਨੂੰ ਬਦੀਲ ਨਹੀਂ ਕਰਦਾ; ਇਹ ਉਨ੍ਹਾਂ ਦੀ ਪੂਰਕ ਹੈ—ਮੇਟਰਿਕ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਭਰੋਸੇਯੋਗ ਅਤੇ ਲਾਗਤ-ਪੱਖੀ ਬਣਾਉਂਦਾ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਹਰ ਮਿੰਟ ਆਪਣੀ API ਦੀ p95 latency ਨੂੰ ਚਾਰਟ ਕਰਦੇ ਹੋ। 10:05 'ਤੇ ਇਹ 180ms ਤੋਂ 900ms ਉੱਤੇ ਚਲ ਜਾਂਦੀ ਅਤੇ ਉੱਥੇ ਰਹਿੰਦੀ ਹੈ। ਮਾਨੀਟਰਨਿੰਗ ਇੱਕ ਅਲਰਟ ਜਨਰੇਟ ਕਰਦੀ ਹੈ; ਨਿਰੀਖਣਯੋਗਤਾ ਤੁਹਾਨੂੰ ਉਸ spike ਨੂੰ ਕਿਸੇ ਖ਼ਾਸ ਰੀਜ਼ਨ, endpoint ਜਾਂ deployment ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ—ਮੇਟਰਿਕ ਰੁਝਾਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰ ਕੇ ਅੰਦਰੂਨੀ ਸਿਗਨਲਾਂ ਤੱਕ ਡ੍ਰਿੱਲ-ਡਾਊਨ ਕਰਕੇ।
ਟਾਈਮ-ਸੀਰੀਜ਼ ਮੇਟਰਿਕਸ ਦਾ ਸਧਾਰਣ ਰੂਪ ਹੁੰਦਾ ਹੈ, ਪਰ ਉਨ੍ਹਾਂ ਦੀ ਮਾਤਰਾ ਅਤੇ ਐਕਸੈਸ ਪੈਟਰਨ ਉਨ੍ਹਾਂ ਨੂੰ ਖ਼ਾਸ ਬਣਾਉਂਦੇ ਹਨ। ਹਰ ਡੇਟਾ ਪੌਇੰਟ ਆਮ ਤੌਰ 'ਤੇ timestamp + labels/tags + value ਹੁੰਦਾ ਹੈ—ਉਦਾਹਰਨ ਵਜੋਂ: “2025-12-25 10:04:00Z, service=checkout, instance=i-123, p95_latency_ms=240”。 timestamp ਘਟਨਾ ਨੂੰ ਸਮੇਂ ਵਿੱਚ ਲਾਈਟ ਕਰਦਾ ਹੈ, labels ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਚੀਜ਼ ਇਹ ਜਾਰੀ ਕਰ ਰਹੀ ਹੈ, ਅਤੇ value ਉਹ ਨਾਪ ਹੈ ਜੋ ਤੁਸੀਂ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ।
ਮੇਟਰਿਕਸ ਸਿਸਟਮ ਕਦੇ-ਕਦੇ ਬੈਚਾਂ ਵਿੱਚ ਨਹੀਂ ਲਿਖਦੇ। ਉਹ ਲਗਾਤਾਰ ਲਿਖਦੇ ਹਨ, ਅਕਸਰ ਹਰ ਕਈ ਸਕਿੰਟਾਂ ਤੇ, ਬਹੁਤ ਸਾਰੇ ਸਰੋਤਾਂ ਤੋਂ ਇਕੱਠੇ। ਇਸ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਲਿਖਣਾਂ ਦਾ ਸਟਰੀਮ ਬਣਦਾ ਹੈ: counters, gauges, histograms, ਅਤੇ summaries ਜੋ ਰੁਕਦੇ ਹੀ ਨਹੀਂ।
ਸਧਾਰਣ ਵਾਤਾਵਰਣ ਵੀ ਹੌਲੀ-ਹੌਲੀ ਮਿਲੀਅਨ ਪੌਇੰਟ ਪ੍ਰਤੀ ਮਿੰਟ ਉਤਪੰਨ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ scrape intervals ਨੂੰ hosts, containers, endpoints, regions, ਅਤੇ feature flags ਨਾਲ ਗੁਣਾ ਕਰਦੇ ਹੋ।
ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ ਡੇਟਾਬੇਸਾਂ ਦੇ ਉਲਟ ਜਿੱਥੇ ਤੁਸੀਂ “ਨਵੀਨਤਮ ਰੋ” ਖਿੱਚਦੇ ਹੋ, ਟਾਈਮ-ਸੀਰੀਜ਼ ਵਰਤੋਂਕਾਰ ਆਮ ਤੌਰ 'ਤੇ ਪੁੱਛਦੇ ਹਨ:
ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਆਮ ਕ੍ਵੈਰੀਜ਼ ਰੈਂਜ ਸਕੈਨ, ਰੋਲਅਪਸ (ਜਿਵੇਂ 1s → 1m averages), ਅਤੇ Aggregations ਜਿਵੇਂ percentiles, rates, ਅਤੇ grouped sums ਹੁੰਦੀਆਂ ਹਨ।
ਟਾਈਮ-ਸੀਰੀਜ਼ ਡੇਟਾ ਦੀ ਕਦਰ ਇਸ ਲਈ ਹੁੰਦੀ ਹੈ ਕਿ ਇਹ ਉਹ ਨਮੂਨੇ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਅਲੱਗ-ਅਲੱਗ ਘਟਨਾਵਾਂ ਵਿੱਚ ਮੁਸ਼ਕਲ ਨਾਲ ਦੇਖੇ ਜਾਂਦੇ ਹਨ: spikes ( incidents ), seasonality (ਦਿਨ/ਹਫਤੇ ਦੇ ਚੱਕਰ), ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਰੁਝਾਨ (capacity creep, gradual regressions)। ਇੱਕ ਡੇਟਾਬੇਸ ਜੋ ਸਮੇਂ ਨੂੰ ਸਮਝਦਾ ਹੈ, ਇਨ੍ਹਾਂ ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਕ효ਸ਼ਲਤਾ ਨਾਲ ਸਟੋਰ ਕਰਨ ਅਤੇ ਡੈਸ਼ਬੋਰਡ/ਅਲਰਟਿੰਗ ਲਈ ਕ੍ਵੈਰੀਜ਼ ਤੇਜ਼ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ TSDB ਇਕ ਐਸਾ ਡੇਟਾਬੇਸ ਹੈ ਜੋ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਟਾਈਮ-ਆਰਡਰਡ ਡੇਟਾ ਲਈ ਬਣਿਆ ਹੁੰਦਾ ਹੈ—ਉਹ ਮਾਪ ਜੋ ਲਗਾਤਾਰ ਆਉਂਦੇ ਹਨ ਅਤੇ ਪ੍ਰਧਾਨ ਤੌਰ 'ਤੇ ਸਮੇਂ ਨਾਲ ਕ੍ਵੈਰੀ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਮਾਨੀਟਰਨਿੰਗ ਵਿੱਚ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਮੇਟਰਿਕਸ ਹਨ ਜਿਵੇਂ CPU ਵਰਤੋਂ, request latency, error rate, ਜਾਂ queue depth, ਹਰ ਇੱਕ ਇੱਕ timestamp ਅਤੇ ਲੇਬਲਾਂ (service, region, instance ਆਦਿ) ਨਾਲ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਜਨਰਲ-ਪਰਪਜ਼ ਡੇਟਾਬੇਸਾਂ ਦੇ ਉਲਟ ਜੋ ਬਹੁਤ ਸਾਰੇ ਐਕਸੈਸ ਪੈਟਰਨ ਲਈ ਰੋਜ਼ਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਨ, TSDBs ਆਮ ਮੈਟਰਿਕ ਵਰਕਲੋਡ ਲਈ optimize ਹੁੰਦੇ ਹਨ: ਨਵੇਂ ਪੌਇੰਟਸ ਨੂੰ ਲਿਖਦੇ ਜਾਵੋ ਜਿਵੇਂ ਸਮਾਂ ਅੱਗੇ ਵਧਦਾ ਹੈ ਅਤੇ ਹਾਲੀਆ ਇਤਿਹਾਸ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹੋ। ਡੇਟਾ ਆਮ ਤੌਰ 'ਤੇ ਸਮੇਂ-ਅਧਾਰਿਤ chunks/blocks ਵਿੱਚ ਰਗੜਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕਿ ਇੰਜਨ “ਆਖਰੀ 5 ਮਿੰਟ” ਜਾਂ “ਆਖਰੀ 24 ਘੰਟੇ” ਨੂੰ ਪ੍ਰਭਾਵਸ਼ালী ਢੰਗ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕੇ ਬਿਨਾਂ ਹੋਰ ਅਣਜਾਣੇ ਡੇਟਾ ਨੂੰ ਛੇੜੇ।
ਮੇਟਰਿਕਸ ਆਮ ਤੌਰ 'ਤੇ ਨੰਬਰਾਤਮਕ ਹੁੰਦੇ ਹਨ ਅਤੇ ਧੀਰੇ-ਧੀਰੇ ਬਦਲਦੇ ਹਨ। TSDBs ਇਸਦਾ ਫਾਇਦਾ ਉਠਾਉਂਦੇ ਹਨ ਖ਼ਾਸ encoding ਅਤੇ compression ਤਕਨੀਕਾਂ ਨਾਲ (ਊਦਾਹਰਨ ਲਈ, adjacent timestamps ਵਿਚ delta encoding, run-length patterns, ਅਤੇ ਦੁਹਰਾਏ ਲੇਬਲ ਸੈਟਾਂ ਲਈ ਸੰਕੁਚਿਤ ਸਟੋਰੇਜ਼)। ਨਤੀਜਾ: ਤੁਸੀਂ ਇਕੋ ਸਟੋਰੇਜ਼ ਬਜਟ ਲਈ ਵਧੇਰੇ ਇਤਿਹਾਸ ਰੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਕ੍ਵੈਰੀਜ਼ ਡਿਸਕ ਤੋਂ ਘੱਟ ਬਾਇਟਾਂ ਪੜ੍ਹਦੀਆਂ ਹਨ।
ਮਾਨੀਟਰਨਿੰਗ ਡੇਟਾ ਆਮ ਤੌਰ 'ਤੇ append-only ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਰੇਅਰ ਹੀ ਪੁਰਾਣੀਆਂ ਪੌਇੰਟਸ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹੋ; ਨਵੇਂ ਪੌਇੰਟ ਜੋੜਦੇ ਹੋ। TSDBs ਇਸ ਪੈਟਰਨ 'ਤੇ ਨਿਵੇਸ਼ ਕਰਦੇ ਹਨ ਸੈਕੇਵੈਂਸ਼ਲ ਲਿਖਤਾਂ ਅਤੇ ਬੈਚ ingestion ਨਾਲ। ਇਸ ਨਾਲ ਰੈਂਡਮ I/O ਘਟਦਾ ਹੈ, write amplification ਘਟਦੀ ਹੈ, ਅਤੇ ingestion ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ ਭਾਵੇਂ ਬਹੁਤ ਸਾਰੇ ਮੇਟਰਿਕਸ ਇੱਕ ਵਾਰ ਆਉਣ।
ਜ਼ਿਆਦਾਤਰ TSDBs ਉਹ ਕ੍ਵੈਰੀ ਪ੍ਰਿਮਿਟਿਵਜ਼ ਦਿੰਦੇ ਹਨ ਜੋ ਮਾਨੀਟਰਨਿੰਗ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਲਈ ਮੌਜੂਦ ਹਨ:
ਭਾਵੇਂ syntax ਉਤਪਾਦਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਹੋਵੇ, ਇਹ ਪੈਟਰਨ ਡੈਸ਼ਬੋਰਡ ਬਣਾਉਣ ਅਤੇ ਅਲਰਟ ਮੁਲਾਂਕਣ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਦੀ ਬੁਨਿਆਦ ਹਨ।
ਮਾਨੀਟਰਨਿੰਗ ਇੱਕ ਅਜੇਹੀ ਲਗਾਤਾਰ ਜਾਣਕਾਰੀ ਦਾ ਸਟਰੀਮ ਹੈ ਜੋ ਰੁਕਦੀ ਨਹੀਂ: CPU ਹਰ ਕੁਝ ਸਕਿੰਟ 'ਤੇ, request counts ਹਰ ਮਿੰਟ, queue depth ਸਾਰਾ ਦਿਨ। ਇੱਕ TSDB ਇਸ ਪੈਟਰਨ ਲਈ ਬਣਿਆ ਹੁੰਦਾ ਹੈ—ਲਗਾਤਾਰ ingestion ਅਤੇ “ਹੁਣ ਕੀ ਹੋ ਰਿਹਾ ਹੈ?” ਵਾਲੇ ਸਵਾਲ—ਇਸ ਲਈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਮੇਟਰਿਕਸ ਲਈ ਵਰਤਦੇ ਹੋ ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਜਨਰਲ-ਪਰਪਜ਼ ਡੇਟਾਬੇਸ ਨਾਲੋਂ ਤੇਜ਼ ਅਤੇ ਹੋਰ ਪੇਸ਼ਗੋਇ ਰਹਿੰਦਾ ਹੈ।
ਅਧਿਕਤਰ ਸੰਚਾਲਕੀ ਸਵਾਲ ਰੈਂਜ ਕ੍ਵੈਰੀਜ਼ ਹੁੰਦੇ ਹਨ: “ਆਖਰੀ 5 ਮਿੰਟ ਦਿਖਾਓ,” “ਪਿਛਲੇ 24 ਘੰਟਿਆਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ,” “deploy ਤੋਂ ਬਾਅਦ ਕੀ ਬਦਲਿਆ?” TSDB ਸਟੋਰੇਜ਼ ਅਤੇ ਇੰਡੈਕਸਿੰਗ ਟਾਈਮ ਰੇਂਜਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਸਕੈਨ ਕਰਨ ਲਈ optimize ਹੁੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਚਾਰਟ ਤੇਜ਼ ਰਹਿੰਦੇ ਹਨ ਭਾਵੇਂ ਤੁਹਾਡਾ ਡੇਟਾਸੇਟ ਵਧੇ।
ਡੈਸ਼ਬੋਰਡ ਅਤੇ SRE ਮਾਨੀਟਰਨਿੰਗ ਕੱਚੇ ਪੌਇੰਟਸ ਨਾਲੋਂ aggregation 'ਤੇ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। TSDBs ਆਮ ਮੈਟਰਿਕ ਗਣਿਤ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਂਦੇ ਹਨ:
ਇਹ ਓਪਰੇਸ਼ਨ noisy samples ਨੂੰ ਅਜਿਹਾ signal ਬਣਾਉਂਦੇ ਹਨ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਅਲਰਟ ਕਰ ਸਕਦੇ ਹੋ।
ਡੈਸ਼ਬੋਰਡ ਆਮ ਤੌਰ 'ਤੇ ਸਾਰਾ ਰੌ-ਡੇਟਾ ਹਮੇਸ਼ਾਂ ਨਹੀਂ ਰੱਖਦੇ। TSDBs ਅਕਸਰ time bucketing ਅਤੇ rollups ਸਪੋਰਟ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਾਲੀਆ ਵਾਰ ਲਈ ਉੱਚ-ਰੇਜ਼ੋਲੂਸ਼ਨ ਡੇਟਾ ਰੱਖ ਸਕੋ ਅਤੇ ਦੂਰ-ਅਵਧੀ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਸੰਖੇਪ ਕੀਤਾ ਹੋਇਆ ਡੇਟਾ ਸਟੋਰ ਕਰੋ। ਇਸ ਨਾਲ ਕੁਐਰੀਜ਼ ਤੇਜ਼ ਰਹਿ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਸਟੋਰੇਜ਼ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਮੁੱਖ ਰੁਝਾਨ ਗੁਆਉਂਦੇ।
ਮੇਟਰਿਕਸ ਬੈਚਾਂ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੇ; ਉਹ ਲਗਾਤਾਰ ਆਉਂਦੇ ਹਨ। TSDBs ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਲਿਖਣ-ਭਾਰ ਵਾਲੇ ਵਰਕਲੋਡ ਤੋਂ ਰੀਡ ਪਰਫਾਰਮੈਂਸ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਬੁਰਾ ਨਹੀਂ ਹੁੰਦਾ, ਜਿਸ ਨਾਲ ਤੁਹਾਡੇ “ਕੀ ਹੁਣ ਕੁਝ ਗੜਬੜ ਹੈ?” ਵਾਲੇ ਸਵਾਲ ਇੰਸੀਡੈਂਟ्स ਅਤੇ ਟਰੈਫਿਕ ਸਪਾਈਕਸ ਦੌਰਾਨ ਭੀ ਭਰੋਸੇਯੋਗ ਰਹਿੰਦੇ ਹਨ।
ਮੇਟਰਿਕਸ ਤਦੋਂ ਤਾਕਤਵਰ ਬਣਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ labels (tags/dimensions) ਰਾਹੀਂ ਤਕੜਾ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਕ single metric ਜਿਵੇਂ http_requests_total ਨੂੰ dimensions ਦੀ ਤਰ੍ਹਾਂ service, region, instance, ਅਤੇ endpoint ਨਾਲ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਤਾਂ ਕਿ ਤੁਸੀਂ ਇਹ ਸੁਆਲ ਪੁੱਛ ਸਕੋ ਕਿ “ਕੀ EU US ਨਾਲੋਂ ਹੌਲਾ ਹੈ?” ਜਾਂ “ਕੋਈ ਇਕ instance ਗਲਤ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ?”
ਕਾਰਡੀਨੈਲਿਟੀ ਉਹ ਗਿਣਤੀ ਹੈ ਜੋ ਤੁਹਾਡੇ metrics ਵੱਲੋਂ ਬਣੇ ਯੂਨੀਕ ਟਾਈਮ ਸੀਰੀਜ਼ਾਂ ਦੀ ਦਰਸਾਉਂਦੀ ਹੈ। ਹਰ ਇੱਕ label value ਦਾ ਯੁੱਗ ਜੋੜ ਇੱਕ ਵੱਖਰਾ ਸੀਰੀਜ਼ ਬਣਾਉਂਦਾ ਹੈ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਤੁਸੀਂ ਇੱਕ ਮੈਟਰਿਕ ਟਰੈਕ ਕਰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ:
…ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ 20 × 5 × 200 × 50 = 1,000,000 ਟਾਈਮ ਸੀਰੀਜ਼ ਹੋਣਗੇ ਇਕਲੋ ਮੈਟਰਿਕ ਲਈ। ਕੁਝ ਹੋਰ labels ਜੋੜੋ (status code, method, user type) ਅਤੇ ਇਹ ਉਸ ਹੱਦ ਤੋਂ ਵੀ ਜ਼ਿਆਦਾ ਵਧ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਸਟੋਰੇਜ਼ ਅਤੇ ਕੁਐਰੀ ਇੰਜਨ ਸੰਭਾਲ ਸਕਦੇ ਹਨ।
ਉੱਚ ਕਾਰਡੀਨੈਲਿਟੀ ਆਮ ਤੌਰ 'ਤੇ graceful ਤਰੀਕੇ ਨਾਲ fail ਨਹੀਂ ਹੁੰਦੀ। ਪਹਿਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ:
ਇਸੇ ਲਈ high-cardinality ਸਹਿਣਸ਼ੀਲਤਾ ਇੱਕ ਮੁੱਖ TSDB ਫਰਕ ਬਣਾਉਂਦੀ ਹੈ: ਕੁਝ ਸਿਸਟਮ ਇਸਨੂੰ ਸੰਭਾਲਣ ਲਈ ਬਣੇ ਹੁੰਦੇ ਹਨ; ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਅਸਥਿਰ ਜਾਂ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਉਹ labels ਵਰਤੋ ਜੋ ਬਾਊਂਡਡ ਅਤੇ ਥੋੜ੍ਹੀ-ਵਿਚਲਨ ਵਾਲੇ ਹਨ, ਅਤੇ ਉਹ labels ਟਾਲੋ ਜੋ ਅਸਲ ਵਿੱਚ ਅਨਬਾਊਂਡ ਹਨ।
ਰੱਖੋ:
service, region, cluster, environmentinstance (ਜੇ ਤੁਹਾਡੀ fleet ਆਕਾਰ ਨਿਯੰਤਰਿਤ ਹੈ)endpoint ਸਿਰਫ ਜੇ ਇਹ ਇੱਕ ਨਾਰਮਲਾਈਜ਼ਡ route template ਹੈ (ਉਦਾਹਰਨ: /users/:id, ਨਾ ਕਿ /users/12345)ਟਾਲੋ:
ਜੇ ਤੁਹਾਨੂੰ ਉਹ ਵਿਸਥਾਰ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਲੋਗਸ ਜਾਂ ਟ੍ਰੇਸ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਇੱਕ સ્થਿਰ label ਰਾਹੀਂ ਮੈਟਰਿਕ ਤੋਂ ਲਿੰਕ ਕਰੋ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਹਾਡੀ TSDB ਤੇਜ਼ ਰਹੇਗੀ, ਤੁਹਾਡੇ ਡੈਸ਼ਬੋਰਡ ਵਰਤਣਯੋਗ ਰਹਿਣਗੇ, ਅਤੇ ਤੁਹਾਡੀ ਅਲਰਟਿੰਗ ਸਮੇਂ 'ਤੇ ਰਹੇਗੀ।
ਮੇਟਰਿਕਸ ਨੂੰ "ਸਦਾ ਲਈ" ਰੱਖਣਾ ਆਕਰਸ਼ਕ ਲੱਗਦਾ ਹੈ—ਜਦ ਤੱਕ ਸਟੋਰੇਜ਼ ਦੇ ਬਿੱਲ ਵਧਦੇ ਅਤੇ ਕੁਐਰੀਜ਼ ਧੀਮੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ TSDB ਤੁਹਾਨੂੰ ਉਹ ਡੇਟਾ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਉਸ ਵੇਰਵੇ ਵਿੱਚ ਜੋ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਉਸ ਸਮੇਂ ਲਈ।
ਮੇਟਰਿਕਸ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ (ਉਹੀ ਸੀਰੀਜ਼, ਨਿਰਧਾਰਤ ਸੈਂਪਲਿੰਗ ਇੰਟਰਵਲ, ਬਿੰਦੂਆਂ ਵਿੱਚ ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਅ)। TSDBs ਇਸਦਾ ਫਾਇਦਾ ਉਠਾ ਕੇ ਖ਼ਾਸ ਕੰਪ੍ਰੈਸ਼ਨ ਵਰਤਦੇ ਹਨ, ਅਕਸਰ ਲੰਬਾ ਇਤਿਹਾਸ ਛੋਟੀ ਜਗ੍ਹਾ 'ਤੇ ਰੱਖਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਰੁਝਾਨ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਵਧੇਰੇ ਡੇਟਾ ਰੱਖ ਸਕਦੇ ਹੋ—capacity planning, seasonal patterns, ਅਤੇ “ਪਿਛਲੇ ਕੌਟਰ ਤੋਂ ਬਾਅਦ ਕੀ ਬਦਲਿਆ?”—ਬਿਨਾਂ ਬਰਾਬਰ ਡਿਸਕ ਲਈ ਭੁਗਤਾਨ ਕੀਤੇ।
ਰਿਟੇਨਸ਼ਨ ਸਿਰਫ ਨਿਯਮ ਹੈ ਕਿ ਡੇਟਾ ਕਿੰਨੇ ਸਮੇਂ ਤਕ ਰੱਖਿਆ ਜਾਵੇ।
ਜਿਆਦਾਤਰ ਟੀਮਾਂ ਰਿਟੇਨਸ਼ਨ ਨੂੰ ਦੋ ਪਰਤਾਂ ਵਿੱਚ ਵੰਡਦੀਆਂ ਹਨ:
ਇਹ ਪਹੁੰਚ ਕੱਲ੍ਹ ਦੇ ਅਤਿ-ਵੇਰਵਾ ਡੀਬੱਗਿੰਗ ਡੇਟਾ ਨੂੰ ਅਗਲੇ ਸਾਲ ਦੇ ਮਹਿੰਗੇ ਆਰਕਾਈਵ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਡਾਉਨਸੈਂਪਲਿੰਗ (ਜਿਸਨੂੰ rollups ਵੀ ਕਹਿੰਦੇ ਹਨ) ਕਈ ਰੌ ਪੌਇੰਟਸ ਨੂੰ ਘੱਟ ਸੰਖਿਆ ਵਾਲੇ ਸਾਰਸ ਬਿੰਦੂਆਂ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ—ਅਕਸਰ ਇੱਕ ਟਾਈਮ ਬੱਕੇਟ ਲਈ avg/min/max/count। ਇਹ ਤਦੋਂ ਲਾਗੂ ਕਰੋ ਜਦੋਂ:
ਕੁਝ ਟੀਮਾਂ raw ਵਿੰਡੋ ਦੇ ਖਤਮ ਹੋਣ 'ਤੇ ਆਟੋਮੈਟਿਕ ਡਾਉਨਸੈਂਪਲ ਕਰ ਦਿੰਦੀਆਂ ਹਨ; ਹੋਰ raw ਨੂੰ "ਹਾਟ" ਸੇਵਾਵਾਂ ਲਈ ਲੰਮਾ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਸ਼ੋਰ ਵਾਲੇ ਜਾਂ ਘੱਟ-ਮੁੱਲ ਵਾਲੇ ਮੇਟਰਿਕਸ ਲਈ ਤੇਜ਼ੀ ਨਾਲ ਡਾਉਨਸੈਂਪਲ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।
ਡਾਉਨਸੈਂਪਲਿੰਗ ਸਟੋਰੇਜ਼ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਲੰਬੀ-ਰੇਂਜ ਕੁਐਰੀਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਵਿਸਥਾਰ ਖੋ ਦਿੰਦੇ ਹੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਛੋਟਾ CPU spike 1-ਘੰਟੇ ਦੇ average ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਮਿਟ ਜਾਵੇ, ਜਦੋਂ ਕਿ min/max rollups "ਕੁਝ ਹੋਇਆ" ਦਾ ਸੰਕੇਤ ਰੱਖ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਇਹ ਦਰਸਾਏ ਕਿ ਠੀਕ ਕਦੋਂ ਜਾਂ ਕਿੰਨੀ ਵਾਰੀ।
ਇੱਕ ਰੀਅਲਿਸਟਿਕ ਨਿਯਮ: ਹਾਲੀਆ incidents ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਲਈ raw ਕਾਫ਼ੀ ਲੰਬੇ ਸਮੇਂ ਲਈ ਰੱਖੋ, ਅਤੇ ਉਤਨੇ rollups ਰੱਖੋ ਕਿ ਪ੍ਰੋਡਕਟ ਅਤੇ ਸਮਰੱਥਾ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੱਤਾ ਜਾ ਸਕੇ।
ਅਲਰਟ ਉਸ ਕੁਐਰੀਆਂ ਦੇ ਬਰਾਬਰ ਹੀ ਚੰਗੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਅੰਨਾਂ ਦੇ ਪਿੱਛੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਮਾਨੀਟਰਨਿੰਗ ਸਿਸਟਮ দ্রুত ਅਤੇ ਲਗਾਤਾਰ ਇਹ نہیں ਦੱਸ ਸਕਦੀ ਕਿ “ਕੀ ਇਹ ਸੇਵਾ ਹੁਣ ਗਲਤ ਹੈ?” ਤਾਂ ਤੁਸੀਂ ਜਾਂ incidents ਛੱਡ ਦਿਓਗੇ ਜਾਂ ਸ਼ੋਰ ਵਾਲੇ pages ਮਿਲਣਗੇ।
ਅਧਿਕਤਰ alert ਨਿਯਮ ਕੁਝ ਕੁ ਕ੍ਵੈਰੀ ਪੈਟਰਨਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੇ ਹਨ:
rate() ਵਰਗੇ functions ਵਰਤਦੇ ਹਨ।ਇੱਥੇ ਇੱਕ TSDB ਕਾਰਗਰ ਹੈ ਕਿਉਂਕਿ ਇਹ queries ਨੂੰ ਹਾਲੀਆ ਡੇਟਾ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨਾ, aggregation ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਲਗਾਉਣਾ, ਅਤੇ ਨਿਯਤ ਸਮੇਂ 'ਤੇ ਨਤੀਜੇ ਵਾਪਸ ਦੇਣਾ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ।
ਅਲਰਟ ਇੱਕ-ਪੌਇੰਟ 'ਤੇ ਮੁਲਾਂਕਣ ਨਹੀਂ ਹੁੰਦੇ; ਉਹ ਵਿੰਡੋਜ਼ (ਉਦਾਹਰਨ: “ਆਖਰੀ 5 ਮਿੰਟ”) ਵਿੱਚ ਮੁਲਾਂਕਣ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਛੋਟੀਆਂ ਟਾਈਮਿੰਗ ਸਮੱਸਿਆਵਾਂ ਨਤੀਜੇ ਬਦਲ ਸਕਦੀਆਂ ਹਨ:
ਸ਼ੋਰ-ਉਤਪੰਨ alerts ਅਕਸਰ missing data, uneven sampling, ਜਾਂ overly sensitive thresholds ਕਾਰਨ ਹੁੰਦੇ ਹਨ। flapping—ਤੇਜ਼ੀ ਨਾਲ firing ਅਤੇ resolved ਹੋਣਾ—ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੁੰਦਾ ਹੈ ਕਿ ਨਿਯਮ normal variance ਦੇ ਬਹੁਤ ਨੇੜੇ ਹੈ ਜਾਂ ਵਿੰਡੋ ਬਹੁਤ ਛੋਟਾ ਹੈ।
“ਕੋਈ ਡੇਟਾ ਨਹੀਂ” ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਟ੍ਰੀਟ ਕਰੋ (ਕੀ ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਹੈ, ਜਾਂ ਸੇਵਾ ਬਸ idle ਹੈ?), ਅਤੇ ਜਦੋਂ traffic ਬਦਲਦਾ ਹੈ ਤਾਂ raw counts ਦੀ ਥਾਂ rate/ratio alerts ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
ਹਰ alert ਨੂੰ ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਇੱਕ ਛੋਟੀ ਰਨਬੁੱਕ ਨਾਲ ਜੋੜੋ: ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਣਾ ਹੈ, “ਚੰਗਾ” ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਨਿਯੂਨਤਾ ਕਰਨੀ ਹੈ। ਚਾਹੇ ਇਹ ਸਿਰਫ /runbooks/service-5xx ਅਤੇ ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਲਿੰਕ ਹੋਵੇ, ਇਹ response ਸਮੇਂ ਨੂੰ ਬਹੁਤ ਘਟਾ ਸਕਦਾ ਹੈ।
ਨਿਰੀਖਣ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਸਿਗਨਲ ਕਿਸਮਾਂ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ: ਮੇਟਰਿਕਸ, ਲੋਗਸ, ਅਤੇ ਟ੍ਰੇਸੇਸ। ਇੱਕ TSDB ਮੇਟਰਿਕਸ ਲਈ ਮੁਕੱਦਰ ਸਟੋਰ ਹੁੰਦਾ ਹੈ—ਟਾਈਮ-ਇੰਡੈਕਸਡ ਡੇਟਾ—ਕਿunki ਇਹ ਤੇਜ਼ aggregation, rollups ਅਤੇ “ਆਖਰੀ 5 ਮਿੰਟ ਵਿੱਚ ਕੀ ਬਦਲਿਆ?” ਪ੍ਰਸ਼ਨਾਂ ਲਈ optimize ਕੀਤਾ ਹੁੰਦਾ ਹੈ।
ਮੇਟਰਿਕਸ ਪਹਿਲੀ ਲਾਈਨ-ਆਫ-ਡੀਫੈਂਸ ਹੁੰਦੇ ਹਨ। ਉਹ ਸੰਕੁਚਿਤ, ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸਸਤੇ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਅਲਰਟਿੰਗ ਲਈ ਆਦਰਸ਼ ਹਨ। ਇਹਨਾਂ ਰਾਹੀਂ ਟੀਮਾਂ SLOs ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੀਆਂ ਹਨ ਜਿਵੇਂ “99.9% requests 300ms ਤੋਂ ਘੱਟ” ਜਾਂ “error rate 1% ਤੋਂ ਘੱਟ”।
ਇੱਕ TSDB ਆਮ ਤੌਰ 'ਤੇ ਚਲਾਉਂਦਾ ਹੈ:
ਮੇਟਰਿਕਸ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਕੁਝ ਗਲਤ ਹੈ, ਪਰ ਹਮੇਸ਼ਾ ਕਿਉਂ ਨਹੀਂ।
ਅਮਲ ਵਿੱਚ, ਇੱਕ TSDB “ਤੇਜ਼ ਸਿਗਨਲ” ਮਾਨੀਟਰਨਿੰਗ ਦਾ ਕੇਂਦਰ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਲੋਗ ਅਤੇ ਟ੍ਰੇਸ ਸਿਸਟਮ ਉੱਚ-ਡਿਟੇਲ ਸਬੂਤ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਮੈਟਰਿਕਸ ਦੇ ਦਰਸਾਏ ਰਸਤੇ 'ਤੇ ਚੈੱਕ ਕਰਦੇ ਹੋ।
ਇੰਸਿਡੈਂਟ ਦੌਰਾਨ ਮਾਨੀਟਰਨਿੰਗ ਡੇਟਾ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹੁੰਦੀ ਹੈ—ਠੀਕ ਉਹ ਸਮਾਂ ਜਦੋਂ ਸਿਸਟਮ ਤਣਾਅ 'ਤੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਡੈਸ਼ਬੋਰਡਾਂ 'ਤੇ ਬਹੁਤ ਬਹੁਤ ਲੋੜ ਹੈ। ਇੱਕ TSDB ਨੂੰ ingestion ਅਤੇ ਕ੍ਵੈਰੀਜ਼ ਦੋਹਾਂ ਨੂੰ ਜਾਰੀ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਭਾਵੇਂ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਦੇ ਕੁਝ ਹਿੱਸੇ ਡਿਗਰੇਡ ਹੋ ਰਹੇ ਹੋਣ, ਨਾਹ ਤਾਂ ਤੁਸੀਂ ਉਹ ਟਾਈਮਲਾਈਨ ਗਵਾ ਬੈਠੋਗੇ ਜੋ ਤਸ਼ਖੀਸ ਅਤੇ ਰਿਕਵਰੀ ਲਈ ਲੋੜੀਂਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ TSDBs ਡੇਟਾ ਨੂੰ nodes ਵਿੱਚ horizontally shard ਕਰਕੇ scale ਕਰਦੇ ਹਨ (ਅਕਸਰ time ranges, metric name, ਜਾਂ labels ਦੇ hash ਨਾਲ)। ਇਸ ਨਾਲ write load ਵਿਕਸਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਰੰਤ ਸਮਰੱਥਾ ਵਧਾਉਣ ਲਈ capacity ਜੋੜੀ ਜਾ ਸਕਦੀ ਹੈ।
ਇੱਕ ਨੋਡ ਫੇਲ ਹੋਣ 'ਤੇ ਉਪਲਬਧ ਰਹਿਣ ਲਈ, TSDBs replication 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਇੱਕੋ ਡੇਟਾ ਦੀਆਂ ਕਾਪੀਆਂ ਕਈ ਨੋਡ ਜਾਂ ਜ਼ੋਨ ਵਿੱਚ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਇੱਕ ਰੈਪਲਿਕਾ unavailable ਹੋ ਜਾਵੇ, reads ਅਤੇ writes ਸਿਹਤਮੰਦ ਰੈਪਲਿਕਾ ਤੇ ਜਾਰੀ ਰਹਿ ਸਕਦੇ ਹਨ। ਚੰਗੇ ਸਿਸਟਮ failover ਸਹਾਇਤਾ ਵੀ ਕਰਦੇ ਹਨ ਤਾਂ ingestion pipelines ਅਤੇ query routers ਆਪਣੇ-ਆਪ ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ redirect ਕਰ ਸਕਣ ਘੱਟ ਤੋਂ ਘੱਟ ਗੈਪਸ ਦੇ ਨਾਲ।
ਮੇਟਰਿਕਸ ਟ੍ਰੈਫਿਕ ਬਰਸਟ-ਅਧਾਰਿਤ ਹੁੰਦਾ ਹੈ—deployments, autoscaling events, ਜਾਂ outages 샥 ਬਾਰ samples ਦੀ ਗਿਣਤੀ ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਨ। TSDBs ਅਤੇ ਉਹਨਾਂ ਦੇ collectors ਆਮ ਤੌਰ 'ਤੇ ingestion buffering (queues, WALs, ਜਾਂ local disk spooling) ਵਰਤਦੇ ਹਨ ਤਾਕਿ ਛੋਟੇ spikes ਨੂੰ ਅੰਦਰ ਗੋਲ ਕਰ ਸਕਣ।
ਜਦੋਂ TSDB ਪਿੱਛੇ ਰਹਿ ਜਾਵੇ, backpressure ਮਹੱਤਵਪੂਰਨ ਹੈ। ਬਦਲਣ ਦੀ ਥਾਂ ਡੇਟਾ ਚੁਪਚਾਪ ਡ੍ਰੌਪ ਕਰਨ ਦੇ, ਸਿਸਟਮ clients ਨੂੰ signal ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਧੀਰੇ ਹੋ ਜਾਣ, ਆਵਸ਼ਯਕ ਮੈਟਰਿਕਸ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ, ਜਾਂ ਨਾਨ-ਅਹਿਮ ingestion ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਢੰਗ ਨਾਲ shed ਕਰੋ।
ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਵਿੱਚ, ਇੱਕ TSDB ਅਕਸਰ ਕਈ ਟੀਮਾਂ ਅਤੇ ਵਾਤਾਵਰਣਾਂ (prod, staging) ਨੂੰ serve ਕਰਦੀ ਹੈ। Multi-tenant ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ—namespaces, per-tenant quotas, ਅਤੇ query limits—ਇਹ ਰੋਕਦੀਆਂ ਹਨ ਕਿ ਇੱਕ ਸ਼ੋਰ ਵਾਲਾ ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਗਲਤ ਕੌਂਫਿਗਰਡ ਨੌਕਰੀ ਸਭ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਾ ਕਰੇ। ਸਾਫ਼ isolation chargeback ਅਤੇ access control ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਂਦੀ ਹੈ ਜਿਵੇਂ ਜਦੋਂ ਤੁਹਾਡੀ ਮਾਨੀਟਰਨਿੰਗ ਪ੍ਰੋਗ੍ਰਾਮ ਵਧਦਾ ਹੈ।
ਮੇਟਰਿਕਸ ਅਕਸਰ “ਗੈਰ-ਸੰਵੇਦਨਸ਼ੀਲ” ਸਮਝੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਨੰਬਰ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਦੇ labels ਅਤੇ ਮੈਟਾਡੇਟਾ ਬਹੁਤ ਕੁਝ ਬਿਆਨ ਕਰ ਸਕਦੇ ਹਨ: ਗ੍ਰਾਹਕ ਪਛਾਣ, ਆന്തരਿਕ ਹੋਸਟਨੇਮ, ਇੰਸੀਡੈਂਟਾਂ ਲਈ ਸੂਝ। ਇੱਕ ਚੰਗੀ TSDB ਸੈਟਅੱਪ ਮੈਟਰਿਕ ਡੇਟਾ ਨੂੰ ਕਿਸੇ ਹੋਰ production dataset ਵਾਂਗ ਹੀ ਟਰੀਟ ਕਰਦੀ ਹੈ।
ਅਧਾਰਭੂਤ ਗੱਲਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: agents ਅਤੇ collectors ਤੋਂ TSDB ਤੱਕ ਟ੍ਰੈਫਿਕ ਨੂੰ TLS ਨਾਲ encrypt ਕਰੋ, ਅਤੇ ਹਰ writer ਨੂੰ authenticate ਕਰੋ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ tokens, API keys, ਜਾਂ short-lived credentials per service ਜਾਂ environment 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ।
ਅਮਲੀ ਨਿਯਮ: ਜੇ ਇੱਕ token leak ਹੋ ਜਾਵੇ, ਤਾਂ blast radius ਛੋਟਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪ੍ਰਤੀ-ਟੀਮ, ਪ੍ਰਤੀ-ਕਲستر ਜਾਂ ਪ੍ਰਤੀ-namespace ਲਿਖਣ ਵਾਲੇ credentials ਨੂੰ ਤਰਜੀਹ ਦਿਓ—ਤਾਂ ਜੋ ਤੁਸੀਂ access revoke ਕਰ ਸਕੋ ਬਿਨਾਂ ਸਬ ਕੁਝ ਤਬਾਹ ਕੀਤੇ।
ਮੇਟਰਿਕ ਪੜ੍ਹਨਾ ਲਿਖਣ ਵਾਂਗ ਹੀ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੀ TSDB ਨੂੰ ਐਕਸੈਸ ਕੰਟਰੋਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸੰਸਥਾ ਦੇ ਢਾਂਚੇ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ:
Role-based access control ਅਤੇ project/tenant/metric namespace ਅਨੁਸਾਰ ਸਕੋਪਿੰਗ ਦੀ ਖੋਜ ਕਰੋ। ਇਹ ਗਲਤੀ ਨਾਲ ਡੇਟਾ ਖੁਲਾਸਾ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਡੈਸ਼ਬੋਰਡ/ਅਲਰਟਿੰਗ ਨੂੰ ਮਾਲਿਕਾਨਾ ਦੇ ਅਨੁਸਾਰ ਰੱਖਦਾ ਹੈ।
ਕਈ “ਮੇਟਰਿਕ ਲੀਕ” labels ਰਾਹੀਂ ਹੁੰਦੇ ਹਨ: user_email, customer_id, ਪੂਰੇ URLs, ਜਾਂ request payload ਦੇ ਟੁਕੜੇ। ਵਿਅਕਤੀਗਤ ਡੇਟਾ ਜਾਂ ਯੂਨੀਕ identifiers ਨੂੰ metric labels ਵਿੱਚ ਨਾ ਰੱਖੋ। ਜੇ ਤੁਹਾਨੂੰ user-level debugging ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਲੋਗਸ/ਟ੍ਰੇਸੇਸ ਵਰਤੋ ਜਿਸ ਵਿੱਚ ਕੜੇ ਨਿਯੰਤਰਣ ਅਤੇ ਛੋਟੀ ਰਿਟੇਨਸ਼ਨ ਹੋਵੇ।
ਕੰਪਲਾਇੰਸ ਲਈ, ਤੁਹਾਨੂੰ ਉਤਰ ਦੇਣਾ ਪੈ ਸਕਦਾ ਹੈ: ਕੌਣ ਕਿਨ੍ਹਾ ਸਮੇਂ ਕਿਸ ਮੈਟਰਿਕ ਨੂੰ ਪੜ੍ਹਿਆ? TSDBs (ਅਤੇ ਆਸਪਾਸ ਦੇ gateway) ਜੋ authentication, configuration ਬਦਲਾਅ, ਅਤੇ read access ਲਈ audit logs ਪੈਦਾ ਕਰਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ—ਤਾਂ ਜੋ ਜਾਂਚਾਂ ਅਤੇ ਸਮੀਖਿਆਵਾਂ ਸਬੂਤਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੋ ਸਕਣ।
TSDB ਚੁਣਨਾ ਬ੍ਰੈਂਡ ਨਾਂ ਤੋਂ ਘੱਟ ਅਤੇ ਤੁਹਾਡੇ metrics ਹਕੀਕਤ ਨਾਲ ਮਿਲਾਉਣ 'ਤੇ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਕਿੰਨਾ ਡੇਟਾ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਕਿਵੇਂ ਇਸਨੂੰ ਕ੍ਵੈਰੀ ਕਰਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਡੀ on-call ਟੀਮ ਨੂੰ ਰਾਤ 2 ਵਜੇ ਕੀ ਚਾਹੀਦਾ ਹੈ।
ਉਤਪਾਦਾਂ ਜਾਂ open-source ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਲਿਖੋ:
Managed TSDBs ਰਖ-ਰਖਾਵ ਘਟਾਉਂਦੇ ਹਨ (ਅਪਗਰੇਡ, ਸਕੇਲਿੰਗ, ਬੈਕਅੱਪ), ਅਕਸਰ predictable SLAs ਦੇ ਨਾਲ। ਵਿਰੋਧ ਹੈ ਕਿ ਲਾਗਤ, ਅੰਦਰੂਨੀ ਕੰਟਰੋਲ ਘੱਟ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਦੇ-ਕਦੇ query features ਜਾਂ ਡਾਟਾ egress 'ਤੇ ਪਾਬੰਦੀ ਹੋ ਸਕਦੀ ਹੈ।
Self-hosted TSDBs ਸਕੇਲ 'ਤੇ ਸਸਤੇ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਲਚਕੀਲਾਪਨ ਦਿੰਦੇ ਹਨ, ਪਰ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਲਈ capacity planning, ਟਿਊਨਿੰਗ ਅਤੇ incident response ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਂਦੇ ਹੋ।
ਇੱਕ TSDB ਅਕਸਰ ਇੱਕੱਲਾ ਨਹੀਂ ਹੁੰਦਾ। ਇਹਦੇ ਨਾਲ compatibility ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ:
1–2 ਹਫ਼ਤੇ ਦਾ PoC ਟਾਈਮ-ਬਾਕਸ ਕਰੋ ਅਤੇ pass/fail ਮਾਪਦੰਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
“ਸਰਵੋਤਮ” TSDB ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ cardinality ਅਤੇ query ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੋਵੇ ਜਦੋਂ ਕਿ ਲਾਗਤ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਬੋਝ ਟੀਮ ਲਈ ਮਨਜ਼ੂਰਯੋਗ ਰਹਿੰਦਾ ਹੋਵੇ।
ਇੱਕ TSDB ਨਿਰੀਖਣਯੋਗਤਾ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਮੇਟਰਿਕਸ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ: ਡੈਸ਼ਬੋਰਡ ਲਈ ਤੇਜ਼ ਕੁਐਰੀਜ਼, ਅਲਰਟ ਮੁਲਾਂਕਣ ਲਈ ਭਰੋਸੇਯੋਗ ਨਤੀਜੇ, ਅਤੇ ਬਹੁਤੇ labeled ਡੇਟਾ (ਉੱਚ-ਕਾਰਡੀਨੈਲਿਟੀ ਵਰਕਲੋਡ ਸਮੇਤ) ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਯੋਗਤਾ ਬਿਨਾਂ ਹਰ ਨਵੇਂ label ਨੂੰ ਲਾਗਤ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਦੇ ਧੱਕੇ 'ਚ ਬਦਲਣ ਦੇ।
ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪ੍ਰਗਟੀ ਨਤੀਜੇ ਦਿਖਾਓ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸੇਵਾਵਾਂ ਬਣਾਉਂਦੇ ਅਤੇ ship ਕਰਦੇ ਹੋ, ਤਾਂ observability ਨੂੰ ਡਿਲਿਵਰੀ ਰਾਹ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਨਾ ਫਾਇਦੇਮੰਦ ਹੁੰਦਾ ਹੈ—ਇਹ ਇੱਕ ਬਾਅਦ ਦੀ ਗੱਲ ਨਹੀ ਹੋਣੀ ਚਾਹੀਦੀ। Platforms ਜਿਵੇਂ Koder.ai ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰੈਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ consistent metric naming, ਸਥਿਰ labels, ਅਤੇ ਇੱਕ ਸਟੈਂਡਰਡ ਡੈਸ਼ਬੋਰਡ/ਅਲਰਟ ਬੰਡਲ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਨਵੀਆਂ ਫੀਚਰਾਂ production ਵਿੱਚ "ਡਾਰਕ" ਨਾ ਆਉਣ।
ਇੱਕ ਇਕ-ਪੰਨੇ ਦੀ ਗਾਈਡ ਲਿਖੋ ਜੋ ਆਸਾਨ ਹੋਵੇ:
service_component_metric (ਉਦਾਹਰਨ: checkout_api_request_duration_seconds).ਪਹਿਲਾਂ ਮਾਮਲਿਆਂ ਅਤੇ ਪਿਛੋਕੜ ਜ਼ਰੂਰੀ ਰੁਟ-ਪੇਥ ਅਤੇ background jobs ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ ਕਰੋ, ਫਿਰ ਕਵਰੇਜ ਵਧਾਓ। ਇੱਕ ਵਾਰੀ ਤੁਹਾਡੀਆਂ ਬੇਸਲਾਈਨ ਡੈਸ਼ਬੋਰਡਾਂ ਮੌਜੂਦ ਹੋ ਜਾਣ, ਹਰ ਟੀਮ ਵਿੱਚ ਇੱਕ ਛੋਟੀ “ਨਿਰੀਖਣ ਭੇਟ” ਕਰੋ: ਕੀ ਚਾਰਟ "ਕੀ ਬਦਲਿਆ?" ਅਤੇ "ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੈ?" ਦੇ ਉੱਤਰ ਦਿੰਦੇ ਹਨ? ਜੇ ਨਹੀਂ, ਤਾਂ labels ਨੂੰ ਸੁਧਾਰੋ ਅਤੇ ਕੁਝ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ metrics ਜੋੜੋ, ਨਾ ਕਿ ਬੇਹੁਦਾ ਰੂਪ ਵਿੱਚ ਵਾਲੀਅਮ ਵਧਾਉ।
Metrics ਗਿਣਤੀ ਹਨ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਤੁਹਾਡੀ ਸਿਸਟਮ ਕੀ ਕਰ ਰਹੀ ਹੈ—ਉਹ ਮਾਪ ਜੋ ਤੁਸੀਂ ਚਾਰਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ request latency, error rate, CPU ਵਰਤੋਂ, queue depth, ਜਾਂ active users। Monitoring ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਮੈਟਰਿਕਸ اکਠੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਡੈਸ਼ਬੋਰਡ ਉੱਤੇ ਦਿਖਾਏ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਕੁਝ ਗਲਤ ਲੱਗੇ ਤਾਂ 알ਰਟ ਸੈਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। Observability ਇੱਕ ਕਦਮ ਅੱਗੇ ਹੈ: ਇਹ ਤੁਹਾਡੀ ਯੋਗਤਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਮਝ ਸਕੋ ਕਿਉਂ ਕੁਝ ਹੋ ਰਿਹਾ ਹੈ—ਇਹ ਅਕਸਰ metrics, logs, ਅਤੇ traces ਨੂੰ ਮਿਲਾ ਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮੈਟਰਿਕਸ ਦੱਸਦੇ ਹਨ ਕੀ ਬਦਲਿਆ, ਲੋਗ ਦਿੰਦੇ ਹਨ ਕੀ ਹੋਇਆ, ਅਤੇ ਟ੍ਰੇਸ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿਸ ਸੇਵਾ ਵਿੱਚ ਸਮਾਂ ਖਰਚ ਹੋਇਆ।
ਟਾਈਮ-ਸੀਰੀਜ਼ ਡੇਟਾ ਲਗਾਤਾਰ ਆਉਣ ਵਾਲਾ value + timestamp ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਰੈਂਜ ਸਵਾਲ ਪੁੱਛਦੇ ਹੋ (ਆਖਰੀ 15 ਮਿੰਟ, deploy ਤੋਂ ਪਹਿਲਾਂ/ਬਾਅਦ) ਅਤੇ ਜ਼ਿਆਦਾਤਰ aggregations (avg, p95, rate) 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੇ ਹੋ ਨਾ ਕਿ ਵੱਖ-ਵੱਖ ਰੋਜ਼ਾਂ ਨੂੰ ਖਿੱਚਣ 'ਤੇ। ਇਸ ਕਰਕੇ ਸਟੋਰੇਜ਼ ਲੇ-ਆਉਟ, ਕੰਪ੍ਰੈਸ਼ਨ, ਅਤੇ ਰੈਂਜ-ਸਕੈਨ ਕਾਰਗੁਜ਼ਾਰੀ ਕਾਰੋਬਾਰੀ ਡੇਟਾਬੇਸ ਵਾਲੀ ਵਰਤੋਂ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇੱਕ TSDB ਉਹ ਡੇਟਾਬੇਸ ਹੈ ਜੋ ਮੇਟਰਿਕ ਵਰਕਲੋਡ ਲਈ ਅਨੁਕੂਲਿਤ ਕੀਤਾ ਗਿਆ ਹੈ: ਉੱਚ ਲਿਖਾਈ ਦਰ, ਅਕਸਰ append-only ingestion, ਅਤੇ ਤੇਜ਼ ਟਾਈਮ-ਰੈਂਜ ਕੁਐਰੀਜ਼ ਜੋ ਆਮ ਮਾਨੀਟਰਨਿੰਗ ਫੰਕਸ਼ਨ (bucketing, rollups, rates, percentiles, label group-bys) ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਹ ਬਣਿਆ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕਿ ਜਦੋਂ ਡੇਟਾ ਵੱਧੇ ਤਾਂ ਵੀ ਡੈਸ਼ਬੋਰਡ ਅਤੇ alert ਢਾਂਚੇ ਜਵਾਬਦੇਹ ਰਹਿਣ।
ਇੱਕ TSDB ਖੁਦ-ਭੁੱਲਕੇ ਤੁਹਾਡੇ observability ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। ਇਹ ਮੈਟਰਿਕਸ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਕ્વੇਰੀ ਕਰਨ ਦੀ ਮਕੈਨਿਕਸ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਲੋੜ ਹੈ:
ਇਨ੍ਹਾਂ ਦੇ ਬਗੈਰ, ਤੁਹਾਡੇ ਕੋਲ ਤੇਜ਼ ਡੈਸ਼ਬੋਰਡ ਹੋ ਸਕਦੇ ਹਨ ਪਰ ਜੋ ਕਾਰਵਾਈਯੋਗ ਹੋਣ, ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ।
ਮੇਟਰਿਕਸ ਤੇਜ਼, ਸਸਤੇ ਤਰੀਕੇ ਨਾਲ ਡਿਟੈਕਟ ਕਰਨ ਅਤੇ ਰੁਝਾਨ ਟਰੈਕ ਕਰਨ ਲਈ ਵਧੀਆ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਵਿੱਚ ਡਿਟੇਲ ਘੱਟ ਹੁੰਦੀ ਹੈ। ਰੱਖੋ:
ਮੈਟਰਿਕਸ ਨਾਲ ਪਤਾ ਲਗਾਓ ਅਤੇ ਸੀਮਾ ਤੱਕ ਘਟਾਓ, ਫਿਰ ਡੀਟੇਲ ਲਈ logs/traces ਵਰਤੋ।
Cardinality ਉਹ ਗਿਣਤੀ ਹੈ ਜੋ ਮੈਟਰਿਕਸ ਵਿੱਚ label combinations ਵੱਲੋਂ ਬਣੀ ਯੂਨੀਕ ਟਾਈਮ ਸੀਰੀਜ਼ਾਂ ਦੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਉਦਾਹਰਣ ਵਾਲੀ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ dimensions ਜਿਵੇਂ instance, endpoint, status code ਜਾਂ (ਖ਼ਤਰਨਾਕ) ਅਨਬਾਊਂਡ IDs ਜੋੜਦੇ ਹੋ ਤਾਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਜਾਂਦੀ ਹੈ। ਉੱਚ ਕਾਰਡੀਨੈਲਿਟੀ ਆਮ ਤੌਰ 'ਤੇ ਲੈ ਕੇ ਆਉਂਦੀ ਹੈ:
ਅਕਸਰ ਇਹੀ ਗੱਲ ਪਹਿਲਾਂ ਸਿਸਟਮ ਨੂੰ ਅਸਥਿਰ ਜਾਂ ਮਹਿੰਗਾ ਬਣਾਉਂਦੀ ਹੈ।
ਉਹ labels ਰੱਖੋ ਜੋ ਬਾਊਂਡਡ ਅਤੇ ਥੋੜ੍ਹੀ-ਜਿਆਦਾ ਤਬਦੀਲੀ ਵਾਲੇ ਹੋਣ:
service, , , , ਨਾਰਮਲਾਈਜ਼ਡ (route template)ਰੈਂਟੇਸ਼ਨ ਲਾਗਤ ਅਤੇ ਕੁਐਰੀ ਗਤੀ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਕਰਨ ਲਈ ਹੈ। ਆਮ ਸੈਟਅੱਪ ਏਹ ਹੈ:
ਡਾਉਨਸੈਂਪਲਿੰਗ precision ਘਟਾਂਦੀ ਹੈ ਪਰ ਸਟੋਰੇਜ ਸਸਤਾ ਕਰਦੀ ਹੈ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀਆਂ ਕਵੈਰੀਆਂ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦੀ ਹੈ; min/max ਨਾਲ averages ਰੱਖਣ ਨਾਲ “ਕੁਝ ਹੋਇਆ” ਦਾ ਸਿੱਜਾ ਸੰਕੇਤ ਬਚਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਅਧਿਕਤਰ alert rules ਰੈਂਜ-ਆਧਾਰਿਤ ਅਤੇ aggregation-heavy ਹੁੰਦੇ ਹਨ (thresholds, rates/ratios, anomaly comparisons)। ਜੇ queries ਧੀਮੇ ਹਨ ਜਾਂ ingestion ਦੇਰੀ ਨਾਲ ਆਵੇ, ਤਾਂ ਤੁਹਾਨੂੰ flapping, incidents ਦੇ ਚੂਕ ਜਾਂ ਡਿਲੇਡ ਪੇਜਿੰਗ ਮਿਲ ਸਕਦੀ ਹੈ। ਕਾਰਗਰ ਕਦਮ:
ਛੋਟੇ, ਮਾਪਣਯੋਗ ਕਦਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪ੍ਰਗਟ ਨਤੀਜੇ ਦਿਖਾਓ:
regionclusterenvironmentendpointinstance ਜੇ ਫਲੀਟ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀ ਹੋਵੇਉਹ ਉੱਚ-ਡਿਟੇਲ ਆਈਟਮ ਲੋਗਸ/ਟ੍ਰੇਸੇਸ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਮੈਟਰਿਕ labels ਨੂੰ ਗਰੁੱਪਿੰਗ ਅਤੇ ਟ੍ਰਾਇਐਜ ਲਈ ਰੱਖੋ।
ਇੱਕ ਛੋਟੀ PoC ਜੋ ਅਸਲ ਡੈਟਾ ਅਤੇ ਉੱਚ ਦਬਾਅ ਵਾਲੀਆਂ ਸੀਨੀਰੀਓਜ਼ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ, ਆਮਤੌਰ 'ਤੇ ਫੀਚਰ ਚੈਕਲਿਸਟਾਂ ਨਾਲੋਂ ਵਧੇਰੇ ਮੌલਿਕ ਫਾਇਦਾ ਦਿੰਦੀ ਹੈ।