Ну это не так много, учитывая матрицу совместимости агент-хранилище.
Statsd не совсем агент, collectd сильно отстает от современного уровня детализации метрик, штуки от ES по-факту не метрики выплевывают, а сырые события, которые только в ES и ложатся, итд.
Мы обычно расширяем функционал по запросам пользователей. Думается, что сделать метрики по GC ruby/rails можно без спец поддержки конкретных технологий, у нас есть очень много способов получать кастомные метрики. Регистрируйте проект, пишите в саппорт, обязательно что-то придумаем:)
По-моему никак. Идеологически: нужно взять список своих listen сокетов и про все остальные вычислять, есть ли там хотя бы с одной стороны ваш listen. Если есть — сокет входящий, нет — исходящий
Я не считаю такую реализацию getNow ошибкой. На баг похоже только то, как просочилась запись с битым таймстампом, но для тикета у нас нет никакой диагностической информации, если появится — обязательно сделаем.
Значения в базе не перебираются. Для каждой таблицы есть не очень большое количество sstable (файлов с данными), для каждого файла в заголовке есть метадата (в том числе минимальный и максимальный таймстамп записей). С точки зрения ресурсов это вычисление не очень дорогое. Почему реализовано именно так сложно сказать, так как отвязаться от локального времени на сервере все равно не получится в случае если timestamp проставляется кассандрой.
нода: 4 ядра/32Гб/2x300Gb ssd + 2x3Tb sata
конфиг jvm стандартный кассандровский (они кстати очень тщательно это продумывают, можно тикеты в jira почитать)
syn queue: насколько я понимаю нельзя посмотреть текущий размер, но при переполнении увеличивается счетчик netstat -st |grep TCPBacklogDrop. Я могу ошибаться, нужно повнимательнее почитать примерно тут
Особенно хорошо все эти проблемы закрывают облака типа google app engine, но там много своих проблем (они тоже падают и иногда надолго, есть задержки при работе с datastore, которые для некоторых задач очень сложно обходить). Выбор технологий/решений — всегда баланс
Это было при ситуацию с 1 мастер + 1 слэйв. Еще раз, автоотработку проблем с мастером сделать можно, но это дорого (если не забыть ничего посчитать).
Наверное стоило назвать доклад «Отказоустойчивость для бедных» :)
Я как раз ровно про это и говорил. Мне например очень не хочется разбираться как работает та же mnesia под нагрузкой, какие у нее краевые случаи, в каких случаях какие данные могут потеряться итд. Или взять к примеру kafka — тут тоже все сложно (прочитать по диагонали документацию недостаточно, увы). Я призывал в своем докладе пробовать решать задачу на уровне, где у вас больше компетенции — например на уровне клиента сервиса очередей. В этом случае можно относиться к сервису очередей как к ресурсу, который может в любой момент отказать, тогда обычно можно достаточно легко это обойти (не всегда, но в большинстве задач)
Во-первых стоит понимать, что это был обзорный доклад для тех, у кого грубо говоря 1 сервер.
Про vrrp: обычно провайдеры дают отдельный vlan на каждого клиента, тогда с ним нет проблем никаких (но всегда стоит уточнять).
Переключение мастера можно сделать на автомате, никто не спорит, но есть много подводных камней про флапы, время на заливку слэйва с нового мастера итд (особенно они заметны на больших базах). Я придерживаюсь мнения, что убить N человекомесяцев на отладку автопереключения для многих нецелесообразно, а без этого процедура остается очень стремной.
О каком клиенте идет речь? Я рассказывал о нашем мониторинговом агенте, который ставится на сервера клиентов и собирает метрики. Агент в данный момент не opensource.
Ну это не так много, учитывая матрицу совместимости агент-хранилище.
Statsd не совсем агент, collectd сильно отстает от современного уровня детализации метрик, штуки от ES по-факту не метрики выплевывают, а сырые события, которые только в ES и ложатся, итд.
Мы обычно расширяем функционал по запросам пользователей. Думается, что сделать метрики по GC ruby/rails можно без спец поддержки конкретных технологий, у нас есть очень много способов получать кастомные метрики. Регистрируйте проект, пишите в саппорт, обязательно что-то придумаем:)
у нас есть тариф "Hacker" для проектов с 1 сервером, стоит 1$/месяц (это почти бесплатно)
Приятно слышать, что мы полезны:) Cпасибо!
По-моему никак. Идеологически: нужно взять список своих listen сокетов и про все остальные вычислять, есть ли там хотя бы с одной стороны ваш listen. Если есть — сокет входящий, нет — исходящий
Я не считаю такую реализацию getNow ошибкой. На баг похоже только то, как просочилась запись с битым таймстампом, но для тикета у нас нет никакой диагностической информации, если появится — обязательно сделаем.
Значения в базе не перебираются. Для каждой таблицы есть не очень большое количество sstable (файлов с данными), для каждого файла в заголовке есть метадата (в том числе минимальный и максимальный таймстамп записей). С точки зрения ресурсов это вычисление не очень дорогое. Почему реализовано именно так сложно сказать, так как отвязаться от локального времени на сервере все равно не получится в случае если timestamp проставляется кассандрой.
нода: 4 ядра/32Гб/2x300Gb ssd + 2x3Tb sata
конфиг jvm стандартный кассандровский (они кстати очень тщательно это продумывают, можно тикеты в jira почитать)
Да, это ошибка, но в целом результат будет примерно тот же. К сожалению сейчас нет под рукой сервера с большим количеством соединений.
Stacked areas позволяют оценить сумму сразу и часто значительные изменения получаются нагляднее. Хотя конечно вкусовщина это все =)
Мы используем самописное решение поверх cassandra. В плане метрик и выражений на prometheus похоже, да.
syn queue: насколько я понимаю нельзя посмотреть текущий размер, но при переполнении увеличивается счетчик
netstat -st |grep TCPBacklogDrop. Я могу ошибаться, нужно повнимательнее почитать примерно тутaccept queue: можно смотреть в netstat/ss для LISTEN сокетов, текущий размер в колонке Recv-Q, лимит в колонке Send-Q, например:
для этого сокета текущий размер = 0, лимит 128
Наверное стоило назвать доклад «Отказоустойчивость для бедных» :)
Про vrrp: обычно провайдеры дают отдельный vlan на каждого клиента, тогда с ним нет проблем никаких (но всегда стоит уточнять).
Переключение мастера можно сделать на автомате, никто не спорит, но есть много подводных камней про флапы, время на заливку слэйва с нового мастера итд (особенно они заметны на больших базах). Я придерживаюсь мнения, что убить N человекомесяцев на отладку автопереключения для многих нецелесообразно, а без этого процедура остается очень стремной.