¿Qué o cómo mejorar? Python, React, Postgresql

Por comodidad, todo metido en containers. Tanto el front como las bbdd

#3 Ponzoña Grafana/Influx? Un poco violenta esa forma de referirse al actual estandar de la industria, no? Por no decir que has comparado el uso de Prometheus con el de Grafana cuando no tienen nada que ver una cosa con la otra. Yo metería Prometheus para scraping, sobretodo si terminas montando alguna de las versiones de K8s y así podrás utilizar las anotaciones que corresponda. Grafana para la visualización de los datos y InfluxDB para el histórico de métricas. Si quieres logs, mete también Loki. Este stack se integra muy bien.

Desconozco si el proyecto es productivo 100% o si es mas para aprender, pero a poco que vaya a ser algo funcional de verdad, te dejases de bases de datos en containers. Para las aplicaciones, sin duda.

De nuevo, si es para un stack de pruebas, compose está medio bien, pero te recomendaría pasarte a K3s o algo similar para ir pasándote al estandar de la industria. Bajo ningún concepto montes un Kubernetes Vanilla a no ser que sea para aprender.

Y para la gestión de procesos,te diría que un Airflow montado también en containers. Es sencillo y muy versátil.

#4 A ver que Grafana y tal está bien pero se queda muy corto y a mi como usuario me parece bastante tercermundista, Prometheus no lo he usado ya que siempre he estado en Datadog y Newrelic, pero vamos he usado tanto InfluxDB como Grafana y me parecen ambos bastante mediocres como apps.

#6 estás comparando una herramienta de pago y cara ($$$) como Datadog, con como he dicho, el estandar de monitorización de la industria que es Grafana. En que te basas para decir que es tercermundista? Tienes plugins para aburrir, tienes themes para aburrir, tienes comunidad para aburrir y todo está en desarrollo constante tanto por la comunidad, como por la propia empresa Grafana que se ha convertido en una de las maás potentes del sector. Datadog está muy bien para empezar o si necesitas algo cómodo y te da un poco igual la parte económica, ya que únicamente instalando el Agente ya tienes métricas y logs disponibles. Pero es muy MUY peligroso si no controlas el número de métricas ingestadas. Con New Relic pasa exactamente lo mismo, cómodo por necesitar un agente y a correr.

Respecto a IngluxDB es una TSDB, así que tampoco hay que intentar tratarlo como lo que no es. Para cosas discretas está muy bien y si necesitas algo más completo y eficiente te puedes pasar al stack de M3 o Victoria Metrics. Pero vamos, que para lo que necesita el OP con el InflixDB le sobra de calle. No creo que vaya a necesitar insertar millones de datos por segundo.

#5 Basicamente, Prometheus es un scraper. Tus aplicaciones lo que deberían hacer es publicar las métricas que quieran en un endpoint, ya sean a través del framework que corresponda o mediante algún agente de statsD por ejemplo. Y el Prometheus lo que hará será atacar a todos esos hosts al endpoint que le hayas indicado recogiendo esas métricas y enviandolas al InflixDB (o cualquier otro destino de datos que quieras. Puedes enviarlo directamente a Grafana, pero el historico de datos que podrás almacenar será menor). A partir de ahí, el Grafana tendrá configurado el InfluxDB como origen de datos y cuando le solicites una muestra, le hará la consulta correspondiente.

Para la parte de Kubernetes, importante lo que te he comentado. Si puedes evitar meterte en la parte de administración del Kubernetes en si, hazlo (a no ser que lo que quieras sea aprender eso en concreto). Pillate algún servicio gestionado o alguna versión lite como Minikube, K3s, K0s...

Dejo por aquí cosas interesantes:
Explicación del stack que comentaba - https://medium.com/swlh/monitoring-with-grafana-prometheus-and-influxdb-an-airport-webcams-example-508c04b226b6

Charla de un proyecto en el que participé precisamente para quitar Datadog por optimización de costes - https://www.youtube.com/watch?v=1eDZYiRDF3I&list=PLQ1vMvN4ZpX9tSYkX0xzP8eV_D3DtB79l&index=10

