OpenAI
ಈ ಪುಟವನ್ನು ಯಂತ್ರದ ಮೂಲಕ ಅನುವಾದಿಸಲಾಗಿದೆ. ಮೂಲ ಇಂಗ್ಲಿಷ್ ಲೇಖನವನ್ನು ನೋಡಿ.

API ದೋಷಗಳು ಮತ್ತು ವಿಳಂಬದ ಸಮಸ್ಯಾನಿರಾಕರಣೆ

OpenAI API ಬಳಸುವಾಗ ಸಾಮಾನ್ಯ ದೋಷಗಳು ಮತ್ತು ವಿಳಂಬ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು Service Health ಮತ್ತು Usage ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದನ್ನು ಈ ಲೇಖನ ವಿವರಿಸುತ್ತದೆ.

ನವೀಕರಿಸಲಾಗಿದೆ: yesterday

ಪ್ರಮುಖ ಲಿಂಕ್‌ಗಳು

ಸರಿಯಾದ ಡೀಫಾಲ್ಟ್‌ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ

ನೀವು ಸೇವಾ ಆರೋಗ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ತೆರೆಯುವಾಗ, ಅದು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಹೀಗಿರುತ್ತದೆ:

  • ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು

  • ಕಳೆದ 30 ದಿನಗಳು

  • ಗಂಟೆಗೊಮ್ಮೆ ರೆಸಲ್ಯೂಷನ್

ಈ ವೀಕ್ಷಣೆ ದಿಕ್ಕು ತಿಳಿದುಕೊಳ್ಳಲು ಮಾತ್ರ ಉಪಯುಕ್ತವಾಗಿದೆ. ಅರ್ಥಪೂರ್ಣ ಸಮಸ್ಯೆ ನಿವಾರಣೆಗೆ ಯಾವಾಗಲೂ ಫಿಲ್ಟರಿಂಗ್ ಅಗತ್ಯವಿದೆ.

ತನಿಖೆಗೆ ಮೊದಲು ಫಿಲ್ಟರ್ ಮಾಡಿ

ಸರಿಯಾದ ಫಿಲ್ಟರಿಂಗ್ ಅತ್ಯಂತ ಮುಖ್ಯ ಹಂತವಾಗಿದೆ. ಹೆಚ್ಚಿನ ತಪ್ಪು ವ್ಯಾಖ್ಯಾನಗಳು ಮಾಡೆಲ್‌ಗಳು, ಟಿಯರ್‌ಗಳು ಅಥವಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಮಿಶ್ರಣ ಮಾಡುವುದರಿಂದ ಬರುತ್ತವೆ.

ಮಾಡೆಲ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ (ಒಂದೊಂದಾಗಿ)

ಯಾವಾಗಲೂ ಒಂದೇ ಮಾಡೆಲ್‌ಗೆ ಫಿಲ್ಟರ್ ಮಾಡಿ.

ಏಕೆ:

  • ಕಡಿಮೆ ಟ್ರಾಫಿಕ್ ಇರುವ ಮಾಡೆಲ್‌ಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಗಳು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಮರೆಮಾಡಲ್ಪಡಬಹುದು

  • ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಮಾಡೆಲ್‌ಗಳು ಸ್ಥಳೀಯ ಸಮಸ್ಯೆಗಳು ಜಾಗತಿಕವಾಗಿರುವಂತೆ ಕಾಣಿಸಬಹುದು

  • ವಿಭಿನ್ನ ಮಾಡೆಲ್‌ಗಳಿಗೆ ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ಷಮತಾ ಗುರಿಗಳಿರುತ್ತವೆ

ಗಮನಿಸಿ: ಅನೇಕ ಮಾಡೆಲ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದರಿಂದ ಅವು ಒಟ್ಟುಗೂಡುತ್ತವೆ—ಅವುಗಳ ನಡುವೆ ಬದಲಾಯಿಸುವುದಿಲ್ಲ.

ಸೇವಾ ಹಂತದ (ಟಿಯರ್) ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ

ನೀವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಟಿಯರ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ (ಸ್ಟ್ಯಾಂಡರ್ಡ್, ಫಾಸ್ಟ್ ಮೋಡ್ (ಹಿಂದೆ ಆದ್ಯತಾ ಪ್ರಕ್ರಿಯೆ), ಸ್ಕೇಲ್ ಟಿಯರ್), ನೀವು ಪರಿಶೀಲಿಸುತ್ತಿರುವ ಟಿಯರ್‌ಗೆ ಯಾವಾಗಲೂ ಫಿಲ್ಟರ್ ಮಾಡಿ.

ಕಾರಣ:

  • ಟಿಯರ್‌ಗಳು ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ಷಮತಾ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿವೆ.

  • ಫಾಸ್ಟ್ ಮೋಡ್ ಮತ್ತು ಸ್ಕೇಲ್ ಟಿಯರ್ ನಿರ್ದಿಷ್ಟ SLAಗಳನ್ನು ಹೊಂದಿವೆ.

  • ಟಿಯರ್‌ಗಳನ್ನು ಬೆರೆಸುವುದರಿಂದ ಪಾವತಿಸಿದ ಟಿಯರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣಿಸುವುದಿಲ್ಲ.

ವಿಳಂಬದ ವಿಶ್ಲೇಷಣೆಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ.

ಈಗಾಗಲೇ ಇರುವ ಮಾಡೆಲ್‌ಗಳಿಗೆ, ಫಾಸ್ಟ್ ಮೋಡ್‌ನ ಟ್ರಾಫಿಕ್ ಬಳಕೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಇನ್ನೂ ಆದ್ಯತೆಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಪ್ರಾಜೆಕ್ಟ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ

ಡೀಫಾಲ್ಟ್ ಆಗಿ, ಸೇವಾ ಆರೋಗ್ಯವು ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.

ಸಮಸ್ಯೆ ನಿವಾರಣೆಗೆ, ಸಮಸ್ಯೆ ಗಮನಿಸಿದ ಪ್ರಾಜೆಕ್ಟ್(ಗಳು)ಗೆ ಫಿಲ್ಟರ್ ಮಾಡಿ.

ಏಕೆ:

  • ಒಂದು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಪ್ರಾಜೆಕ್ಟ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಆಳಬಹುದು.

  • ಸಣ್ಣ ಪರಿಣಾಮಿತ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಸಂಬಂಧರಹಿತ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಮರೆಮಾಡಲ್ಪಡಬಹುದು.

ಸಮಸ್ಯೆ ನಿಜವಾಗಿಯೂ ಸಂಸ್ಥೆ-ವ್ಯಾಪಿಯಾಗಿದೆ ಎಂದು ನೀವು ನಂಬಿದರೆ ಮಾತ್ರ “ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು” ಆಯ್ಕೆಯಾಗಿ ಬಿಡಿ.

ದೋಷಗಳ ನಿವಾರಣೆ

HTTP ವಿನಂತಿಗಳ ವೀಕ್ಷಣೆಯನ್ನು ಬಳಸಿ

ದೋಷಗಳನ್ನು ತನಿಖೆ ಮಾಡಲು:

  1. ಮಾಡೆಲ್ ಮತ್ತು ಸೇವಾ ಹಂತದ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ.

  2. Uptime ಟ್ಯಾಬ್ ಬದಲಿಗೆ HTTP Requests ಟ್ಯಾಬ್ ತೆರೆಯಿರಿ.

ಈ ವೀಕ್ಷಣೆ HTTP ಸ್ಥಿತಿ ಕೋಡ್ ಪ್ರಕಾರ ಒಟ್ಟು ವಿನಂತಿಗಳು ಮತ್ತು ದೋಷ ಎಣಿಕೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಸೂಕ್ಷ್ಮ ಏರಿಕೆಗಳು ಅಥವಾ ಬದಲಾವಣೆಗಳನ್ನು ಗುರುತಿಸಲು ನಿಮಿಷ-ಮಟ್ಟದ ರೆಸಲ್ಯೂಷನ್‌ಗೆ ಜೂಮ್ ಮಾಡಿ.

ಎಣಿಕೆಗಳಲ್ಲ, ದೋಷ ದರಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ

ಯಾವುದೇ ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಕೆಲವು ದೋಷಗಳು ನಿರೀಕ್ಷಿತವಾಗಿರುತ್ತವೆ. ಕಚ್ಚಾ ಒಟ್ಟುಗಳಲ್ಲ, ದೋಷದ ಶೇಕಡಾವಾರು ಮೇಲೆ ಗಮನ ಕೊಡಿ.

ನಿಮ್ಮ ಒಟ್ಟು ಪ್ರಮಾಣ ಹೆಚ್ಚಾದಂತೆ, ಅತ್ಯಂತ ಕಡಿಮೆ ದೋಷ ದರದಲ್ಲಿಯೂ ಸಂಭವನೀಯ ದೋಷಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾಗುತ್ತದೆ.

ಸೇವಾ ಆರೋಗ್ಯದಲ್ಲಿ ದೋಷಗಳು ಕಾಣಿಸದಿದ್ದಾಗ

ನಿಮಗೆ ಕ್ಲೈಂಟ್-ಸೈಡ್ ದೋಷಗಳು ಕಾಣಿಸಿದರೂ ಸೇವಾ ಆರೋಗ್ಯದಲ್ಲಿ ಸಂಬಂಧಿತ ಡೇಟಾ ಇಲ್ಲದಿದ್ದರೆ:

  • ವಿನಂತಿಗಳು ಬಹುಶಃ OpenAI ತಲುಪಿಲ್ಲ.

  • ಸಮಸ್ಯೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿರುತ್ತದೆ (ಟೈಮ್‌ಔಟ್‌ಗಳು, ಪ್ರಾಕ್ಸಿಗಳು, ನೆಟ್‌ವರ್ಕಿಂಗ್).

ಆಕ್ರಮಣಕಾರಿ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಟೈಮ್‌ಔಟ್‌ಗಳೊಂದಿಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ.

ವಿಳಂಬದ ಸಮಸ್ಯೆ ನಿವಾರಣೆ

ನಿರ್ದಿಷ್ಟ SLAಗಳನ್ನು ಹೊಂದಿರುವ ಫಾಸ್ಟ್ ಮೋಡ್ ಮತ್ತು ಸ್ಕೇಲ್ ಟಿಯರ್ ಟಿಯರ್‌ಗಳಲ್ಲಿ ವಿಳಂಬದ ವಿಶ್ಲೇಷಣೆ ಹೆಚ್ಚು ಅರ್ಥಪೂರ್ಣವಾಗಿರುತ್ತದೆ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟಿಯರ್‌ನಲ್ಲಿ ವಿಳಂಬವು ಹೆಚ್ಚು ವ್ಯಾಪಕವಾಗಿ ಬದಲಾಗಬಹುದು ಮತ್ತು ಅದಕ್ಕೆ ಖಾತರಿಪಡಿಸಿದ ವಿಳಂಬದ ಮಿತಿಯಿಲ್ಲ.

ಮುಖ್ಯ ಮೆಟ್ರಿಕ್‌ಗಳು

ಪ್ರತಿ ಮೆಟ್ರಿಕ್ ನೋಡಲು, ಸಂಬಂಧಿತ ಟ್ಯಾಬ್ ಕ್ಲಿಕ್ ಮಾಡಿ:

  • ಟೋಕನ್ ವೇಗ: ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಜನರೇಟ್ ಆಗುವ ಟೋಕನ್‌ಗಳು; ಪ್ರಾಂಪ್ಟ್ ಗಾತ್ರದಿಂದ ಸ್ವತಂತ್ರ.

  • ವಿನಂತಿ ಸಮಯ: ಒಟ್ಟು ವಿನಂತಿ ಅವಧಿ; ಔಟ್‌ಪುಟ್ ಗಾತ್ರ ಮತ್ತು ರೀಜನಿಂಗ್‌ನಿಂದ ಬಹಳವಾಗಿ ಪರಿಣಾಮಿತವಾಗುತ್ತದೆ.

  • ಮೊದಲ ಟೋಕನ್‌ಗೆ ಬೇಕಾದ ಸಮಯ (TTFT): ಮೊದಲ ಟೋಕನ್ ಜನರೇಟ್ ಆಗುವವರೆಗಿನ ಸಮಯ; ಕ್ಯಾಶ್ ಮಾಡದ ಇನ್‌ಪುಟ್ ಪ್ರಾಂಪ್ಟ್ ಗಾತ್ರ ಮತ್ತು ರೀಜನಿಂಗ್‌ನಿಂದ ಬಹಳವಾಗಿ ಪರಿಣಾಮಿತವಾಗುತ್ತದೆ.

