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) Метрики брокеров сообщений
Для мониторинга CronJob в Kubernetes нужен простой советский…