ಮಿನಿಕ್ಯೂಬ್ ಸೆಟಪ್ ಮೂಲಕ ಗ್ರಾಫಾನಾದಲ್ಲಿ ಪ್ರಮೀತಿಯಸ್ ಡೇಟಾಸೋರ್ಸ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವುದು

ಮಿನಿಕುಬ್‌ನಲ್ಲಿ ಪ್ರಮೀಥಿಯಸ್-ಗ್ರಾಫನಾ ಇಂಟಿಗ್ರೇಷನ್ ದೋಷನಿವಾರಣೆ

ಕುಬರ್ನೆಟ್ಸ್-ಆಧಾರಿತ ಮಾನಿಟರಿಂಗ್ ಸ್ಟಾಕ್ ಅನ್ನು ನಿಯೋಜಿಸುವಾಗ, ಮೆಟ್ರಿಕ್ ಸಂಗ್ರಹಣೆ ಮತ್ತು ದೃಶ್ಯೀಕರಣಕ್ಕಾಗಿ ಎರಡು ಪ್ರಬಲ ಸಾಧನಗಳಾದ ಪ್ರೊಮೆಥಿಯಸ್ ಮತ್ತು ಗ್ರಾಫನಾವನ್ನು ಸಂಯೋಜಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಬಳಸುತ್ತಿದೆ ಮಿನಿಕುಬೆ ಸ್ಥಳೀಯ ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಸರವಾಗಿ, ಏಕೀಕರಣದ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರುವುದು ಅಸಾಮಾನ್ಯವೇನಲ್ಲ, ವಿಶೇಷವಾಗಿ ಡೇಟಾ ಮೂಲ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಹೊಂದಿಸುವಾಗ.

ಸೇರಿಸುವಾಗ ಈ ಲೇಖನವು ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಯನ್ನು ತಿಳಿಸುತ್ತದೆ ಪ್ರಮೀತಿಯಸ್ ಗ್ರಾಫಾನಾದಲ್ಲಿ ಡೇಟಾಸೋರ್ಸ್ ಆಗಿ. ಹೊಸ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಗ್ರಾಫಾನಾವನ್ನು ನಿಯೋಜಿಸಿದ ನಂತರ, ಪ್ರಮೀತಿಯಸ್-ರೀತಿಯ ಸೇವೆಗೆ ಸಂಪರ್ಕವನ್ನು ಪ್ರವೇಶಿಸಬಹುದು ಓಪನ್ ಟೆಲಿಮೆಟ್ರಿ ಕಲೆಕ್ಟರ್ ವಿಫಲವಾಗುತ್ತದೆ. ಸೇವೆಗಳನ್ನು ಸರಿಯಾಗಿ ನಿಯೋಜಿಸಿದ ನಂತರ ಮತ್ತು ಸಂಬಂಧಿತ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಅನ್ವಯಿಸಿದ ನಂತರ ಈ ಸಮಸ್ಯೆ ಸಂಭವಿಸುತ್ತದೆ.

ಎಚ್‌ಟಿಟಿಪಿ ಮೂಲಕ ಪ್ರೊಮೀಥಿಯಸ್‌ನನ್ನು ಪ್ರಶ್ನಿಸುವಾಗ ಎದುರಾಗುವ ದೋಷವು ಗೊಂದಲಕ್ಕೊಳಗಾಗಬಹುದು. "ತಪ್ಪಾದ HTTP ಪ್ರತಿಕ್ರಿಯೆ" ಸಂದೇಶವು ಮುರಿದ ಸಾರಿಗೆ ಸಂಪರ್ಕವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಮಿನಿಕುಬ್‌ನಲ್ಲಿನ ವಿವಿಧ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಅಥವಾ ಸೇವಾ ಮಾನ್ಯತೆ ಸಮಸ್ಯೆಗಳಿಂದ ಈ ದೋಷ ಉಂಟಾಗಬಹುದು.

ಈ ಲೇಖನವು ಮೂಲ ಕಾರಣವನ್ನು ನಿರ್ಧರಿಸುವ ಮತ್ತು ಸಮಸ್ಯೆಗೆ ನಿಜವಾದ ಪರಿಹಾರಗಳನ್ನು ಒದಗಿಸುವ ಕಾರ್ಯವಿಧಾನಗಳ ಮೂಲಕ ನಿಮ್ಮನ್ನು ಕರೆದೊಯ್ಯುತ್ತದೆ. ನಡುವೆ ಯಶಸ್ವಿ ಸೆಟಪ್ ಅನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಸಂಪರ್ಕ ಸಮಸ್ಯೆಯನ್ನು ನಿವಾರಿಸುತ್ತೇವೆ ಪ್ರಮೀತಿಯಸ್ ಮತ್ತು ಗ್ರಾಫನಾ ನಿಮ್ಮಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಸರ.

ಗ್ರಾಫಾನಾದಲ್ಲಿ ಪ್ರಮೀತಿಯಸ್ ಡೇಟಾಸೋರ್ಸ್ ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು

ಮೊದಲ ಸ್ಕ್ರಿಪ್ಟ್, NodePort ಮೂಲಕ Prometheus ಸೇವೆಯನ್ನು ಒದಗಿಸಲು Kubernetes ನ YAML ಸಂರಚನೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಗ್ರ್ಯಾಫಾನಾದಂತಹ ಬಾಹ್ಯ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಂದ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ನೀವು ಬಯಸಿದಾಗ ಈ ತಂತ್ರವು ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿದೆ. 'ನೋಡ್‌ಪೋರ್ಟ್' ಪ್ರಕಾರವು ನಿರ್ದಿಷ್ಟ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಸೇವೆಗೆ ಬಾಹ್ಯ ದಟ್ಟಣೆಯನ್ನು ರವಾನಿಸುತ್ತದೆ, ಇದನ್ನು ಗ್ರಾಫನಾ ನಂತರ ಡೇಟಾ ಮೂಲವಾಗಿ ಬಳಸಬಹುದು. ಪ್ರೋಗ್ರಾಂ Minikube ಅಥವಾ ಅಂತಹುದೇ ಸ್ಥಳೀಯ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ರನ್ ಆಗುವಾಗ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಸನ್ನಿವೇಶಗಳಿಗೆ ಈ ತಂತ್ರವು ಸೂಕ್ತವಾಗಿದೆ.

ಎರಡನೆಯ ಆಯ್ಕೆಯು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸುತ್ತದೆ ಪ್ರವೇಶ HTTP ಮೂಲಕ ಪ್ರೊಮೀಥಿಯಸ್ ಸೇವೆಯನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ಸಂಪನ್ಮೂಲ, ಇದು ಕ್ಲಸ್ಟರ್ ಹೊರಗಿನಿಂದ ಪ್ರವೇಶಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ಬಾಹ್ಯ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಪ್ರವೇಶವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ HTTP ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮೂಲಕ ನೇರವಾಗಿ ಪ್ರಮೀಥಿಯಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸಲು ಗ್ರಾಫನಾಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್, SSL ಮುಕ್ತಾಯ ಮತ್ತು ಹೆಸರು-ಆಧಾರಿತ ವರ್ಚುವಲ್ ಹೋಸ್ಟಿಂಗ್ ಸೇರಿದಂತೆ ಹೆಚ್ಚು ವಿಸ್ತಾರವಾದ ರೂಟಿಂಗ್ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನೀಡುತ್ತದೆ ಎಂಬುದು ಪ್ರವೇಶವನ್ನು ಬಳಸಿಕೊಳ್ಳುವ ಪ್ರಾಥಮಿಕ ಪ್ರಯೋಜನವಾಗಿದೆ. ಮೇಲ್ವಿಚಾರಣಾ ಸೇವೆಗಳಿಗೆ ನಿಮಗೆ ಸುರಕ್ಷಿತ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ ಪ್ರವೇಶ ಅಗತ್ಯವಿರುವ ಉತ್ಪಾದನಾ ಸನ್ನಿವೇಶಗಳಿಗೆ ಈ ಪರಿಹಾರವು ಸೂಕ್ತವಾಗಿದೆ.

