Как я создавал Observability для своих pet-проектов. Часть 1

[alhimik45]

Я что-то у себя стек Grafana + Loki + tempo не осилил поставить за один выходной. Конфиги, конифги - из коробки под k8s не заводится. Разобраться конечно можно, но как-то для пет проектов хотелось бы чего-то простого как палка.

В итоге поставил https://openobserve.ai/ одним контейнером. Логи, метрики, трейсы в одном флаконе с единым UI без необходимости настраивать несколько сервисов. Opentelemetry collector льёт в него логи и метрики всего что в k8s. Плюс кастомные метрики от умного дома лью напрямую из питона тоже по OTLP. Он очень хорошо жмёт данные, сейчас пишет стату, что на Ingested Size в 573.20 GB на диске Compressed Size получился 15.69 GB.

[Apokalepsis]

Просто в Docker я в целом запустил без страданий, конфиги тоже не большие. В кубер Tempo не использовал, а вот Grafana + Loki достаточно легко залетал. Надо будет с Tempo попробовать.

За ссылку спасибо, жмет не просто хорошо, а потрясающе. Особенно актуально в ентерпрайзе, когда есть требование по длительному сроку хранения. У тебя случайно нет helm чарта развернуть, попробовать?

[alhimik45]

У меня просто кубер манифест сделанный по доке к докер контейнеру. Вначале планировал в качестве хранилки использовать B2, но когда увидел как он жмёт, решил вообще не заморачиваться и просто в папке на VPS хранить пока место есть

Скрытый текст

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: openobserve
  namespace: monitoring
spec:
  serviceName: openobserve
  replicas: 1
  selector:
    matchLabels:
      app: openobserve
  template:
    metadata:
      labels:
        app: openobserve
    spec:
      volumes:
        - name: data
          hostPath:
            path: /openobserve
      containers:
        - name: openobserve
          image: public.ecr.aws/zinclabs/openobserve:latest
          env:
            - name: ZO_ROOT_USER_EMAIL
              value: [e-mail]
            - name: ZO_ROOT_USER_PASSWORD
              value: "P@ssw0rd!"
            - name: ZO_DATA_DIR
              value: /data
            - name: ZO_TELEMETRY
              value: "false"
          resources:
            limits:
              cpu: 4096m
              memory: 2048Mi
            requests:
              cpu: 256m
              memory: 50Mi
          ports:
            - containerPort: 5080
              name: http
          volumeMounts:
          - name: data
            mountPath: /data
---
apiVersion: v1
kind: Service
metadata:
  name: openobserve
  namespace: monitoring
spec:
  selector:
    app: openobserve
  ports:
  - name: http
    port: 5080
    targetPort: 5080
  - name: grpc
    port: 5081
    targetPort: 5081

[gecube]

В итоге поставил https://openobserve.ai/ одним контейнером

выглядит прикольно. Интересно послушать опыт.

[kinderbug]

alias obs='ssh -L 3000:localhost:3000 user@your-vps'

Лайфхак как не костылить через алиасы:

Файл ~/.ssh/config

Host obs
    HostName your-vps
    User user
    LocalForward 3000 127.0.0.1:3000

Теперь просто заходим по ssh obs и автоматом будет нужный порт пробрасываться куда надо

[Kenya-West]

Очень хороший комментарий. Лучше все свои машины указывать в ~/.ssh/config. Как бонус, XPipe и прочее ПО для организации управления серверами будет тянуть всю инфу из этого файла.

[Apokalepsis]

Я конфигом пользуюсь, но даже как-то не знал или не обращал внимание что можно через него туннель. Прям большое спасибо!

[sergeygals]

Кажется что есть смысл заменить loki на victorialogs, у второго есть свой ui из коробки, он реально жрёт меньше и ресурсов и места

[Apokalepsis]

Потыкать Victoria Logs у меня в план, но в текущей задаче сильно проще с Loki - он уже проверенный, достаточно эффективный и отличный интерфейс, Grafana, один на все: логи, метрики, трейсы. Скоро еще вроде планируется возможность хранить профили приложений.

[gecube]

один интерфейс на все - очень спорное решение

Касательно Loki:

It seems Loki has over 784 configuration options and 12 microservices (and counting ++).

https://github.com/grafana/loki/issues/4613
"Простое" и "эффективное" решение. Угу.
Про Jaeger тоже самое.
Сейчас уже модно - https://github.com/metrico/qryn
Из киллер фич - эффективность хранения данных + совместимость по апи с темпо-локи итп

[sergeygals]

Примечание: я пока не до конца разобрался, чем отличается VictoriaMetrics от Prometheus (в контексте Grafana) при работе с Prometheus‑метриками. Судя по всему, если указать плагин Prometheus, то Grafana корректно подключается к VictoriaMetrics. Но, тем не менее, я предпочитаю явно указать её как отдельный источник.

Таки все правильно. О различиях есть тут https://docs.victoriametrics.com/victoriametrics-datasource/. В целом использовать Prometheus datasource есть смысл только когда меняешь Prometheus на VM, что бы не перерисовать борды сделанные для Prometheus