Nach 27 Monaten hab ich eben meinen #Thanos #PoC mit ~810 Mio Samples offline genommen, und meine Daten daraus in ein #VictoriaMetrics migriert 🥳 Aus dem PoC ist vor ein paar Monaten ein produktiver #Mimir-Cluster geworden, daher brauch ich das Setup hier zuhause nicht mehr 😇
#Daten #SmartHome
#victoriametrics — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #victoriametrics, aggregated by home.social.
-
-
Мониторинг SSRS и Power BI Report Server: дашборд для Grafana
К этой статье меня подтолкнула причина донельзя прозаическая. Сижу недавно на брифинге, и прилетает жалоба: сервер отчётов работает из рук вон плохо. Сервер при этом не мой, в орбиту обслуживания он не входил, а тут пришлось вспомнить, как оно всё устроено у SQL Server Reporting Services (SSRS), вспомнить молодость, так сказать. Вспомнил. Заодно собрал то, чего мне самому когда-то не хватало, — и решил, что пора всё это выложить в одну статью. Сервер отчётов — сервис незаметный, пока кто-нибудь из бизнеса не напишет: «а почему мне со вчерашнего дня не приходит утренняя рассылка». Сидишь, открываешь портал, видишь, что подписка вроде есть, вроде активна, а письма не уходят. Ну и как оно всегда было? Лезешь в логи, а логов нормальных нет, есть только таблица где-то внутри базы, в которую редко кто, кроме DBA, и заглядывал. Знакомо? Если вы держите SSRS или его старшего брата Power BI Report Server, наверняка знакомо. Вопросы, на которые SSRS обязан отвечать сам, звучат просто. Какие рассылки упали этой ночью и по какой причине? Какие отчёты открывают чаще всего, а какие не открывали полгода? Это обычная статистика использования отчётов, которой в портале нет. Где сервер реально упирается в ресурсы? Кто владелец подписки, которая ломается третью неделю подряд? Штатными средствами ни один из этих ответов не достаётся: портал показывает список объектов, а журнал выполнения лежит таблицей в служебной базе, без графиков поверх. Ниже — как я собрал дашборд в Grafana поверх базы ReportServer и какие грабли попались по дороге.
https://habr.com/ru/articles/1084918/
#ssrs #reporting_services #pbirs #executionlog #grafana #mssql #мониторинг #windows_exporter #victoriametrics #дашборд
-
Эволюция пайплайна метрик: как менялась архитектура с ростом нагрузки
Привет, Хабр! Я Руслан Боярский, SRE в Т-Банке, отвечаю за надежность платформы Sage и принимаю активное участие в ее развитии. Sage — это платформа наблюдаемости, где мы собираем телеметрию. И я регулярно убеждаюсь, что в ИТ мы не можем существовать без метрик. В статье рассказываю о том, как с ростом нагрузки более чем в 100 раз может меняться и развиваться система мониторинга, подходы в командах, да и в целом сами команды. Покажу ключевые эпохи развития нашей подсистемы метрик. В каждой эпохе дам контекст, архитектуру, профиль нагрузки. А еще опишу проблемы, с которыми можно столкнуться, и расскажу, как мы их решали. Попутно будет пара историй про инциденты. Поехали.
https://habr.com/ru/companies/tbank/articles/1083370/
#metrics #observability #sre #architecture #system_design #prometheus #victoriametrics #sage #openmetrics #remotewrite
-
Что будет с телеметрией, если хранилище исчезнет: сравниваем очереди и батчинг семи агентов
Когда выбирают агент для телеметрии, обычно сравнивают поддержку протоколов, потребление CPU и удобство конфигурации. Я бы начал со следующего вопроса: > Что произойдёт с данными, если хранилище перестанет отвечать на 30 минут, а потом вернётся обратно? Агент-доставщик может уметь в ретраи, персистент вольюм, но это не означает, что данные не потеряются. Ретраи должны где-то жить, а очередь должна иметь предел. После восстановления связи накопившиеся сообщения нужно выгрузить, не положив только что ожившее и еще не до конца очухавшееся хранилище. А если агент вдруг неожиданно перезапустится, очередь должна пережить и это. Меня зовут Антон Касимов, я работаю в Gals Software, веду авторский телеграм по наблюдаемости Мониторим ИТ , а в этой статье разберу семь популярных шипперов и коллекторов: OpenTelemetry Collector , Grafana Alloy , Vector , Fluent Bit , vlagent , vmagent и vtagent . Для каждого шиппера рассмотрю следующие вещи: батчинг, очередь, поведение при недоступности бэкэнда, ключевые настройки и минимальный пример конфигурации. Это не синтетический рейтинг кто быстрее, выше, сильнее. У инструментов разная специализация и разные единицы измерения. Очередь в 1000 OTLP-запросов нельзя честно сравнить с очередью в 10 ГБ или с WAL длительностью восемь часов. В проектах я сам периодически сталкиваюсь с проблемой выбора, поэтому тема для меня достаточно животрепещуща. Возможно, она окажется такой и для вас.
https://habr.com/ru/articles/1082872/
#галс_софтвэр #gals_software #opentelemetry #alloy #fluentbit #observability #victoriametrics #victorialogs #victoriatraces
-
VictoriaMetrics: Drop-In Prometheus Replacement? — hands-on guide for sysadmins. #observability #prometheus #victoriametrics
https://www.valtersit.com/guides/monitoring/victoriametrics-drop-in-prometheus-replacement/
-
Как устроен IPMI-мониторинг серверов: сбор метрик и интеграция с Grafana
Инфраструктура Selectel насчитывает тысячи серверов, которые круглосуточно обеспечивают работу клиентских проектов: процессоры обрабатывают инструкции, память хранит данные, диски читают и записывают информацию. Такая постоянная нагрузка заложена в архитектуру оборудования, но риски сбоев — будь то аппаратные ошибки, перегрев, сбои питания или проблемы с сетью — есть всегда. В случае нештатной ситуации инженеры быстро восстановят работу. Однако лучше обнаружить проблему еще до того, как она затронет клиентскую инфраструктуру. Именно для этого существует IPMI-мониторинг — своего рода приборная панель сервера, которая показывает состояние оборудования и помогает замечать первые признаки возможных неисправностей. В этой статье расскажем, что такое IPMI-мониторинг серверов и рассмотрим принцип его работы. Также посмотрим, как настроить IPMI-мониторинг
https://habr.com/ru/companies/selectel/articles/1081096/
#selectel #ipmi #мониторинг #bmc #grafana #grafanaдашборд #серверы #алертинг #victoriametrics #мониторинг_сервера
-
Prometheus и VictoriaMetrics: почему одни и те же метрики могут занимать в 139 раз больше места
Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске. Обе системы делают одно и то же: принимают миллионы точек в минуту, хранят их месяцами и быстро отдают в алерты и дашборды. Обе сжимают точку до байтов и долей байта. Именно эти байты, умноженные на миллиарды точек в сутки, превращаются в счёт за диск. Ошибка в расчёте цены сэмпла заканчивается переполненным диском под мониторингом, урезанным retention или незапланированным расходом. Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 ( разбор на Habr ), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir ( бенчмарк VictoriaMetrics , замер вендора, 2022 год). На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.
https://habr.com/ru/companies/vk/articles/1068798/
#vk_cloud #prometheus #victoriametrics #time_series #tsdb #мониторинг #метрики #observability #сжатие_данных #cardinality
-
Публичное демо без регистрации: как показать живой мониторинг и не подставиться
Самый частый вопрос на первом контакте звучит одинаково у всех: «А можно просто посмотреть, как это выглядит?» Ответов на него обычно два, и оба плохие. Первый — созвон с демонстрацией экрана: полчаса моего времени и полчаса чужого ради того, чтобы человек понял, что ему это не нужно. Второй — форма «оставьте телефон, и мы покажем»: она отсеивает ровно тех, кто пришёл посмотреть без обязательств, то есть почти всех. Третий вариант — выложить работающий стенд наружу и дать ссылку без регистрации. Звучит просто ровно до момента, когда начинаешь считать, что именно ты выкладываешь: чужие данные, структуру своих дашбордов, доступ к хранилищу метрик и счёт за трафик. Ниже — что из этого оказалось настоящей проблемой, что мифом, какие ограничения у публичных дашбордов Grafana и почему собственная защита от абуза первым делом ударила по моим же посетителям. Стенд, о котором речь: девять дашбордов реальной платформы, синтетическая «розничная сеть», обновление раз в 30 секунд, вход без учётной записи.
https://habr.com/ru/articles/1078300/
#grafana #dashboard #prometheus #victoriametrics #devops #observability #kubernetes #docker #1c #infrastructure
-
VictoriaMetrics is very well done, high performance, frugal in resource usage, operator-friendly log messages, operator-friendly error messages, an helping community. I am very satisfied.
> Follow a single metric through its whole life inside VictoriaMetrics: born as a counter in your process, exported over the wire, given an identity and an inverted-index entry, written through an LSM tree, compressed into columnar blocks on disk, read back by a rate() query, downsampled as it ages, and finally deleted when retention runs out.
-
Saatnya mempertimbangkan ulang untuk kembali ke #prometheus. Terlalu banyak magic yang tidak terprediksi dan tidak dapat diatur di #victoriametrics.
-
Я ломал свою платформу мониторинга. Первым сломалось не то, что я тестировал
Я в одиночку делаю и эксплуатирую платформу мониторинга: метрики, логи и трейсы для чужой инфраструктуры, мультитенантно, на VictoriaMetrics cluster / VictoriaLogs / VictoriaTraces, FastAPI, nginx и Postgres. Прод — один сервер: Debian 12, 4 CPU, 8 ГБ, четырнадцать контейнеров. За несколько месяцев эксплуатации у меня накопилось десятка полтора отказов под нагрузкой. Ни один из них не был найден классическим нагрузочным тестом. Все — найдены постфактум, по логам, по счётчику рестартов контейнеров и по панели трафика у хостера. Это статья не про то, «как правильно проводить НТ» — таких статей достаточно. Она про то, какие именно виды нагрузки ломают систему приёма телеметрии, почему привычный сценарий «загоним 1000 rps через k6 и посмотрим на перцентили» проходит мимо всех трёх, и как выглядит воспроизводимый прогон, который эти отказы ловит. Все цифры ниже — с живого сервера, не синтетика.
https://habr.com/ru/articles/1076348/
#vmagent #vector #fluent_bit #victoriametrics #observability
-
Одно кривое правило — и алертинг лёг всем тенантам: анатомия отказа vmalert в мультитенантной платформе
Я строю мультитенантную платформу мониторинга на стеке VictoriaMetrics + Grafana + vmalert: у каждого клиента — изолированный tenant в хранилище и собственный набор правил алертинга, которые он редактирует через личный кабинет. Расскажу про два сцепленных инцидента, которые изменили моё понимание изоляции тенантов, — с конкретными числами, конфигами и кодом фиксов. Спойлер: изолировать данные — этого мало.
https://habr.com/ru/articles/1076162/
#observability #victoriametrics #grafana #мультитенантность #alertmanager
-
Radar: Kubernetes UI, которого не хватало
У каждого, кто работает с Kubernetes, рано или поздно возникает потребность «посмотреть на кластер глазами»: кто с кем связан, почему под в CrashLoopBackOff, что изменилось за ночь, какие сертификаты истекают. Вариантов обычно два — Kubernetes Dashboard (слишком бедный) или Lens / Headlamp (десктопное приложение или тяжёлый стек с зависимостями). А kubectl-специалисты откапывают причины инцидентов в простынях YAML, где сигнал тонет в managedFields и status.conditions . Radar — open-source UI для Kubernetes от Skyhook (YC W23). Один бинарник на Go, без регистрации и аккаунта, бесплатный навсегда. Топология кластера, браузер ресурсов, timeline событий, менеджер Helm-релизов, GitOps для FluxCD , карта трафика, аудит безопасности, анализ impact'а перед апгрейдом K8s и даже встроенный MCP-сервер, чтобы ИИ-агенты могли смотреть кластер глазами Radar вместо сырого kubectl. В этой статье мы развернём Radar в Yandex Managed Kubernetes через Helm — с ingress-nginx и доменом из публичного IP — и разберём все основные экраны. Разворачиваемый инстанс — общий для команды разработчиков, поэтому конфигурация строго read-only: все write-права выключены, ИИ-агенты подключаются к read-only MCP.
https://habr.com/ru/articles/1073566/
#Radar #Kubernetes_UI #OpenCost #VictoriaMetrics #Hubble #Cilium #RBAC #MCP #топология_кластера #Kubernetes_Observability
-
Started playing with #VictoriaMetrics , wrote a blog post about how I deployed it:
-
today I did https://codeberg.org/AstraLuma/victoria-apt
It's kind of a hack job, but now I can have the entire victoria suite through apt.
-
@sakeudeung sepakat. #VictoriaMetrics emang cocoknya cuma kalau pengen irit saja
-
@adhisimon kebanyakan drama gak jujur itu dokumentasi #victoriametrics.
Nama parameter banyak mengecoh dan limitasi-limitasi gak ditulis di doc, cuma dibahas dan dibiarin terkubur di issue aja.
Makanya gak jadi replacement de-facto nya #prometheus dia. Kalo mau cari aman dan stabil mending tetap di prometheus walau RAM nya lumayan boros.
Kalo #mimir mending. Dia janji apa adanya. Gak nawarin macam-macam cuma janjiin long time storage buat timeseries.
