На сколько я вижу из практики, слейв у себя не складирует, а запрашивает у мастера нужное — мастеру нужно обеспечить достаточную историю wal-логов.
Либо, что гораздо надёжнее, организовать архивирование и доставку wal-логов на слейв (или общее хранилище) сторонним процессом. А слейв научить эти логи доставать по мере необходимости.
Не нравится мне такой длинный archive_command. Когда что-то отломается, будет сложно найти, а постгрес будет постоянно пытаться её выполнить и копить кучу несжатых wal-логов. Было бы прозрачнее, перемещать и жать wal-лог тут же, во временную директорию. А уже затем другим процессом синхронизировать куда надо, проверять и в случае чего оповещать.
pg_basebackup в таком режиме требует наличие wal логов на время от начала бекапа, до конца. Если логи убегут, то бекап завершится ошибкой.
Нужно либо увиличивать wal_keep_segments, либо останавливать синхронизацию на момент бекапа — намного удобнее.
Жать gzip-ом в один поток тоже не очень оптимально. Лучше прикрутить pbzip2, к примеру.
Можно написать несколько шаблонов GROK и подставлять их по очереди. Подходящий и обработает нужное.
Либо построить более разветвлённую логику и по анализу входящих данных подставлять нужные варианты.
Добавлю пять копеек:
Что-бы kibana искала в замороженных индексах, необходимо включить соответствующий параметр «Search in frozen indices».
В хот фазе для логов по одному дню rollover не особо нужен и, если его убрать, то можно не заморачиваться с нумерацией вида 000001.
В варм фазе, если индекс не урезать, то он остаётся доступен для записи — что может быть тоже полезно.
LXD не использовал, но активно работаю с LXC. Дак вот:
1. df по идее должно лечится использованием дисковых квот на ФС, но не пробовал. Для меня гораздо удобнее нарезать LVM под контейнера — каждому свой. Тогда никаких разночтений не возникает.
2. LXC отлично работает с бриджами и любыми их конфигурациями. Можно и разные мосты настроить и физический интерфейс прокинуть и тп. А где надо и пронатить. Это всё на совести ядра, не важно с контейнерами или без.
3. Интерфейс — можно посмотреть в сторону Proxmox.
Лучше поздно… :).
В общем, при партиционировании удалять данные нужно внешней обработкой: сносить устаревшие партиции — в том и профит, что быстро.
Заббикс позволяет отключать хаузкипер для данных выборочно. Для тех, что партиционированы, отключить. Для других оставить.
Вы какую-то не ту документацию смотрели по настройке адресов. How-to — есть там оба варианты с описанием.
Как сеть отвалится, посмотрите, какие интерфейсы соединены в бридж и входят ли туда интерфейсы виртуалок. Можно добавить недостающие вручную.
Чтобы бридж не пересоздавался каждый при изменении сетевых настроек, можно сетевые параметны вынести на интерфейс, который затем включить в бридж.
Лет семь назад, после подобных симптомов, купил у китайцев простую вертикальную мышь. Работает по сей день, правда перепаивал микрики и енкодер колёсика. Боль и усталость в запястье после долгой работы больше не появляются. К использованию давно привык и каких-либо неудобств и неловкостей не возникает. В общем — рекомендую.
Ну и разминать и тренировать кисть и запястья тоже не повредит ;).
Чем оно может быть полезным. Как его использовать на практике.
Использую:
— для сбора логов с nginx+lua — в интересных местах добавлен вывод тела ответа сервера и заголовков запроса.
— с приложений на питоне и свой формат логов — интересующие поля + метрики.
— с различных сетевых устройств — syslog с обработкой.
ELK даёт возможность поиска, визуализации, статистики, триггеры по каким-то параметрам с оповещением. В общем, удобно.
В timestamp по умолчанию проставляется время получения сообщения. И все графики и счётные метрики (количество событий в секунду и тп) будут прыгать от него. И когда много сообщений придут одновременно, в статистике получится всплеск, которого нет. Потому удобно синхронизировать logdate и timestamp.
Я стараюсь всегда время брать из логов и записывать в timestamp, с помощью date filter. Иначе, при каких либо задержках или пакетных доставках, время события будет отличатся от времени записи.
И по моему скромному мнению, при наличии systemd, supervisor излишен.
Не правильно так делать.
Нужно либо свой конфиг .service создать в /etc/systemd/system/
Либо переопределить системный, в директории /etc/systemd/system/SERVICENAME.service.d/
Да и docker-ce 17.x давно вышел, почему 1.12-ый используете?
А с новой версией системы прав для dashboard-а случаем не разбирались?
Кроме очевидных шагов, надо же ещё и отмываться. Или сбросить попахивающий актив. А может сделать вид, что ничего и не было и они не причём… В общем — интересно.
Либо, что гораздо надёжнее, организовать архивирование и доставку wal-логов на слейв (или общее хранилище) сторонним процессом. А слейв научить эти логи доставать по мере необходимости.
pg_basebackup в таком режиме требует наличие wal логов на время от начала бекапа, до конца. Если логи убегут, то бекап завершится ошибкой.
Нужно либо увиличивать wal_keep_segments, либо останавливать синхронизацию на момент бекапа — намного удобнее.
Жать gzip-ом в один поток тоже не очень оптимально. Лучше прикрутить pbzip2, к примеру.
Либо построить более разветвлённую логику и по анализу входящих данных подставлять нужные варианты.
Что-бы kibana искала в замороженных индексах, необходимо включить соответствующий параметр «Search in frozen indices».
В хот фазе для логов по одному дню rollover не особо нужен и, если его убрать, то можно не заморачиваться с нумерацией вида 000001.
В варм фазе, если индекс не урезать, то он остаётся доступен для записи — что может быть тоже полезно.
Из-за скачков времени ntpd может ломаться.
Timekeeping best practices for Linux guests
1. df по идее должно лечится использованием дисковых квот на ФС, но не пробовал. Для меня гораздо удобнее нарезать LVM под контейнера — каждому свой. Тогда никаких разночтений не возникает.
2. LXC отлично работает с бриджами и любыми их конфигурациями. Можно и разные мосты настроить и физический интерфейс прокинуть и тп. А где надо и пронатить. Это всё на совести ядра, не важно с контейнерами или без.
3. Интерфейс — можно посмотреть в сторону Proxmox.
В общем, при партиционировании удалять данные нужно внешней обработкой: сносить устаревшие партиции — в том и профит, что быстро.
Заббикс позволяет отключать хаузкипер для данных выборочно. Для тех, что партиционированы, отключить. Для других оставить.
How-to — есть там оба варианты с описанием.
Как сеть отвалится, посмотрите, какие интерфейсы соединены в бридж и входят ли туда интерфейсы виртуалок. Можно добавить недостающие вручную.
Чтобы бридж не пересоздавался каждый при изменении сетевых настроек, можно сетевые параметны вынести на интерфейс, который затем включить в бридж.
Ну и разминать и тренировать кисть и запястья тоже не повредит ;).
Использую:
— для сбора логов с nginx+lua — в интересных местах добавлен вывод тела ответа сервера и заголовков запроса.
— с приложений на питоне и свой формат логов — интересующие поля + метрики.
— с различных сетевых устройств — syslog с обработкой.
ELK даёт возможность поиска, визуализации, статистики, триггеры по каким-то параметрам с оповещением. В общем, удобно.
И по моему скромному мнению, при наличии systemd, supervisor излишен.
Не правильно так делать.
Нужно либо свой конфиг .service создать в /etc/systemd/system/
Либо переопределить системный, в директории /etc/systemd/system/SERVICENAME.service.d/
Да и docker-ce 17.x давно вышел, почему 1.12-ый используете?
А с новой версией системы прав для dashboard-а случаем не разбирались?