ಪ್ರಮುಖ ಲಿಂಕ್‌ಗಳು
ಸೇವಾ ಆರೋಗ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ (ಪ್ರಸ್ತುತ Enterprise API ಗ್ರಾಹಕರಿಗೆ ಮಾತ್ರ ಲಭ್ಯ)
ಸರಿಯಾದ ಡೀಫಾಲ್ಟ್‌ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ
ನೀವು ಸೇವಾ ಆರೋಗ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ತೆರೆಯುವಾಗ, ಅದು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಹೀಗಿರುತ್ತದೆ:
ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು
ಕಳೆದ 30 ದಿನಗಳು
ಗಂಟೆಗೊಮ್ಮೆ ರೆಸಲ್ಯೂಷನ್
ಈ ವೀಕ್ಷಣೆ ದಿಕ್ಕು ತಿಳಿದುಕೊಳ್ಳಲು ಮಾತ್ರ ಉಪಯುಕ್ತವಾಗಿದೆ. ಅರ್ಥಪೂರ್ಣ ಸಮಸ್ಯೆ ನಿವಾರಣೆಗೆ ಯಾವಾಗಲೂ ಫಿಲ್ಟರಿಂಗ್ ಅಗತ್ಯವಿದೆ.
ತನಿಖೆಗೆ ಮೊದಲು ಫಿಲ್ಟರ್ ಮಾಡಿ
ಸರಿಯಾದ ಫಿಲ್ಟರಿಂಗ್ ಅತ್ಯಂತ ಮುಖ್ಯ ಹಂತವಾಗಿದೆ. ಹೆಚ್ಚಿನ ತಪ್ಪು ವ್ಯಾಖ್ಯಾನಗಳು ಮಾಡೆಲ್‌ಗಳು, ಟಿಯರ್‌ಗಳು ಅಥವಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಮಿಶ್ರಣ ಮಾಡುವುದರಿಂದ ಬರುತ್ತವೆ.
ಮಾಡೆಲ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ (ಒಂದೊಂದಾಗಿ)
ಯಾವಾಗಲೂ ಒಂದೇ ಮಾಡೆಲ್‌ಗೆ ಫಿಲ್ಟರ್ ಮಾಡಿ.
ಏಕೆ:
ಕಡಿಮೆ ಟ್ರಾಫಿಕ್ ಇರುವ ಮಾಡೆಲ್‌ಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಗಳು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಮರೆಮಾಡಲ್ಪಡಬಹುದು
ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಮಾಡೆಲ್‌ಗಳು ಸ್ಥಳೀಯ ಸಮಸ್ಯೆಗಳು ಜಾಗತಿಕವಾಗಿರುವಂತೆ ಕಾಣಿಸಬಹುದು
ವಿಭಿನ್ನ ಮಾಡೆಲ್‌ಗಳಿಗೆ ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ಷಮತಾ ಗುರಿಗಳಿರುತ್ತವೆ
ಗಮನಿಸಿ: ಅನೇಕ ಮಾಡೆಲ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದರಿಂದ ಅವು ಒಟ್ಟುಗೂಡುತ್ತವೆ—ಅವುಗಳ ನಡುವೆ ಬದಲಾಯಿಸುವುದಿಲ್ಲ.
ಸೇವಾ ಹಂತದ (ಟಿಯರ್) ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ
ನೀವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಟಿಯರ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ (ಸ್ಟ್ಯಾಂಡರ್ಡ್, ಫಾಸ್ಟ್ ಮೋಡ್ (ಹಿಂದೆ ಆದ್ಯತಾ ಪ್ರಕ್ರಿಯೆ), ಸ್ಕೇಲ್ ಟಿಯರ್), ನೀವು ಪರಿಶೀಲಿಸುತ್ತಿರುವ ಟಿಯರ್‌ಗೆ ಯಾವಾಗಲೂ ಫಿಲ್ಟರ್ ಮಾಡಿ.
ಕಾರಣ:
ಟಿಯರ್‌ಗಳು ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ಷಮತಾ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿವೆ.
ಫಾಸ್ಟ್ ಮೋಡ್ ಮತ್ತು ಸ್ಕೇಲ್ ಟಿಯರ್ ನಿರ್ದಿಷ್ಟ SLAಗಳನ್ನು ಹೊಂದಿವೆ.
ಟಿಯರ್‌ಗಳನ್ನು ಬೆರೆಸುವುದರಿಂದ ಪಾವತಿಸಿದ ಟಿಯರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣಿಸುವುದಿಲ್ಲ.
ವಿಳಂಬದ ವಿಶ್ಲೇಷಣೆಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ.
ಈಗಾಗಲೇ ಇರುವ ಮಾಡೆಲ್‌ಗಳಿಗೆ, ಫಾಸ್ಟ್ ಮೋಡ್‌ನ ಟ್ರಾಫಿಕ್ ಬಳಕೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಇನ್ನೂ ಆದ್ಯತೆಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ.
ಪ್ರಾಜೆಕ್ಟ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ
ಡೀಫಾಲ್ಟ್ ಆಗಿ, ಸೇವಾ ಆರೋಗ್ಯವು ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.
ಸಮಸ್ಯೆ ನಿವಾರಣೆಗೆ, ಸಮಸ್ಯೆ ಗಮನಿಸಿದ ಪ್ರಾಜೆಕ್ಟ್(ಗಳು)ಗೆ ಫಿಲ್ಟರ್ ಮಾಡಿ.
ಏಕೆ:
ಒಂದು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಪ್ರಾಜೆಕ್ಟ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಆಳಬಹುದು.
ಸಣ್ಣ ಪರಿಣಾಮಿತ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಸಂಬಂಧರಹಿತ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಮರೆಮಾಡಲ್ಪಡಬಹುದು.
ಸಮಸ್ಯೆ ನಿಜವಾಗಿಯೂ ಸಂಸ್ಥೆ-ವ್ಯಾಪಿಯಾಗಿದೆ ಎಂದು ನೀವು ನಂಬಿದರೆ ಮಾತ್ರ “ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು” ಆಯ್ಕೆಯಾಗಿ ಬಿಡಿ.
ದೋಷಗಳ ನಿವಾರಣೆ
HTTP ವಿನಂತಿಗಳ ವೀಕ್ಷಣೆಯನ್ನು ಬಳಸಿ
ದೋಷಗಳನ್ನು ತನಿಖೆ ಮಾಡಲು:
ಮಾಡೆಲ್ ಮತ್ತು ಸೇವಾ ಹಂತದ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ.
Uptime ಟ್ಯಾಬ್ ಬದಲಿಗೆ HTTP Requests ಟ್ಯಾಬ್ ತೆರೆಯಿರಿ.
ಈ ವೀಕ್ಷಣೆ HTTP ಸ್ಥಿತಿ ಕೋಡ್ ಪ್ರಕಾರ ಒಟ್ಟು ವಿನಂತಿಗಳು ಮತ್ತು ದೋಷ ಎಣಿಕೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಸೂಕ್ಷ್ಮ ಏರಿಕೆಗಳು ಅಥವಾ ಬದಲಾವಣೆಗಳನ್ನು ಗುರುತಿಸಲು ನಿಮಿಷ-ಮಟ್ಟದ ರೆಸಲ್ಯೂಷನ್‌ಗೆ ಜೂಮ್ ಮಾಡಿ.
ಎಣಿಕೆಗಳಲ್ಲ, ದೋಷ ದರಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ
ಯಾವುದೇ ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಕೆಲವು ದೋಷಗಳು ನಿರೀಕ್ಷಿತವಾಗಿರುತ್ತವೆ. ಕಚ್ಚಾ ಒಟ್ಟುಗಳಲ್ಲ, ದೋಷದ ಶೇಕಡಾವಾರು ಮೇಲೆ ಗಮನ ಕೊಡಿ.
ನಿಮ್ಮ ಒಟ್ಟು ಪ್ರಮಾಣ ಹೆಚ್ಚಾದಂತೆ, ಅತ್ಯಂತ ಕಡಿಮೆ ದೋಷ ದರದಲ್ಲಿಯೂ ಸಂಭವನೀಯ ದೋಷಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾಗುತ್ತದೆ.
ಸೇವಾ ಆರೋಗ್ಯದಲ್ಲಿ ದೋಷಗಳು ಕಾಣಿಸದಿದ್ದಾಗ
ನಿಮಗೆ ಕ್ಲೈಂಟ್-ಸೈಡ್ ದೋಷಗಳು ಕಾಣಿಸಿದರೂ ಸೇವಾ ಆರೋಗ್ಯದಲ್ಲಿ ಸಂಬಂಧಿತ ಡೇಟಾ ಇಲ್ಲದಿದ್ದರೆ:
ವಿನಂತಿಗಳು ಬಹುಶಃ OpenAI ತಲುಪಿಲ್ಲ.
ಸಮಸ್ಯೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿರುತ್ತದೆ (ಟೈಮ್‌ಔಟ್‌ಗಳು, ಪ್ರಾಕ್ಸಿಗಳು, ನೆಟ್‌ವರ್ಕಿಂಗ್).
ಆಕ್ರಮಣಕಾರಿ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಟೈಮ್‌ಔಟ್‌ಗಳೊಂದಿಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ.
ವಿಳಂಬದ ಸಮಸ್ಯೆ ನಿವಾರಣೆ
ನಿರ್ದಿಷ್ಟ SLAಗಳನ್ನು ಹೊಂದಿರುವ ಫಾಸ್ಟ್ ಮೋಡ್ ಮತ್ತು ಸ್ಕೇಲ್ ಟಿಯರ್ ಟಿಯರ್‌ಗಳಲ್ಲಿ ವಿಳಂಬದ ವಿಶ್ಲೇಷಣೆ ಹೆಚ್ಚು ಅರ್ಥಪೂರ್ಣವಾಗಿರುತ್ತದೆ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟಿಯರ್‌ನಲ್ಲಿ ವಿಳಂಬವು ಹೆಚ್ಚು ವ್ಯಾಪಕವಾಗಿ ಬದಲಾಗಬಹುದು ಮತ್ತು ಅದಕ್ಕೆ ಖಾತರಿಪಡಿಸಿದ ವಿಳಂಬದ ಮಿತಿಯಿಲ್ಲ.
ಮುಖ್ಯ ಮೆಟ್ರಿಕ್‌ಗಳು
ಪ್ರತಿ ಮೆಟ್ರಿಕ್ ನೋಡಲು, ಸಂಬಂಧಿತ ಟ್ಯಾಬ್ ಕ್ಲಿಕ್ ಮಾಡಿ:
ಟೋಕನ್ ವೇಗ: ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಜನರೇಟ್ ಆಗುವ ಟೋಕನ್‌ಗಳು; ಪ್ರಾಂಪ್ಟ್ ಗಾತ್ರದಿಂದ ಸ್ವತಂತ್ರ.
ವಿನಂತಿ ಸಮಯ: ಒಟ್ಟು ವಿನಂತಿ ಅವಧಿ; ಔಟ್‌ಪುಟ್ ಗಾತ್ರ ಮತ್ತು ರೀಜನಿಂಗ್‌ನಿಂದ ಬಹಳವಾಗಿ ಪರಿಣಾಮಿತವಾಗುತ್ತದೆ.
ಮೊದಲ ಟೋಕನ್‌ಗೆ ಬೇಕಾದ ಸಮಯ (TTFT): ಮೊದಲ ಟೋಕನ್ ಜನರೇಟ್ ಆಗುವವರೆಗಿನ ಸಮಯ; ಕ್ಯಾಶ್ ಮಾಡದ ಇನ್‌ಪುಟ್ ಪ್ರಾಂಪ್ಟ್ ಗಾತ್ರ ಮತ್ತು ರೀಜನಿಂಗ್‌ನಿಂದ ಬಹಳವಾಗಿ ಪರಿಣಾಮಿತವಾಗುತ್ತದೆ.
ಯಾವಾಗಲೂ P50 / P75 / P95 ಪರ್ಸೆಂಟೈಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಸರಾಸರಿಗಳು ನಿಜವಾದ ಬಳಕೆದಾರರ ಪರಿಣಾಮವನ್ನು ಮರೆಮಾಡಬಹುದು.
ವಿಳಂಬ ಮತ್ತು ಟೋಕನ್ ಬಳಕೆಯ ನಡುವಿನ ಸಂಬಂಧ ತಿಳಿಯುವುದು
ಸೇವಾ ಸ್ಥಿತಿಯ ನೋಟವು ಕಾರ್ಯವೈಖರಿ ಯಾವಾಗ ಬದಲಾಯಿತು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಬಳಕೆಯ ಡೇಟಾವು ಏಕೆ ಬದಲಾಯಿತು ಎಂಬುದನ್ನು ವಿವರಿಸಲು ನೆರವಾಗುತ್ತದೆ.
ಸೇವಾ ಸ್ಥಿತಿಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ನೀವು ನೋಡುತ್ತಿರುವ ನೋಟಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಡೇಟಾವನ್ನೇ ಪರಿಶೀಲಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಬಳಕೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಈ ಕೆಳಗಿನ ಕ್ರಮಗಳನ್ನು ಅನುಸರಿಸಿ:
ಅದೇ ಯೋಜನೆ ಮತ್ತು ಮಾಡೆಲ್‌ಗೆ ಫಿಲ್ಟರ್ ಮಾಡಿ.
ಅನ್ವಯವಾಗುವಲ್ಲಿ, ಸೇವಾ ಹಂತ (ಟೈರ್) ಆಧರಿಸಿ ಗುಂಪು ಮಾಡಿ.
ವಿಳಂಬದ ಮೇಲೆ ಅತಿ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುವ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ಮೇಲೆ ಗಮನ ಕೇಂದ್ರೀಕರಿಸಿ.
ಇನ್ನಷ್ಟು ಆಳವಾದ ವಿಶ್ಲೇಷಣೆಗಾಗಿ, ಚಟುವಟಿಕೆ ಡೇಟಾವನ್ನು ರಫ್ತು ಮಾಡಿ ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ಪ್ರತಿ ವಿನಂತಿಯ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆ ಹೇಗೆ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
ಬೆಂಬಲ ತಂಡದೊಂದಿಗೆ ಏನನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕು (ಅಗತ್ಯವಿದ್ದರೆ)
ನೀವು ಬೆಂಬಲ ತಂಡವನ್ನು ಸಂಪರ್ಕಿಸಿದರೆ, ಇವುಗಳನ್ನು ಸೇರಿಸಿ:
ಪರಿಣಾಮಕ್ಕೊಳಗಾದ ಸಂಸ್ಥೆಗಳ ಗುರುತುಗಳು (ಮುಖ್ಯ)
Chat Completions ಅಥವಾ Responses ನಂತಹ ಪರಿಣಾಮಕ್ಕೊಳಗಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು (ಮುಖ್ಯ)
ಪರಿಣಾಮಕ್ಕೊಳಗಾದ ಮಾಡೆಲ್‌ಗಳು (ಮುಖ್ಯ)
ಇದು ಫಾಸ್ಟ್ ಮೋಡ್‌ನಲ್ಲಿದೆಯೇ ಅಥವಾ ಸ್ಕೇಲ್ ಟಿಯರ್‌ನಲ್ಲಿದೆಯೇ ಎಂಬ ಮಾಹಿತಿ (ಮುಖ್ಯ)
ವಿಳಂಬ ಅಥವಾ ದೋಷಗಳು ಕಂಡುಬಂದ ಸಮಯದ ಅವಧಿಗಳು ಮತ್ತು ಸಮಯ ವಲಯ (ಮುಖ್ಯ)
ಲಭ್ಯವಿದ್ದರೆ, ಸಂಬಂಧಿತ x-request-id ಅಥವಾ X-Client-Request-Id
ನೀವು ಒದಗಿಸುವ ವಿನಂತಿಗಳ ಸಮಯಮುದ್ರೆಗಳು ಮತ್ತು ಸಮಯ ವಲಯ, ಅಥವಾ ಕನಿಷ್ಠ ದಿನಾಂಕ
ಲಭ್ಯವಿದ್ದರೆ, ಇವುಗಳನ್ನೂ ಸೇರಿಸಿ:
ವಿನಂತಿಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಯೋಜನೆಯ ಗುರುತು
ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ ವಿನಂತಿಗಳು ಪರಿಣಾಮಕ್ಕೊಳಗಾಗಿವೆಯೇ, ಹಾಗಿದ್ದರೆ ಯಾವುವು ಎಂಬ ಮಾಹಿತಿ
ನೀವು ಗಮನಿಸುತ್ತಿರುವ ಪ್ರವೃತ್ತಿಗಳ ವಿವರಣೆಗಳು
ಸಮಸ್ಯೆಯ ಪ್ರಕಾರಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಇವುಗಳನ್ನು ಸೇರಿಸಿ:
ದೋಷಗಳು: ವಿಫಲವಾಗುತ್ತಿರುವ ಅಥವಾ ದೋಷಗಳನ್ನು ನೀಡುತ್ತಿರುವ ವಿನಂತಿಗಳ ಅಂದಾಜು ಶೇಕಡಾವಾರು, ಪ್ರತಿಕ್ರಿಯೆ ಸಂಕೇತಗಳು, ದೋಷ ಸಂದೇಶಗಳು ಮತ್ತು ದೋಷದ ಪ್ರತಿಕ್ರಿಯೆ ಬರಲು ತೆಗೆದುಕೊಂಡ ಸಮಯ.
ವಿಳಂಬ: ಯಾವ ಶತಕಾಂಶಕಗಳು ಪರಿಣಾಮಕ್ಕೊಳಗಾಗಿವೆ (P50 / P90 / P95 / P99), ಗ್ರಾಹಕರ ಮೂಲಮಟ್ಟಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಅವು ಎಷ್ಟು ಹೆಚ್ಚಿವೆ, ಹಾಗೂ ನಿಧಾನವಾದ ವಿನಂತಿಗಳ ಉದಾಹರಣೆಗಳ ಜೊತೆಗೆ ಅವನ್ನು ಕಳುಹಿಸಿದ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಸ್ವೀಕರಿಸಿದ ಸಮಯಮುದ್ರೆಗಳು.
ಎರಡೂ: ದೋಷ ಅಥವಾ ವಿಳಂಬದ ಡೇಟಾದ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳು ಅಥವಾ ಕೋಷ್ಟಕ, ಜೊತೆಗೆ ದೋಷದ ದರಗಳು ಅಥವಾ ವಿಳಂಬವು ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚಾಗಿತ್ತು ಎಂದು ನೀವು ಹೇಗೆ ನಿರ್ಧರಿಸಿದಿರಿ ಎಂಬ ವಿವರ.
ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆ ನಿವಾರಣೆ ಸನ್ನಿವೇಶಗಳು
ಟೈಮ್‌ಔಟ್‌ಗಳು ಸಂಭವಿಸಿದರೂ ಸೇವಾ ಆರೋಗ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣುತ್ತದೆ
ಸಂಭಾವ್ಯ ಕಾರಣ: ವಿನಂತಿಗಳು OpenAI ತಲುಪುವ ಮೊದಲು ಟೈಮ್‌ಔಟ್ ಆಗುತ್ತಿವೆ.
ಪರಿಶೀಲಿಸಿ:
ಕ್ಲೈಂಟ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಟೈಮ್‌ಔಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು
ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಅಥವಾ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಬದಲಾವಣೆಗಳು
ಸೇವಾ ಆರೋಗ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ 499 ದೋಷಗಳಿರುವಿಕೆ (ಇವು ನಿಮ್ಮ ಸ್ವಂತ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ 5xx ದೋಷಗಳಾಗಿ ಕಾಣಿಸಬಹುದು).
ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್ ಇಲ್ಲದೆ ಲೇಟೆನ್ಸಿ ಹೆಚ್ಚಾಗಿದೆ
ಸಂಭಾವ್ಯ ಕಾರಣ: ಔಟ್‌ಪುಟ್ ಟೋಕನ್ ಗಾತ್ರ ಅಥವಾ ರೀಜನಿಂಗ್ ಬಳಕೆ ಹೆಚ್ಚಾಗಿದೆ ಮತ್ತು/ಅಥವಾ ಟ್ರಾಫಿಕ್ ಸೇವಾ ಹಂತಗಳ ನಡುವೆ ಬದಲಾಗಿದೆ.
ಪರಿಶೀಲಿಸಿ:
ಬಳಕೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಪ್ರತಿ ವಿನಂತಿಗೆ ಸರಾಸರಿ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು (ಡೇಟಾವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ, ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳನ್ನು ಒಟ್ಟು ವಿನಂತಿಗಳಿಂದ ಭಾಗಿಸುವುದು ಅಗತ್ಯ).
ಸೇವಾ ಆರೋಗ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ Request Time ಮತ್ತು TTFT ಪರ್ಸೆಂಟೈಲ್‌ಗಳು.
ಫಾಸ್ಟ್ ಮೋಡ್ ಅಥವಾ ಸ್ಕೇಲ್ ಟಿಯರ್ ನಿಧಾನವಾಗಿ ಕಾಣಿಸುತ್ತದೆ
ಸಂಭಾವ್ಯ ಕಾರಣ: ವಿವಿಧ ಟಿಯರ್‌ಗಳ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಿರುವುದರಿಂದ, ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟಿಯರ್‌ನ ಟ್ರಾಫಿಕ್ ಪಾವತಿಸಿದ ಟಿಯರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮರೆಮಾಡುತ್ತಿದೆ.
ಪರಿಶೀಲಿಸಿ:
ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಒಂದೇ ಟಿಯರ್ ಮತ್ತು ಮಾಡೆಲ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಲಾಗಿದೆ.
ಟಿಯರ್‌ಗಳ ನಡುವಿನ ಟೋಕನ್ ವೇಗದ ಹೋಲಿಕೆ.
5XX ದೋಷಗಳಲ್ಲಿ ಏರಿಕೆ
ಸಂಭಾವ್ಯ ಕಾರಣ: ಟ್ರಾಫಿಕ್‌ನ ಸಣ್ಣ ಶೇಕಡಾವಾರನ್ನು ಪರಿಣಾಮಿಸುವ ತಾತ್ಕಾಲಿಕ ವೈಫಲ್ಯಗಳು.
ಪರಿಶೀಲಿಸಿ:
ದೋಷ ದರದ ಶೇಕಡಾವಾರು
ಅದೇ ಸಮಯದಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಪ್ರಮಾಣ ಬದಲಾಗಿದೆಯೇ ಎಂಬುದು
ಸಮಸ್ಯೆ ಕೇವಲ ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ
ಸಂಭಾವ್ಯ ಕಾರಣ: ಪ್ರಾಜೆಕ್ಟ್-ನಿರ್ದಿಷ್ಟ ಕಾನ್ಫಿಗರೇಶನ್ ಅಥವಾ ಬಳಕೆ ಮಾದರಿ.
ಪರಿಶೀಲಿಸಿ:
ಪ್ರಾಜೆಕ್ಟ್-ಮಟ್ಟದ ಫಿಲ್ಟರಿಂಗ್
ಪರಿಣಾಮಿತರಾಗದ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಕೆ
ಅಂತಿಮ ಮುಖ್ಯಾಂಶಗಳು
ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಮೊದಲು, ಸಂಬಂಧಿತವಾಗಿರುವಲ್ಲಿ ಮಾಡೆಲ್, ಟಿಯರ್ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ.
ಲೇಟೆನ್ಸಿ ವಿಶ್ಲೇಷಣೆಗೆ ಸರಾಸರಿಗಳ ಬದಲು ಪರ್ಸೆಂಟೈಲ್‌ಗಳನ್ನು ಬಳಸಿ.
ಸಣ್ಣ ದೋಷ ದರಗಳು ನಿರೀಕ್ಷಿತವಾಗಿರುತ್ತವೆ.
ಡೇಟಾ ಕಾಣೆಯಾಗಿರುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸಮಸ್ಯೆಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಬಳಕೆ ಡೇಟಾ ಲೇಟೆನ್ಸಿ ಏಕೆ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಸಹಾಯ ಮಾಡಬಹುದು; ಸೇವಾ ಆರೋಗ್ಯವು ವರ್ತನೆ ಯಾವಾಗ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.