Когда появляется необходимость документировать схемы баз данных, разные DBMS предоставляют свои инструменты для подобных задач. И большинство из них поддерживает DESC table_name, в том числе и ClickHouse. Однако, результат этой команды не столь выразителен, как хотелось бы.

DESCRIBE TABLE data_lr

name        type      default_type   default_expression   comment   codec_expression   ttl_expression
Path        String                                                  ZSTD(3)
Value       Float64                                                 Gorilla, LZ4
Time        UInt32                                                  DoubleDelta, LZ4
Date        Date                                                    DoubleDelta, LZ4
Timestamp   UInt32                                                  DoubleDelta, LZ4

При этом, системные таблицы tables и columns содержат исчерпывающую информацию, объединив которую, можно получить вот такой симпатичный результат:

Несколько недель назад в нашей инфраструктуре я обнаружил небольшую ошибку конфигурации переменной окружения TZ. Исправление этой ошибки нарушило хрупкое равновесие багов во вселенной и графики RPS для одного из проектов в нашем графите буквально сошли с ума. Я расскажу, как гонялся за несколькими часами в течение нескольких дней.

Приветствую, habr.

Если кто-то эксплуатирует систему graphite-web и столкнулся с проблемой производительности хранилища whisper (IO, потребляемое дисковое пространство), то шанс того, что был брошен взгляд на ClickHouse в качестве замены, должен стремиться к единице. Данное утверждение подразумевает то, что в качестве принимающего метрики демона уже используется сторонняя реализация, например carbonwriter или go-carbon.

ClickHouse хорошо решает описанные проблемы. К примеру, после переливки 2TiB данных из whisper, они уместились в 300GiB. Подробно на сравнении я останавливаться не буду, статей на эту тему хватает. К тому же, до недавнего времени с нашим ClickHouse хранилищем было не всё идеально.

Примерно месяц назад у меня был выбор: писать ли модуль для puppet "в стол" (то есть, для внутренней инфраструктуры) или делать его универсальным, открывать исходники и публиковать его на puppet forge. Конечно, быстрее и проще было бы набросать быстро под себя 2-3 класса и на том успокоиться, но вот опыт, который был получен в процессе публикации модуля, является ценным и хочется им поделиться. В рунете никакой информации по использованию puppet development kit (далее PDK) нет, так что можно считать это своеобразным туториалом.

О чём статья

В процессе разработки модуля (а точнее, двух) я открыл для себя PDK, который сильно облегчает как разработку, так и сопровождение модулей. А именно:

• Автоматическое форматирование metadata.json при обновлении последнего
• Генерация конфигурации для различных систем CI, которые умеют следующее:
  
  • Проверка ruby кода линтером rubocop
  • Запуск юнит тестов
  • При определённых условиях — автоматическая заливка рабочего кода на puppet forge
• Генерация документации на основе тегов в коментариях при помощи yard
• Плашка [PDK] для модуля на puppet forge. Мелочь, а приятно!

Всех заинтересованных

И снова, здравствуйте. Неделю (эта статья о-очень долго мариновалась в бэклоге) Какое-то время назад я рассказал, как использовать rcm для обычного управления конфигурацией. У нас в компании есть модуль puppet, распространяющий персональные настройки пользователя по всем хостам, на которые у него есть доступ. Соответственно, хочется следующего:

• Иметь собственные настройки для всего, чем я пользуюсь (vim, zsh, git, etc..)
• Обновлять их по мере обновления в репозитории dotfiles
• Всё это — без лишних телодвижений

Инструменты

Всё, что нужно, уже используется мною, а именно:

• rcm
• git
• tar

Предыстория

Когда на руках появляется более одного рабочего устройства, то к тебе, %username%, приходит желание иметь одинаковую конфигурацию и тут, и там, и на работе, и дома. Когда я только-только начинал попытки синхронизировать файлы, мне было достаточно Dropbox и Yandex.disk. Особенно хорошо они помогали синхронизировать документы и историю джаббера, но как только я попытался приспособить их к .bashrc, .vimrc и им подобным, тут же повылезали различные сайд-эффекты. Например, с symlink'ами в обоих системах полнейшая беда, ± какая-то история есть только в дропбоксе, ну и писать скрипты управления зоопарком пришлось бы самому. Наверняка ведь что-то уже написано,

Как дошло до жизни такой