ಮೂರನೇ ವಿಧಾನವು ಗ್ರಾಫಾನಾದಿಂದ ಪ್ರೊಮೆಥಿಯಸ್‌ಗೆ HTTP ವಿನಂತಿಗಳನ್ನು ಪ್ರಸಾರ ಮಾಡಲು ಕಸ್ಟಮ್ GoLang ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸುತ್ತದೆ. GoLang ಸರ್ವರ್ ವಿನಂತಿಗಳನ್ನು ಆಲಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು Kubernetes ಕ್ಲಸ್ಟರ್‌ನೊಳಗೆ ಸೂಕ್ತವಾದ ಅಂತಿಮ ಬಿಂದುವಿಗೆ ರವಾನಿಸುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್ ಮಿತಿಗಳು ಗ್ರಾಫಾನಾದಿಂದ ಪ್ರಮೀತಿಯಸ್‌ಗೆ ನೇರ ಸಂಪರ್ಕವನ್ನು ತಡೆಯುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅಥವಾ ವಿನಂತಿಯು ಪ್ರಮೀತಿಯಸ್‌ಗೆ ತಲುಪುವ ಮೊದಲು ಹೆಚ್ಚುವರಿ ಪ್ರಕ್ರಿಯೆ ಅಗತ್ಯವಿದ್ದಾಗ ಈ ವಿಧಾನವು ಪ್ರಯೋಜನಕಾರಿಯಾಗಿದೆ. GoLang ಸ್ಕ್ರಿಪ್ಟ್ ಸರಳವಾಗಿದೆ ಆದರೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ, ಇದು ಇತರ ಪರಿಹಾರಗಳಿಗೆ ಕಾರ್ಯಸಾಧ್ಯವಾದ ಆಯ್ಕೆಯನ್ನು ನೀಡುತ್ತದೆ.

ಅಂತಿಮವಾಗಿ, GoLang ನ ಘಟಕ ಪರೀಕ್ಷೆಗಳು ಪ್ರಾಕ್ಸಿ ನಿರೀಕ್ಷೆಯಂತೆ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸುತ್ತದೆ. HTTP ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು 'httptest.NewRequest' ಮತ್ತು 'httptest.NewRecorder' ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸುವುದರಿಂದ ಪ್ರಾಕ್ಸಿಯು ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳನ್ನು ಅವಲಂಬಿಸದೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸರಿಯಾಗಿ ಹಾದುಹೋಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಈ ಘಟಕ ಪರೀಕ್ಷೆಗಳು ನೈಜ ದಟ್ಟಣೆಯನ್ನು ಅನುಕರಿಸುತ್ತದೆ ಮತ್ತು ಗ್ರಾಫನಾ ಉದ್ದೇಶಿಸಿದಂತೆ ಪ್ರಮೀತಿಯಸ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ವಿವಿಧ ಸಂದರ್ಭಗಳಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಘಟಕ ಪರೀಕ್ಷೆಗಳು ನಿರ್ಣಾಯಕವಾಗಿವೆ, ಜೊತೆಗೆ ಯೋಜನೆಯು ವಿಸ್ತರಿಸಿದಂತೆ ಕೋಡ್ ಗುಣಮಟ್ಟವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

apiVersion: v1
kind: Service
metadata:
  name: prometheus-service
  namespace: default
spec:
  selector:
    app: prometheus
  ports:
  - protocol: TCP
    port: 9090
    targetPort: 9090
  type: NodePort

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: prometheus-ingress
  namespace: default
spec:
  rules:
  - host: prometheus.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: prometheus-service
            port:
              number: 9090

package main
import (
  "net/http"
  "log"
)
func handler(w http.ResponseWriter, r *http.Request) {
  http.Redirect(w, r, "http://prometheus-service.default.svc:9090", 301)
}
func main() {
  http.HandleFunc("/", handler)
  log.Fatal(http.ListenAndServe(":8080", nil))
}

