Pull to refresh

Comments 10

А можно на примере, что за проблема с Prometheus Pushgateway и как Thanos Receive её решает.

Что значит - "Метрика, отправленная в Pushgateway, существует в нём, пока не будет в явном виде удалена или перезаписана"? Почему это не так для метрики отправленной в Thanos Receive?

тут лучше всего, наверно, опишет оф дока Prometheus Pushgateway:

The Pushgateway never forgets series pushed to it and will expose them to Prometheus forever unless those series are manually deleted via the Pushgateway's API.

когда на пушгейтвей отправляем метрики, он их принимает, и потом отдает по порту /metrics все, что ему было отправлено. У него нет механизма "просрочки" метрики. Пока ты не пушнешь метрику с новым значением, старое так и будет висеть.

На рисевер же мы отправляем метрику. Ресивер ее аппроксимирует до нескольких минут, и все, потом она уходит в прошлое. Так как метрика приходит с четко проставленным временем.

Спасибо, стало чуть понятнее, но я не зря просил пример - мозг у меня так устроен, мне мало правила, мне нужен пример, что бы понять правило :(

Но если я правильно понял, то разница такая (на примере температуры):

  • В чистом виде - пром. опрашивает сервис и тот возвращает ему температуру на момент опроса (нап. 90). Если сервис не отвечает, то температура не определена или 0

  • В случае пушгейтвей - пром. опрашивает пушгейтвей, а тот возвращает ему последнее пушнотое значение для этой метрики, даже если сервис уже давно ничего не пушал, то есть температура будет всегда, например, 90.

  • В случае рисевера то он просто сразу записывает метрику в базу с временем. И 90 там будет только на момент получения метрики, а потом новое значение, или если сервис перестал работать, то температура не определена или 0

Вот написал и вроде понятней стало. Надеюсь это кому-то тоже поможет.

Нужен простой советский бизибокс.

Писал тут не так давно экспортер для статусов группы CRD на бизибоксе + немного баша и jq

#!/bin/bash

# Old way. Need kubectl
#
# crd_name_1_rec=$(kubectl get crd_name_1 -n kube-system -o jsonpath='{range .items[*]}{.status.phase}{"\n"}{end}' | sort | uniq -c )
# crd_name_2_rec=$(kubectl get crd_name_2 -n kube-system -o jsonpath='{range .items[*]}{.status.phase}{"\n"}{end}' | sort | uniq -c )

token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

crd_name_1_rec=$(curl --silent -XGET "https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/apis/k8s.tinkoff.ru/v1alpha1/namespaces/${POD_NAMESPACE}/crd_name_1" \
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer ${token}" \ |
jq '.items[].status.phase' | sort | uniq -c)

echo '# HELP crd_name_1 Count of crd_name_1 statuses according it state'
echo '# TYPE crd_name_1  gauge'

while IFS= read -r status 
do
  echo "crd_name_1{state=$(echo $status | awk '{print $2}')} $(echo $status | awk '{print $1}')"
done <<< "$crd_name_1_rec"

unset status
unset crd_name_1_rec

crd_name_2_rec=$(curl --silent -XGET "https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/apis/k8s.tinkoff.ru/v1alpha1/namespaces/${POD_NAMESPACE}/crd_name_2" \
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer ${token}" \ |
jq '.items[].status.phase' | sort | uniq -c)

echo '# HELP crd_name_2 Count of crd_name_2 statuses according it state'
echo '# TYPE crd_name_2  gauge'

while IFS= read -r status 
do
  echo "crd_name_2{state=$(echo $status | awk '{print $2}')} $(echo $status | awk '{print $1}')"
done <<< "$crd_name_2_rec"

Скрипт складывается в конфигмап metrics-scripts и запускается так

piVersion: apps/v1
kind: Deployment
metadata:
  name: crd-exporter
spec:
  replicas: 1
  template:
    spec:
      containers:
      - image: busybox-bash-jq
        name: crd-exporter
        command:
        - /bin/sh
        - -c
        - |
          busybox httpd -vvv -f -p 9100 -h /httpd
        volumeMounts:
        - name: metrics-scripts
          mountPath: /httpd/cgi-bin
        ports:
        - containerPort: 9100
        resources:
          limits:
            memory: 128Mi
            cpu: 100m
          requests:
            memory: 128Mi
            cpu: 100m
        env:
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
      volumes:
        - name: metrics-scripts
          configMap:
            name: metrics-scripts
            defaultMode: 0744

Ну и промовские аннотации на под или сервис по вкусу

Все микросервисы создаются в рамках нашей конвенции разработки и имеют набор стандартных метрик. Эти стандартные метрики позволяют сервисам из коробки иметь базовые инструменты мониторинга: базовые алерты, базовые дашборды в Grafana.

А есть где-нибудь описание ваших стандартных метрик? Было бы любопытно посмотреть. Спасибо

У нас утвержден стандарт метрик и там много, чего написано и утверждено. Если все ужать, то можно резюмировать, что все метрики разделены на группы

1) Информация о сервисе: какой язык, какая версия и т.п.

2) Запросы к сервису. Ответы сервиса

3) Запросы и ответы в разрезе протоколов

4) Вызовы других сервисов

5) Работа с базами данных (MSSQL, PostgersSQL)

6) Работа с in-memory cache

7) Метрики брокеров сообщений

Класс, спасибо большое за ответ! А сам утвержденный стандарт, наверное, NDA? :)

Да, все что могла расписала(

Only those users with full accounts are able to leave comments. Log in, please.