Quiero usar mis instancias de Prometheus y Grafana ya existentes en el espacio de nombres de monitoreo para emular lo que está haciendo seldon-core-analytics . Estoy usando los gráficos de timón de la comunidad de Prometheus e instalé kube-prometheus-stack en k8s. Esto es lo que he hecho hasta ahora:
En el archivo values.yaml , bajo la configuración de Prometheus, agregué las siguientes anotaciones:
annotations: prometheus.io/scrape: "true" prometheus.io/path: "/prometheus Luego, miré el prometheus-config.yaml en su repositorio de Github y copié y pegué la configuración en un archivo de mapa de configuración.
Además, creó un ServiceMonitor
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: seldon-servicemonitor-default labels: seldon-monitor: seldon-default namespace: monitoring spec: selector: matchLabels: app.kubernetes.io/managed-by: seldon-core endpoints: - interval: 15s path: /metrics port: http - interval: 15s path: /prometheus port: http namespaceSelector: matchNames: - seldon - default - monitoring No hay errores con los pasos anteriores hasta el momento, pero no parece que la instancia de Prometheus pueda extraer las métricas de un modelo que implementé en un espacio de nombres diferente. ¿Qué otra configuración debo hacer para que mis propias instancias de Prometheus y Grafana puedan recopilar y visualizar las métricas de mis modelos poco implementados? La documentación realmente no explica cómo hacer esto en sus propias instancias, y la que le proporcionan a través seldon-core-analytics no está lista para producción.
La configuración de Prometheus en seldon-core-analytics es bastante estándar. Se basa en el descubrimiento de servicios de Kubernetes incorporado y utiliza anotaciones para encontrar objetivos de raspado:
annotations: prometheus.io/scrape: true prometheus.io/path: /metrics prometheus.io/scheme: http prometheus.io/port: 9100 En su configuración de ejemplo, Prometheus apuntará a pods, servicios y puntos finales con prometheus.io/scrape: true en ellos. Las otras tres etiquetas se utilizan para anular los parámetros de raspado predeterminados por objetivo. Por lo tanto, si tiene una configuración como la del ejemplo, solo necesita colocar algunas de estas anotaciones en los pods.
La forma en que funciona kube-prometheus-stack es diferente. Utiliza el operador Prometheus y CRD para dar forma a la configuración. Este documento de diseño describe el propósito de cada CRD.
Debe crear un recurso ServiceMonitor para definir una regla de extracción para nuevos servicios. ServiceMonitor en sí debe tener etiquetas como se define en el recurso Prometheus (otro CRD) bajo la clave serviceMonitorSelector . Es difícil proporcionarle un ejemplo de trabajo en estas circunstancias, pero esta breve guía debería ser suficiente para comprender qué hacer.
Le sugiero que describa uno de los ServiceMonitor que tiene, luego cree uno nuevo cambiando las etiquetas en matchLabels . No cambie el espacio de nombres en un nuevo objeto, el operador Prometheus no busca ServiceMonitor en otros espacios de nombres de forma predeterminada. Para que ServiceMonitor descubra objetivos en todos los espacios de nombres, el namespaceSelector debe estar vacío:
spec: namespaceSelector: any: trueLos monitores de servicio son extremadamente difíciles de depurar. Mi estrategia de depuración sería: -
Compruebe si Prometheus lee el ServiceMonitor creado : - Mire la URL /targets. (Debe haber un objetivo en el estado 0/0 al menos) De lo contrario, eso significa que Prometheus no está detectando el ServiceMonitor en sí. Sugiero buscar en la siguiente configuración en su configuración de kube-prometheus-stack.
serviceMonitorSelectorNilUsesHelmValues: false serviceMonitorSelector: {} serviceMonitorNamespaceSelector: {} El ServiceMonitor predeterminado tiene los metadatos de Helm adjuntos que utiliza el operador de Prometheus para filtrar/elegir los ServiceMonitor para monitorear. Establecer serviceMonitorSelectorNilUsesHelmValues:false ignorará cualquier selección de este tipo.
Si ServiceMonitor está visible en los destinos pero no hay destinos. :- En este caso, el problema radica entre ServiceMonitor y los pods que está tratando de raspar. Verifique si los puertos que mencionó son accesibles y si los pods cumplen con los selectores mencionados.
Mi consejo sería iniciar otro ServiceMonitor ficticio siguiendo esto y luego modificando el ServiceMonitor paso a paso hasta que comience a monitorear los seldon-core-analytics