ಯಾವಾಗಲೂ P50 / P75 / P95 ಪರ್ಸೆಂಟೈಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಸರಾಸರಿಗಳು ನಿಜವಾದ ಬಳಕೆದಾರರ ಪರಿಣಾಮವನ್ನು ಮರೆಮಾಡಬಹುದು.

6. ಲೇಟೆನ್ಸಿಯನ್ನು ಟೋಕನ್ ಬಳಕೆಯೊಂದಿಗೆ ಸಂಬಂಧಿಸುವುದು

ಸೇವಾ ಆರೋಗ್ಯವು ವರ್ತನೆ ಯಾವಾಗ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಬಳಕೆ ಡೇಟಾ ಏಕೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಬಳಕೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ, ಸೇವಾ ಆರೋಗ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿನ ನಿಮ್ಮ ವೀಕ್ಷಣೆಗೆ ಸಂಬಂಧಿಸಿದ ಡೇಟಾವನ್ನೇ ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡಿ:

  • ಅದೇ ಪ್ರಾಜೆಕ್ಟ್ ಮತ್ತು ಮಾಡೆಲ್‌ಗೆ ಫಿಲ್ಟರ್ ಮಾಡಿ.

  • ಅನ್ವಯಿಸಿದರೆ, ಸೇವಾ ಹಂತದ ಪ್ರಕಾರ ಗುಂಪುಗೊಳಿಸಿ.

  • ಲೇಟೆನ್ಸಿಯನ್ನು ಅತ್ಯಂತ ಬಲವಾಗಿ ಪರಿಣಾಮಿಸುವ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ಮೇಲೆ ಗಮನ ಕೊಡಿ.

ಆಳವಾದ ವಿಶ್ಲೇಷಣೆಗೆ, Activity Data ಅನ್ನು ಎಕ್ಸ್‌ಪೋರ್ಟ್ ಮಾಡಿ ಮತ್ತು ಕಾಲಕ್ರಮೇಣ ಪ್ರತಿ ವಿನಂತಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

7. ಅಗತ್ಯವಿದ್ದರೆ ಬೆಂಬಲ ತಂಡದೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಬೇಕಾದ ಮಾಹಿತಿ

ನೀವು ಬೆಂಬಲ ತಂಡವನ್ನು ಸಂಪರ್ಕಿಸಿದರೆ, ಇವುಗಳನ್ನು ಸೇರಿಸಿ:

  • ಪರಿಣಾಮಕ್ಕೊಳಗಾದ ಸಂಸ್ಥೆಯ IDಗಳು (ಮುಖ್ಯ)

  • Chat Completions ಅಥವಾ Responses ಮುಂತಾದ ಪರಿಣಾಮಕ್ಕೊಳಗಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು (ಮುಖ್ಯ)

  • ಪರಿಣಾಮಕ್ಕೊಳಗಾದ ಮಾಡೆಲ್‌ಗಳು (ಮುಖ್ಯ)

  • ಸಮಸ್ಯೆಯು ಫಾಸ್ಟ್ ಮೋಡ್ ಅಥವಾ ಸ್ಕೇಲ್ ಟಿಯರ್‌ನಲ್ಲಿ ಸಂಭವಿಸುತ್ತಿದೆಯೇ ಎಂಬುದು (ಮುಖ್ಯ)

  • ವಿಳಂಬ ಅಥವಾ ದೋಷಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಯವಲಯ ಸಹಿತ ಕಾಲಾವಧಿಗಳು (ಮುಖ್ಯ)

  • ಲಭ್ಯವಿದ್ದರೆ, ಸಂಬಂಧಿತ x-request-id ಅಥವಾ X-Client-Request-Id.

  • ನೀವು ಒದಗಿಸುವ ವಿನಂತಿಗಳಿಗೆ ಸಮಯವಲಯ ಸಹಿತ ಸಮಯಮುದ್ರೆಗಳು ಅಥವಾ ಕನಿಷ್ಠ ದಿನಾಂಕ.