#9 Correcto. No conocía esta parte ya que no la trabajé y únicamente utilizabamos su caché. Desconozco cuanto de eficiente es como TSDB.

https://prometheus.io/docs/prometheus/latest/storage/

Coincido con que Prometheus me parece mejor que influxdb/grafana aunque solo lo he probado, en la empresa tiraron por Datadog

#5 k8s es el orquestrador de contenedores que usa la mayoría. Al principio puede saturar de lo potente que es pero una vez que tienes los conceptos claros, no es tan difícil

Resumen de lo que es k8s:

Aquí te haces un intensivo de 5h

#13 Pues ya les vale tirarte por eso, madre mía.

A ver que está bien y ha sido el estándar, ahora lo es Prometheus. Por poder se puede usar para mil historias, a mi personalmente no me gusta mucho, pero está bien de funcionalidad

#17 Por eso mismo te dije que para montar 4 containers Kubernetes es un overkill de cuidado.

Primero, para montar un servicio como LoadBalancer, debes tener el cluster configurado en algun cloud publico de cara a poder usar SUS servicios de LoadBalancer, de lo contrario, unicamente puedes exponer hacia afuera el servicio con uno de tipo NodePort.

Por otro lado, un objeto Ingress se registra en un IngressController, y debes tener definidos ambos. El servicio NodePort expondra el deployment del IngressController y este hara de reverseProxy dentro del cluster.

Si quieres exponer Grafana, entonces el flujo del trafico es el siguiente:

Servicio LoadBalancer -> IngressController -> Ingress -> Grafana SVC -> Grafana Pod

Para el ingressController, puedes utilizar este por ejemplo: https://kubernetes.github.io/ingress-nginx/

En cuanto al storage, en un mismo cluster puedes tener diferentes tipos de Storage, y defines como usarlos o no en los propios yaml de config

#23 ¿Es obligatorio? Voy a probar

#25 Nada, imposible

#27

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: grafana-ingress
  namespace: monitoring
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
    - host: "*.svc.local"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: kube-prometheus-stack-1643570798-grafana
                port:
                  number: 80

apiVersion: v1
kind: Service
metadata:
  name: kube-prometheus-stack-1643570798-grafana
  namespace: monitoring
  uid: 5372d8d5-2688-4bfc-918b-b24908df84e4
  resourceVersion: '26142'
  creationTimestamp: '2022-01-30T19:27:03Z'
  labels:
    app.kubernetes.io/instance: kube-prometheus-stack-1643570798
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: grafana
    app.kubernetes.io/version: 8.3.4
    helm.sh/chart: grafana-6.21.0
  annotations:
    meta.helm.sh/release-name: kube-prometheus-stack-1643570798
    meta.helm.sh/release-namespace: monitoring
  managedFields:
    - manager: helm
      operation: Update
      apiVersion: v1
      time: '2022-01-30T19:27:02Z'
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:annotations:
            .: {}
            f:meta.helm.sh/release-name: {}
            f:meta.helm.sh/release-namespace: {}
          f:labels:
            .: {}
            f:app.kubernetes.io/instance: {}
            f:app.kubernetes.io/managed-by: {}
            f:app.kubernetes.io/name: {}
            f:app.kubernetes.io/version: {}
            f:helm.sh/chart: {}
        f:spec:
          f:ports:
            .: {}
            k:{"port":80,"protocol":"TCP"}:
              .: {}
              f:name: {}
              f:port: {}
              f:protocol: {}
              f:targetPort: {}
          f:selector:
            .: {}
            f:app.kubernetes.io/instance: {}
            f:app.kubernetes.io/name: {}
          f:sessionAffinity: {}
          f:type: {}
  selfLink: >-
    /api/v1/namespaces/monitoring/services/kube-prometheus-stack-1643570798-grafana
status:
  loadBalancer: {}
spec:
  ports:
    - name: http-web
      protocol: TCP
      port: 80
      targetPort: 3000
  selector:
    app.kubernetes.io/instance: kube-prometheus-stack-1643570798
    app.kubernetes.io/name: grafana
  clusterIP: 10.96.65.70
  clusterIPs:
    - 10.96.65.70
  type: ClusterIP
  sessionAffinity: None
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack