Мониторинг электросчетчиков за один вечер
Имеется 25 счетчиков электроэнергии Меркурий 236 ART, объединенных сетью RS485 для дистанционного получения данных. Появилась задача - как можно скорее организовать мониторинг состояния приборов учета и в автоматическом режиме сохранять значения накопленной ими энергии. Посмотреть как это сделать в Zabbix.
Имеется 25 счетчиков электроэнергии Меркурий 236 ART, объединенных сетью RS485 для дистанционного получения данных. Появилась задача - как можно скорее организовать мониторинг состояния приборов учета и в автоматическом режиме сохранять значения накопленной ими энергии. Посмотреть как это сделать в Zabbix.
Поздравляю коллег из Amixr.io с присоединением к команде Grafana! Grafana OnCall доступна в бете для платных и бесплатных пользователей Grafana Cloud.
Подробнее можно узнать на вебинаре Deep dive into the Grafana, Prometheus, and Alertmanager stack for alerting and on-call management
Подробнее можно узнать на вебинаре Deep dive into the Grafana, Prometheus, and Alertmanager stack for alerting and on-call management
Grafana Labs
Announcing Grafana OnCall, the easiest way to do on-call management | Grafana Labs
The new on-call management tool is available in beta preview for Grafana Cloud users with both free and paid plans.
Обратите внимание на интересные репозитории компании Monitoring Artist на гитхабе. Среди них были обнаружены:
- Контейнер с Grafana со всеми преинсталлированными публичными плагинами
- Инструментарий для стресс-тестов Zabbix-агента и Zabbix-сервера
- Веб-приложение для работы с Zabbix-API
Некоторые репозитории давно не обновлялись и может потребоваться допиливание под современные версии Zabbix.
- Контейнер с Grafana со всеми преинсталлированными публичными плагинами
- Инструментарий для стресс-тестов Zabbix-агента и Zabbix-сервера
- Веб-приложение для работы с Zabbix-API
Некоторые репозитории давно не обновлялись и может потребоваться допиливание под современные версии Zabbix.
Посмотрите на эту картинку. Да, это из известной сказки, в которой лживый мальчик кричал «Волки! Волки!» в то время, когда волки доедали каких-то других козлят. А когда волки пришли за его козлятами — никто не прибежал с вилами на помощь.
Если из мониторинга прилетают алерты без повода через какое-то время на них перестанут реагировать. Очень много таких ситуаций возникает когда нет ответственного за мониторинг и каждая группа администраторов добавляет туда свои метрики и алерты. Ниже несколько рекомендаций, чтобы не выпускать ситуацию из под контроля.
1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.
2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.
3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».
4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.
5️⃣ Этот список не означает, что нужно собирать только минимальный набор ключевых метрик. Нужно собирать их как можно больше и различными технологиями (встривание в код, синтетические транзакции, анализ трафика и т.д.). Важно отключить генерацию событий и оповещения на то, на что некому реагировать.
6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.
7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).
Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.
Если из мониторинга прилетают алерты без повода через какое-то время на них перестанут реагировать. Очень много таких ситуаций возникает когда нет ответственного за мониторинг и каждая группа администраторов добавляет туда свои метрики и алерты. Ниже несколько рекомендаций, чтобы не выпускать ситуацию из под контроля.
1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.
2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.
3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».
4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.
5️⃣ Этот список не означает, что нужно собирать только минимальный набор ключевых метрик. Нужно собирать их как можно больше и различными технологиями (встривание в код, синтетические транзакции, анализ трафика и т.д.). Важно отключить генерацию событий и оповещения на то, на что некому реагировать.
6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.
7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).
Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.
Monitor Consul using Prometheus and Grafana
Consul is a service discovery tool for allowing services or VMs to be registered and then provide dns and http interfaces to query on the state of registered services/VMs. Читать дальше.
Consul is a service discovery tool for allowing services or VMs to be registered and then provide dns and http interfaces to query on the state of registered services/VMs. Читать дальше.
Medium
Monitor Consul using Prometheus and Grafana
Consul is a service discovery tool for allowing services or VMs to be registered and then provide dns and http interfaces to query on the…
PLG (Promtail, Loki, Grafana) stack for apps monitoring
PLG stack refers to Promtail, Loki and Grafana. Promtail extracts and collects logs from docker containers log files and pushes them to the Loki service which then Grafana uses to show logs in the log panel. Узнать как это устроено.
PLG stack refers to Promtail, Loki and Grafana. Promtail extracts and collects logs from docker containers log files and pushes them to the Loki service which then Grafana uses to show logs in the log panel. Узнать как это устроено.
irate() vs rate() — What’re they telling you?
Prometheus makes available great functions for data aggregation by timeline. Among these functions, I focused my analysis on irate() and rate() which give us similar outcomes but they work in different way. Читать дальше.
Prometheus makes available great functions for data aggregation by timeline. Among these functions, I focused my analysis on irate() and rate() which give us similar outcomes but they work in different way. Читать дальше.
Medium
irate() vs rate() — What’re they telling you?
Prometheus makes available great functions for data aggregation by timeline. Among these functions, I focused my analysis on irate() and…
Pushing K8s Cluster Logs to S3 Bucket using Fluentd
Storing logs on Elastic search can be very costly, both in terms of cost as well as in terms of time when you’re trying to retrieve them back. So, to save cost, we started sending our Kubernetes cluster logs to AWS S3 bucket, where we would store them for 6 months while keeping the log’s retention policy on Elastic search to only 1 month. Читать дальше.
Storing logs on Elastic search can be very costly, both in terms of cost as well as in terms of time when you’re trying to retrieve them back. So, to save cost, we started sending our Kubernetes cluster logs to AWS S3 bucket, where we would store them for 6 months while keeping the log’s retention policy on Elastic search to only 1 month. Читать дальше.
Medium
Pushing K8s Cluster Logs to S3 Bucket using Fluentd
By Prakarsh. Prakarsh handles DevOps at Devtron. He has experience in running TechOps and customer excellence for the B2B vertical of the…
Kubermetrics — Cluster Visualization Made Simple
Kubermetrics is an open-source dev tool that provides Kubernetes cluster monitoring as well as data visualization in a simple and easy to understand user interface. Узнать больше о Kubemetrics.
Kubermetrics is an open-source dev tool that provides Kubernetes cluster monitoring as well as data visualization in a simple and easy to understand user interface. Узнать больше о Kubemetrics.
Prometheus, but bigger
"Pure" OpenTSDB installations demanded too much work and attention, Standalone Prometheus did not offer replication and I would end up with multiple databases, TimeScaleDB looked nice, but I am no Postgres administrator.
After some experimentation with the above solutions, I looked to the CNCF website for more options and found Thanos! It ticked all the right boxes: Longtime retention, Replication, High Availability, microservice approach, and global view for all my clusters using the same database! Читать дальше.
"Pure" OpenTSDB installations demanded too much work and attention, Standalone Prometheus did not offer replication and I would end up with multiple databases, TimeScaleDB looked nice, but I am no Postgres administrator.
After some experimentation with the above solutions, I looked to the CNCF website for more options and found Thanos! It ticked all the right boxes: Longtime retention, Replication, High Availability, microservice approach, and global view for all my clusters using the same database! Читать дальше.
Medium
Prometheus, but bigger
Achieving kubernetes multi cluster monitoring
А кто-то пробовал hastic.io? Это тул для pattern and anomaly detection с UI для Grafana. Выглядит интересно.
Есть еще пара видосов с этим решением:
Выступление с докладом на Monitorama PDX 2019
и доклад на GrafanaCon LA 2019
Есть еще пара видосов с этим решением:
Выступление с докладом на Monitorama PDX 2019
и доклад на GrafanaCon LA 2019
VictoriaMetrics: PromQL compliance
MetricsQL — это язык запросов, созданный на основе PromQL. Он используется в качестве основного языка запросов в VictoriaMetrics, базе данных временных рядов и решении для мониторинга. Считается, что MetricsQL имеет обратную совместимость с PromQL, поэтому информационные панели Grafana, поддерживаемые источником данных Prometheus, должны работать так же после переключения с Prometheus на VictoriaMetrics. Однако, VictoriaMetrics не на 100% совместим с PromQL и никогда не будет. Подробнее в этой статье.
MetricsQL — это язык запросов, созданный на основе PromQL. Он используется в качестве основного языка запросов в VictoriaMetrics, базе данных временных рядов и решении для мониторинга. Считается, что MetricsQL имеет обратную совместимость с PromQL, поэтому информационные панели Grafana, поддерживаемые источником данных Prometheus, должны работать так же после переключения с Prometheus на VictoriaMetrics. Однако, VictoriaMetrics не на 100% совместим с PromQL и никогда не будет. Подробнее в этой статье.
Kubernetes monitoring от простого к сложному (Николай Храмчихин)
Разберём как при помощи VictoriaMetrics замониторить kubernetes. Откуда собирать метрики и как автоматически обнаруживать новые цели. Черная магия релейблинга и как она работает. Расшифровка и запись выступления.
Разберём как при помощи VictoriaMetrics замониторить kubernetes. Откуда собирать метрики и как автоматически обнаруживать новые цели. Черная магия релейблинга и как она работает. Расшифровка и запись выступления.
Хабр
Kubernetes monitoring от простого к сложному (Николай Храмчихин)
Разберём как при помощи VictoriaMetrics замониторить kubernetes. Откуда собирать метрики и как автоматически обнаруживать новые цели. Черная магия релейблинга и как она работает. Аннотации для...
What is ClickHouse, how does it compare to PostgreSQL and TimescaleDB, and how does it perform for time-series data? Ключевые отличия Clickhouse и PostgreSQL c TimescaleDB.
В статье:
⚡️What is ClickHouse (including a deep dive of its architecture)
⚡️How does ClickHouse compare to PostgreSQL
⚡️How does ClickHouse compare to TimescaleDB
⚡️How does ClickHouse perform for time-series data vs. TimescaleDB
Читать в блоге Timescale ->
В статье:
⚡️What is ClickHouse (including a deep dive of its architecture)
⚡️How does ClickHouse compare to PostgreSQL
⚡️How does ClickHouse compare to TimescaleDB
⚡️How does ClickHouse perform for time-series data vs. TimescaleDB
Читать в блоге Timescale ->
