Мы два года развивали свою систему мониторинга. Кликай, чтобы…31.10.2019 11:35

Всем привет!
Я уже рассказывал в этом блоге об организации модульной системы мониторинга для микросервичной архитектуры и о переходе с Graphite+Whisper на Graphite+ClickHouse для хранения метрик в условиях высоких нагрузок. После чего мой коллега Сергей Носков писал о самом первом звене нашей системы мониторинга — разработанном нами Bioyino, распределённом масштабируемом агрегаторе метрик.

Пришло время немного освежить информацию о том как мы готовим мониторинг в Авито — последняя наша статья была аж в далеком 2018 году, и за это время было несколько интересных изменений в архитектуре мониторинга, управлении триггерами и нотификациями, различные оптимизации данных в ClickHouse и прочие нововведения, о которых я как раз и хочу вам рассказать.

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

В далеком 2017 я показывал схему взаимодействия компонентов, актуальную на тот момент, и хотел бы продемонстрировать её еще раз, дабы вам не пришлось лишний раз переключаться по вкладкам.

С того момента произошло следующее.

• Количество серверов в кластере Graphite выросло с 3 до 6.
  (56 CPU 2.60GHz, 384GB RAM, 10 SSD SAS 745GB, Raid 6, 10GBit/s Net).

  
  

• Мы заменили brubeck на bioyino — нашу собственную имплементацию StatsD на Rust, и даже целую статью про это написали. Правда, после выхода статьи мы подвезли в него поддержку тегов (Graphite) и Raft для выбора лидера.

  
  

• Мы проработали возможность использовать bioyino в качестве StatsD-агента и разместили такие агенты рядом с инстансами монолита, а также там, где это было необходимо в k8s.

  
  

• Мы наконец-то избавились от старой системы мониторинга Munin (формально она у нас ещё есть, но её данные уже нигде не используются).

  
  

• Сбор данных из кластеров Kubernetes был организован через Prometheus/Federations, так как Heapster в новых версиях Kubernetes не поддержали.

  
  

За два прошедших года количество принимаемых и обрабатываемых метрик выросло примерно в 9 раз.

Процент занимаемого места на серверах также неумолимо ползёт вверх, и мы предпринимаем различные шаги по его понижению. Это хорошо видно на графике.

Что именно мы делаем?

10 10 10 * * clickhouse-client -q "select distinct partition from system.parts where active=1 and database='graphite' and table='data' and max_date between today()-55 AND today()-35;" | while read PART; do clickhouse-client -u systemXXX --password XXXXXXX -q "OPTIMIZE TABLE graphite.data PARTITION ('"$PART"') FINAL";done

• Мы расшардировали таблицы с данными. Теперь у нас три шарда по две реплики в каждом с ключом шардирования по хэшу от имени метрики. Такой подход дает нам возможность производить rollup процедуры, так как все значения по конкретной метрике находятся в пределах одного шарда, а дисковое пространство на всех шардах утилизируется равномерно.

Схема Distributed таблицы выглядит следующим образом.

CREATE TABLE graphite.data_all (
`Path` String, 
`Value` Float64, 
`Time` UInt32, 
`Date` Date, 
`Timestamp` UInt32
) 
ENGINE = Distributed (
'graphite_cluster',
'graphite',
'data', 
jumpConsistentHash(cityHash64(Path), 3)
) 

Мы также назначили пользователю «default» readonly-права и перекинули выполнение процедур записи в таблицы на отдельного пользователя systemXXX.

Конфигурация кластера Graphite в ClickHouse выглядит следующим образом.

    
        
            
                true
                
                    graphite-clickhouse01
                    9000
                    systemXXX
                    XXXXXX
                
                
                    graphite-clickhouse04
                    9000
                    systemXXX
                    XXXXXX
                
            
            
                true
                
                    graphite-clickhouse02
                    9000
                    systemXXX
                    XXXXXX
                
                
                    graphite-clickhouse05
                    9000
                    systemXXX
                    XXXXXX
                
            
            
                true
                
                    graphite-clickhouse03
                    9000
                    systemXXX
                    XXXXXX
                
                
                    graphite-clickhouse06
                    9000
                    systemXXX
                    XXXXXX
                
            
        
    

Помимо нагрузки на запись, выросло количество запросов на чтение данных из Graphite. Эти данные используются для:

• обработки триггеров и формирования алертов;
• отображения графиков на мониторах в офисе и экранах ноутбуков и ПК растущего числа сотрудников компании.

Чтобы мониторинг не утонул под этой нагрузкой, мы использовали ещё один хак: данные за последние два дня мы храним в отдельной «маленькой» табличке, и все читающие запросы за последние два дня мы отправляем туда, снижая нагрузку на основную шардированную таблицу. Так же для этой «маленькой» таблички мы применили реверсивную схему хранения метрик, что значительно ускорило поиск находящихся в ней данных и организовали для неё дневное партиционирование. Cхема этой таблички выглядит следующим образом.

CREATE TABLE graphite.data_reverse (
`Path` String, 
`Value` Float64, 
`Time` UInt32 CODEC(Delta(4), ZSTD(1)),
 `Date` Date, 
`Timestamp` UInt32
) 
ENGINE = ReplicatedGraphiteMergeTree (
'/clickhouse/tables/{cluster}/data_reverse', 
'{replica}', 
'graphite_rollup'
) PARTITION BY Date 
ORDER BY (Path, Time) 
SETTINGS index_granularity = 4096

Чтобы направлять в неё данные, мы добавили в конфигурационный файл приложения carbon-clickhouse новую секцию.

[upload.graphite_reverse]
type = "points-reverse"
table = "graphite.data_reverse"
threads = 2
url = "http://systemXXX:XXXXXXX@localhost:8123/"
timeout = "60s"
cache-ttl = "6h0m0s"
zero-timestamp = true

Чтобы удалять партиции старше двух дней, мы написали задание cron. Оно выглядит примерно так.

1 12 * * * clickhouse-client -q "select distinct partition from system.parts where active=1 and database='graphite' and table='data_reverse' and max_date

[[data-table]]
table = "graphite.data_reverse"
max-age = "48h"
reverse = true