ಲಭ್ಯವಿದ್ದರೆ, ಇವುಗಳನ್ನೂ ಸೇರಿಸಿ:

  • ವಿನಂತಿಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಾಜೆಕ್ಟ್ ID.

  • ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ ವಿನಂತಿಗಳು ಪರಿಣಾಮಕ್ಕೊಳಗಾಗಿವೆಯೇ ಮತ್ತು ಅವು ಯಾವುವು ಎಂಬುದು.

  • ನೀವು ಗಮನಿಸುತ್ತಿರುವ ಪ್ರವೃತ್ತಿಗಳ ವಿವರಣೆಗಳು.

ಸಮಸ್ಯೆಯ ಪ್ರಕಾರಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇವುಗಳನ್ನು ಸೇರಿಸಿ:

  • ದೋಷಗಳು: ವಿಫಲವಾಗುತ್ತಿರುವ ಅಥವಾ ದೋಷ ನೀಡುತ್ತಿರುವ ವಿನಂತಿಗಳ ಅಂದಾಜು ಶೇಕಡಾವಾರು, ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್‌ಗಳು, ದೋಷ ಸಂದೇಶಗಳು ಮತ್ತು ದೋಷದ ಪ್ರತಿಕ್ರಿಯೆ ಸ್ವೀಕರಿಸಲು ತೆಗೆದುಕೊಂಡ ಸಮಯ.

  • ವಿಳಂಬ: ಪರಿಣಾಮಕ್ಕೊಳಗಾದ ಶತಕಗಳು (P50 / P90 / P95 / P99), ಗ್ರಾಹಕರ ಮೂಲಮಟ್ಟಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಅವು ಎಷ್ಟು ಹೆಚ್ಚಿವೆ ಮತ್ತು ಕಳುಹಿಸಿದ ಹಾಗೂ ಸ್ವೀಕರಿಸಿದ ಸಮಯಮುದ್ರೆಗಳೊಂದಿಗೆ ನಿಧಾನಗತಿಯ ವಿನಂತಿಗಳ ಉದಾಹರಣೆಗಳು.

  • ಎರಡೂ: ದೋಷ ಅಥವಾ ವಿಳಂಬದ ಡೇಟಾದ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳು ಅಥವಾ ಕೋಷ್ಟಕದ ಜೊತೆಗೆ, ದೋಷದ ದರಗಳು ಅಥವಾ ವಿಳಂಬವು ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚಿದೆ ಎಂದು ನೀವು ಹೇಗೆ ನಿರ್ಧರಿಸಿದ್ದೀರಿ ಎಂಬ ವಿವರ.

ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆ ನಿವಾರಣೆ ಸನ್ನಿವೇಶಗಳು

ಟೈಮ್‌ಔಟ್‌ಗಳು ಸಂಭವಿಸಿದರೂ ಸೇವಾ ಆರೋಗ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣುತ್ತದೆ

ಸಂಭಾವ್ಯ ಕಾರಣ: ವಿನಂತಿಗಳು OpenAI ತಲುಪುವ ಮೊದಲು ಟೈಮ್‌ಔಟ್ ಆಗುತ್ತಿವೆ.

ಪರಿಶೀಲಿಸಿ:

  • ಕ್ಲೈಂಟ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಟೈಮ್‌ಔಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು

  • ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಅಥವಾ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಬದಲಾವಣೆಗಳು

  • ಸೇವಾ ಆರೋಗ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ 499 ದೋಷಗಳಿರುವಿಕೆ (ಇವು ನಿಮ್ಮ ಸ್ವಂತ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ 5xx ದೋಷಗಳಾಗಿ ಕಾಣಿಸಬಹುದು).

ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್ ಇಲ್ಲದೆ ಲೇಟೆನ್ಸಿ ಹೆಚ್ಚಾಗಿದೆ

ಸಂಭಾವ್ಯ ಕಾರಣ: ಔಟ್‌ಪುಟ್ ಟೋಕನ್ ಗಾತ್ರ ಅಥವಾ ರೀಜನಿಂಗ್ ಬಳಕೆ ಹೆಚ್ಚಾಗಿದೆ ಮತ್ತು/ಅಥವಾ ಟ್ರಾಫಿಕ್ ಸೇವಾ ಹಂತಗಳ ನಡುವೆ ಬದಲಾಗಿದೆ.

