или что у него там в потрохах

жава, да.

у меня такой вопрос: можно ли в графане положить колонками несколько отчётов рядом?

Есть у меня например набор из 12 графиков, по графику на строку. Хочу сделать 3 колонки, но поменять там значения переменных

span + height?

Не, я не хочу делать руками копии графиков

Я хочу вставить в колонку целиком отчёт

Можно скопировать JSON графика и вставить в новый

:(

И потом менять каждый раз?

Можно самому заполнять grafana.db, если надо автоматизировано собирать дашборды.

не знаете как удалить лишние time series по instance или group через https://prometheus.io/docs/querying/api/ , как я понимаю можно удалить все только по job ?

а во нашел как удалять лишние time series в prometheus через API , может кому понадобиться curl -XDELETE -g 'http://localhost:9090/api/v1/series?match[]={job="node",group="testing"}'

наконец-то разобрался как в новом телеграфе собрать cisco-cbqos. по сравнению со старым стало немного сложнее, но логичнее. и да, в influxdb

народ как правильно называется и с помощью чего сделать логирвоание времени появления события в различных частях системы? Например приходит сообщение, я задаю ему uuid и везде в логах при обработке пишу этот uuid, вот как мне собрать графики по отдельным этапам обработки?

интересует как собирать и внутри одного модуля, так и в другом модуле, например после передачи через очереди

привет, кто нибудь настраивал tls_config для prometheus?

я настраивала, просто указывала cert_file и key_file

и insecure_skip_verify

ок, я тоже так сделал, но не работает

У меня работает)

tls_config идет для job_name , у меня например в job_name несколько targets , получается сертификаты эти настроиваются отдельно на каждый endpoint?

или это должны быть сертификаты, которые например в нгинкc указаны для сервера prometheus?

Насчет нескольких target не проверяла, у меня в каждой job один target только

да, но я так понимаю что сертификаты то должны указываться для endpoint те на те хосты которые в targets прописаны, если сертификаты разные то тогда они наверно должны разделется по job_name и должен быть 1 target

у меня prometheus в targets пишет следущее: Get https://yourhostname:443/metrics: x509: certificate signed by unknown authority при этом insecure_skip_verify: true

локальный node_exporter пишет Get https://localhost:9090/metrics: http: server gave HTTP response to HTTPS client

у менч также insecure_skip_verify: true, и еще вот scheme: https

а nginx используется?

нет

во у меня заработало )

https://localhost? но зачем?

https://localhost? но зачем?

да это я пробовал, я вернул на http

а для чего нужно : labels: group: 'example' в prometheus?

со всем недостатками нового snmp плагина для телеграфа я очень доволен в итоге. получилось лучше, проще, быстрее чем все мои предыдущие попытки мониторить cbqos. ниже картинка мониторинга класса video на циске. класс висит в нескольких политиках на нескольких интерфейсах. по политикам группировка.

Метриканы, а какой подход считается рассово верным когда у меня есть очень много источников метрик? (сервера/коллекции в монге/ и всё такое). Что прометей, что графана не очень хорошо переживают когда ты пытаешься сразу всё на одном дешборде показать (10 графиков в итоге показывают около 500 метрик).

Я тут сейчас сам с собой поговорю, корочи.

Начать наверное надо с вопроса нахуя оно всё надо, да?

Логично что график должен показать условно насколько всё хорошо (лучше, как обычно, хуже).

И как следствие дать быстро понять кто именно стал причиной того что «хорошесть» метрики изменилась.

В целом согласен

Но и даши тогда надо делать такими, чтобы регистрировались именно отклонения

Да-да.

Эдакий визуальный алертинг

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

Что с сетью

Но теперь смешное: на каждый из серверов у меня на каждую метрику уже будет алерт

Тоесть если кто-то конркретно насрал, я об этом узнаю с именем и мне не надо смотреть на графики.

Зачем мне тогда смотреть на графики?

А это не смешно. Просто агент может быть совмещенным

И графики лишь дополняют алерты

А вот зачем: пришел алерт что в субд что-то не так. Например просел qps

И больше ничего.

И тут начинается игра: почему тормозит субд.

игра ))

Ну а чо. Детективный роман. Найди пидора

это помойму уже другой вопрос почему тормозит субд

На этот вопрос мне графики и должны помочь найти ответ.

Иначе нахуя они нужны?

Например если мы мониторим queries per second, то тут есть несколько векторов развития событий: 1) Выросла нагрузка, мы упёрлись в ресурсы, всё встало раком 2) Нагрузка упала сама по себе

Именно. Графики фактически помогут понять, какой из влертов не сработал

Первое что всегда надо исключать это 2). Потому что это могли катануть кривой релиз

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

Или не лежит ;)

Тут, наверное, должен быть алерт по нулевой нагрузке?

ERROR: S client not available

Первое что всегда надо исключать это 2). Потому что это могли катануть кривой релиз

а тестов нет?

а тестов нет?

А срать вообще. Чёрный ящик

Этр уже из девопсовских практик

Потом тесты тоже люди пишут, это всё хуйня.

Быват что катают новую фичу, а там кнопку подвинули и пользователи её не видят теперь. И всё.

Потом тесты тоже люди пишут, это всё хуйня.

но все равно можно свести к минимумы кривые релизы

но все равно можно свести к минимумы кривые релизы

Мне не интересно об этом думать, потому что это не моя зона отвественности.

Это чёрный ящик. Зачем мне его колупать отвёрткой?

Prod-like staging хорошее подспорье

ну да я имел ввиду тесты проходят где нить на стейдже , если есть косяки то в прод ничего не идет и разработчик или кто там изменения делал это увидит

И по аналогии с черным ящиком скорее напрашивается запихивание в него всякой дряни

Вы это, чот наивные очень

Когда всё хорошо работает, никому мониторинг не нужен.

Мониторинг нужен когда всё пошло по пизде, чтоб быстро найти что именно пошло по пизде. Закон мёрфи же.

Всё делают люди, у вас могут быть какие угодно процедуры, но с вероятностью 100% у вас что-то пойдёт по пизде

А алертинг для чего тогда?

Алертинг тебе скажет: пошло по пизде

Он же должен сказать, что именно. Иначе ему грош цена

А почему пошло-то?

Окей, трафик пошел по пизде.

Как тебе алертинг причину скажет?

Никак не скажет.

По крайней мере сейчас. Через года полтора ML будет точно говорить почему.

Простой пример с dyn. У тебя просто нет больше днс :)

что то не понимаю я связи алертинга с тем что ты хочешь

Я не алертинг хочу, я хочу понять что надо на графиках рисовать

Хмык. Очень абстрактно, на мой вкус. Алертинг следит за входами и выходами каждого компонента.

возьми готовые дашборды

Метриканы, а какой подход считается рассово верным когда у меня есть очень много источников метрик? (сервера/коллекции в монге/ и всё такое). Что прометей, что графана не очень хорошо переживают когда ты пытаешься сразу всё на одном дешборде показать (10 графиков в итоге показывают около 500 метрик).

показывай только то что нужно, фильтруй данные. Врядли тебе интересен cpu usage всех, а вот топ эн с highest Current или highest Average скорее всего интересен.

Алертинг это другая история совсем, с ним @tnt4brain почему-то лезет

Ибо ты его задачи натягиваешь на мониторинг

показывай только то что нужно, фильтруй данные. Врядли тебе интересен cpu usage всех, а вот топ эн с highest Current или highest Average скорее всего интересен.

Какое простое правило для оценки можно придумать для случайной метрики?