package main
import (
  "net/http"
  "net/http/httptest"
  "testing"
)
func TestHandler(t *testing.T) {
  req := httptest.NewRequest("GET", "http://localhost:8080", nil)
  rr := httptest.NewRecorder()
  handler(rr, req)
  if status := rr.Code; status != http.StatusMovedPermanently {
    t.Errorf("wrong status code: got %v want %v", status, http.StatusMovedPermanently)
  }
}

ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಪ್ರಮೀತಿಯಸ್ ಮತ್ತು ಗ್ರಾಫನಾ ಏಕೀಕರಣವನ್ನು ಉತ್ತಮಗೊಳಿಸುವುದು

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಪ್ರಮೀಥಿಯಸ್ ಮತ್ತು ಗ್ರಾಫನಾವನ್ನು ಸಂಯೋಜಿಸಲು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಾದ್ಯಂತ ಸಾಕಷ್ಟು ಸೇವೆಯ ಮಾನ್ಯತೆಯ ಅಗತ್ಯವಿದೆ. ನಿಮ್ಮ ಸನ್ನಿವೇಶದಲ್ಲಿ, ನೀವು ಡೀಫಾಲ್ಟ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ OpenTelemetry ಕಲೆಕ್ಟರ್ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಒಂದರಲ್ಲಿ Grafana ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೀರಿ. ClusterIP ಯಂತಹ ಕುಬರ್ನೆಟ್ಸ್ ವೈಶಿಷ್ಟ್ಯಗಳು ಆಂತರಿಕ ಸಂವಹನವನ್ನು ಸುಧಾರಿಸುತ್ತದೆ, ಸರಿಯಾದ ಸೆಟಪ್ ಇಲ್ಲದೆ ಕ್ರಾಸ್-ನೇಮ್ಸ್ಪೇಸ್ ಸಂವಹನ ಕಷ್ಟವಾಗಬಹುದು. ಸೇವೆಯ ಹೆಸರುಗಳು ಮತ್ತು DNS ನಮೂದುಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ನಿರ್ಣಾಯಕವಾಗಿದೆ, ಇದರಿಂದಾಗಿ ಗ್ರಾಫಾನಾ ಉದ್ದೇಶಿತ ಅಂತಿಮ ಬಿಂದುವಿನ ಮೂಲಕ ಪ್ರಮೀತಿಯಸ್ ಅನ್ನು ತಲುಪಬಹುದು.

ಗ್ರಾಫಾನಾದೊಂದಿಗೆ ಪ್ರೋಮೀಥಿಯಸ್ ಏಕೀಕರಣವನ್ನು ಡೀಬಗ್ ಮಾಡುವಾಗ ಮತ್ತೊಂದು ಪರಿಗಣನೆಯು ಸೇವೆಯ ಪ್ರಕಾರಗಳು ಪ್ರವೇಶದ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದು. ಎ ClusterIP ಸೇವೆಯು ಆಂತರಿಕ ಕ್ಲಸ್ಟರ್ ಬಳಕೆಗಾಗಿ ಉದ್ದೇಶಿಸಲಾಗಿದೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಮಾತ್ರ ಪ್ರವೇಶಿಸಬಹುದು. ಗ್ರಾಫನಾವನ್ನು ಬೇರೆ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದ್ದರೆ ಅಥವಾ ಬಾಹ್ಯ ಪ್ರವೇಶದ ಅಗತ್ಯವಿದ್ದರೆ, a ಗೆ ಚಲಿಸುತ್ತದೆ ನೋಡ್‌ಪೋರ್ಟ್ ಅಥವಾ ಪ್ರವೇಶ ಸೇವೆಯ ಪ್ರಕಾರವು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ. ಈ ನವೀಕರಣವು ಕ್ಲಸ್ಟರ್‌ನ ಹೊರಗಿನಿಂದ ಅಥವಾ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಾದ್ಯಂತ ಟ್ರಾಫಿಕ್ ಅನ್ನು ರೂಟ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.

ಇದಲ್ಲದೆ, ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಸೇವೆಗಳ ನಡುವೆ ನೆಟ್‌ವರ್ಕ್ ತೊಂದರೆಗಳನ್ನು ನಿರ್ಣಯಿಸುವುದು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ, ವಿಶೇಷವಾಗಿ "HTTP ಸಾರಿಗೆ ಸಂಪರ್ಕವು ಮುರಿದುಹೋಗಿದೆ" ನಂತಹ ಸಂದೇಶಗಳು ಕಾಣಿಸಿಕೊಂಡಾಗ. ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಪೋರ್ಟ್‌ಗಳು ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಂದ ಈ ತೊಂದರೆಗಳು ಉಂಟಾಗಬಹುದು. 'kubectl port-forward' ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳಂತಹ ಪರಿಕರಗಳು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸೇವೆಗಳಾದ್ಯಂತ ಸಂಪರ್ಕವನ್ನು ನೈಜ ಸಮಯದಲ್ಲಿ ಪರಿಶೀಲಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ, ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಗಳನ್ನು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಅವರಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಪ್ರಮೀತಿಯಸ್ ಮತ್ತು ಗ್ರಾಫನಾ ಮನಬಂದಂತೆ ಸಂವಹನ ನಡೆಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸರಿಯಾದ ಪೋರ್ಟ್‌ಗಳನ್ನು (ಜಿಆರ್‌ಪಿಸಿಗೆ 4317 ನಂತಹ) ಬಹಿರಂಗಪಡಿಸುವುದು ಅವಶ್ಯಕ.