Comparing Logging Solutions

Сравнивают Loki, ELK и SPLUNK.

​Посмотрите на эту картинку. Да, это из известной сказки, в которой лживый мальчик кричал «Волки! Волки!» в то время, когда волки доедали каких-то других козлят. А когда волки пришли за его козлятами — никто не прибежал с вилами на помощь.

Если из мониторинга прилетают алерты без повода через какое-то время на них перестанут реагировать. Очень много таких ситуаций возникает когда нет ответственного за мониторинг и каждая группа администраторов добавляет туда свои метрики и алерты. Ниже несколько рекомендаций, чтобы не выпускать ситуацию из под контроля.

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. Читать дальше.

​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. Узнать как это устроено.

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. Читать дальше.

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. Читать дальше.

The 10 Best Data Visualizations of 2021

Читать дальше на Медиуме.

​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.

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! Читать дальше.

​А кто-то пробовал hastic.io? Это тул для pattern and anomaly detection с UI для Grafana. Выглядит интересно.

Есть еще пара видосов с этим решением:

Выступление с докладом на Monitorama PDX 2019

и доклад на GrafanaCon LA 2019

​VictoriaMetrics: PromQL compliance

MetricsQL — это язык запросов, созданный на основе PromQL. Он используется в качестве основного языка запросов в VictoriaMetrics, базе данных временных рядов и решении для мониторинга. Считается, что MetricsQL имеет обратную совместимость с PromQL, поэтому информационные панели Grafana, поддерживаемые источником данных Prometheus, должны работать так же после переключения с Prometheus на VictoriaMetrics. Однако, VictoriaMetrics не на 100% совместим с PromQL и никогда не будет. Подробнее в этой статье.

Kubernetes monitoring от простого к сложному (Николай Храмчихин)

Разберём как при помощи VictoriaMetrics замониторить kubernetes. Откуда собирать метрики и как автоматически обнаруживать новые цели. Черная магия релейблинга и как она работает. Расшифровка и запись выступления.

smartctl_exporter для Prometheus (репыч на Гитхабе)

​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 ->

Ну и ещё, чтоб два раза не вставать.

​How to use Prometheus for anomaly detection in GitLab

One of the more basic functions of the Prometheus query language is real-time aggregation of time series data. Andrew Newdigate, a distinguished engineer on the GitLab infrastructure team, hypothesized that Prometheus query language can also be used to detect anomalies in time series data. Читать дальше в блоге Гитлаб.

​What time-weighted averages are and why you should care

Расчёт средневзвешенных по времени средних, почему они так эффективны для анализа данных и как использовать гиперфункции TimescaleDB для более быстрого расчета - и все это с использованием SQL. Читать дальше в блоге Timescale.

Каталог статей о Victoria Metrics. Возможно, найдется что-то интересное.

Мониторинг скорости интернет каналов в Zabbix

Я работаю в крупной федеральной компании, у которой более 2000 объектов. Для большинства задач необходим стабильный канал интернета с высокой скоростью. Поэтому нам необходимо было сделать систему, которая позволяет отслеживать скорость работы интернет каналов на этих объектах, и в случае проблем информировала бы нас об этом. Читать дальше на Хабре.

🔆 Успейте воспользоваться скидкой до 70% на Okmeter 🔆

@okmeter — это умный SaaS-мониторинг с готовыми дашбордами, графиками и алертами, который:
- сам находит процессы и сервисы, которые нужно замониторить: PostgreSQL, MySQL, MongoDB, RabbitMQ, Docker, NGINX и другие;
- собирает тысячи метрик с каждого хоста;
- имеет преднастроенные и продуманные алерты и дашборды для всех сервисов;
- доставляет алерты по email, SMS, в Slack, Telegram, Opsgenie, Alertmanager.

С Okmeter вообще не нужно тратить время и силы на настройку мониторинга. Просто поставьте агента Okmeter на сервер, и он все сделает за вас. Получите мощный инструмент мониторинга «из коробки», с которым решать любые задачи по observability — просто и удобно.

🔥 Первые две недели бесплатно, а на дальнейшее использование сейчас действуют крутые скидки по случаю «Черной пятницы»! Подробности: https://okmeter.io/