ಪರಿಶೀಲಿಸಿ:

  • ಬಳಕೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ಪ್ರತಿ ವಿನಂತಿಗೆ ಸರಾಸರಿ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು (ಡೇಟಾವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ, ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳನ್ನು ಒಟ್ಟು ವಿನಂತಿಗಳಿಂದ ಭಾಗಿಸುವುದು ಅಗತ್ಯ).

  • ಸೇವಾ ಆರೋಗ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ Request Time ಮತ್ತು TTFT ಪರ್ಸೆಂಟೈಲ್‌ಗಳು.

ಫಾಸ್ಟ್ ಮೋಡ್ ಅಥವಾ ಸ್ಕೇಲ್ ಟಿಯರ್ ನಿಧಾನವಾಗಿ ಕಾಣಿಸುತ್ತದೆ

ಸಂಭಾವ್ಯ ಕಾರಣ: ವಿವಿಧ ಟಿಯರ್‌ಗಳ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಿರುವುದರಿಂದ, ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟಿಯರ್‌ನ ಟ್ರಾಫಿಕ್ ಪಾವತಿಸಿದ ಟಿಯರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮರೆಮಾಡುತ್ತಿದೆ.

ಪರಿಶೀಲಿಸಿ:

  • ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಒಂದೇ ಟಿಯರ್ ಮತ್ತು ಮಾಡೆಲ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಲಾಗಿದೆ.

  • ಟಿಯರ್‌ಗಳ ನಡುವಿನ ಟೋಕನ್ ವೇಗದ ಹೋಲಿಕೆ.

5XX ದೋಷಗಳಲ್ಲಿ ಏರಿಕೆ

ಸಂಭಾವ್ಯ ಕಾರಣ: ಟ್ರಾಫಿಕ್‌ನ ಸಣ್ಣ ಶೇಕಡಾವಾರನ್ನು ಪರಿಣಾಮಿಸುವ ತಾತ್ಕಾಲಿಕ ವೈಫಲ್ಯಗಳು.

ಪರಿಶೀಲಿಸಿ:

  • ದೋಷ ದರದ ಶೇಕಡಾವಾರು

  • ಅದೇ ಸಮಯದಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಪ್ರಮಾಣ ಬದಲಾಗಿದೆಯೇ ಎಂಬುದು

ಸಮಸ್ಯೆ ಕೇವಲ ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ

ಸಂಭಾವ್ಯ ಕಾರಣ: ಪ್ರಾಜೆಕ್ಟ್-ನಿರ್ದಿಷ್ಟ ಕಾನ್ಫಿಗರೇಶನ್ ಅಥವಾ ಬಳಕೆ ಮಾದರಿ.

ಪರಿಶೀಲಿಸಿ:

  • ಪ್ರಾಜೆಕ್ಟ್-ಮಟ್ಟದ ಫಿಲ್ಟರಿಂಗ್

  • ಪರಿಣಾಮಿತರಾಗದ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಕೆ

ಅಂತಿಮ ಮುಖ್ಯಾಂಶಗಳು

  • ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಮೊದಲು, ಸಂಬಂಧಿತವಾಗಿರುವಲ್ಲಿ ಮಾಡೆಲ್, ಟಿಯರ್ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ.

  • ಲೇಟೆನ್ಸಿ ವಿಶ್ಲೇಷಣೆಗೆ ಸರಾಸರಿಗಳ ಬದಲು ಪರ್ಸೆಂಟೈಲ್‌ಗಳನ್ನು ಬಳಸಿ.

  • ಸಣ್ಣ ದೋಷ ದರಗಳು ನಿರೀಕ್ಷಿತವಾಗಿರುತ್ತವೆ.

  • ಡೇಟಾ ಕಾಣೆಯಾಗಿರುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸಮಸ್ಯೆಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ.

  • ಬಳಕೆ ಡೇಟಾ ಲೇಟೆನ್ಸಿ ಏಕೆ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಸಹಾಯ ಮಾಡಬಹುದು; ಸೇವಾ ಆರೋಗ್ಯವು ವರ್ತನೆ ಯಾವಾಗ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ಈ ಲೇಖನವು ಉಪಯುಕ್ತವಾಗಿತ್ತೇ?