Тут в графану панель  для логов подвезли https://grafana.com/blog/2019/10/16/new-in-grafana-6.4-the-logs-panel

ссылка на логи в графане побилась, но я все поправил, спасибо!

Спасибо @sysadmin_tools за крутой видос
https://www.youtube.com/watch?v=6Nyr9z3g0p0
#elasticsearch

А тем временем, в RabbitMQ 3.8 реализовали нативную поддержку Prometheus метрик. И даже подготовили дашборды для графаны 📊http://amp.gs/qCD3

Таким образом, все больше продуктов нативно поддерживает Prometheus 🔥🔥🔥. Из недавнего например HAProxy и NGINX Plus.

И вы можете помочь добавить нативные метрики в ClickHouse, поставив «👍 и ❤️» в этой ишью, или даже реализовать эту фичу 😉http://amp.gs/qCDH
#news #rabbitmq #monitoring #prometheus #clickhouse

На CodeAcademy запустили новый курс по Go совместно с Google. 😱👨‍💻

https://www.codecademy.com/learn/learn-go

Заделываем дыры в кластере Kubernetes. Доклад и расшифровка с DevOpsConf
https://habr.com/ru/company/southbridge/blog/472484/

Плейлист всех выступлений с конференции #k8s fwdays 2019 проходившей 5 октября

Интересный взгляд на SLO со стороны взаимодействия команд от Charity Majors.

http://amp.gs/qeGR
#slo #article

A collection of language specific resources that one can use to look up the best practices followed by that particular language's community.

https://github.com/palash25/best-practices-checklist

Весьма объемная статья в блоге Segment про оптимизацию их инфраструктуры
http://amp.gs/qedd
#segment #blog

Подсмотрел в чате тут про https://github.com/jacksontj/promxy - proxy для Prometheus который позволяет сделать HA #proxy #prometheus

Один из наших подписчиков написал статью про интересную штуку - анализатор сетевой топологии. Читаем, ставим лойсы https://habr.com/ru/post/472724/
#network

Работаем с сигналами Linux из Golang
https://medium.com/better-programming/using-signals-to-handle-unix-commands-in-golang-f09e9efb7769
#linux #signals #golang

Пишем свой TCP сканер на Go 👩‍💻👨‍💻

https://developer20.com/tcp-scanner-in-go

Все новое это хорошо забытое старое.

Автор предлагает взять и любую дичь (ваши ежедневные команды из консоли) и обернуть в Makefile, что по сути будет той же башнянкой.sh

Возможно я не оценил профит и кто-то готов пояснить мне где же там все-таки собака зарыта?

сайт - http://bit.ly/2oe5TzU
github - http://bit.ly/2p9oCgr

За материал спасибо @pavkazzz

Очень хотел посмотреть этот доклад

Уже постил видео доклада коллеги с конференции DevOpsConf 2019 «Логи не нужны?», а теперь и текст подъехал.

Если у вас на ровном месте петабайты логов, условный эластик вам не рад и вы ему тоже, то вам стоит задуматься:
- что из этого всего вам действительно нужно
- что превратить в метрики и использовать как метрику (e.g. Prometheus)
- возможно отделить критические ошибки и положить в специализированное место (e.g. Sentry)
- такая же история с бизнес метриками

Статья: http://bit.ly/2ocTcVU
Видео: http://bit.ly/2ocTNqC

🧪 Методы "отравления" кеша CDN, которые могут привести к частичной, либо полной недоступности ресурса для остальных посетителей: https://cpdos.org

#security #линк #фидбечат

По поводу поста https://t.me/chiki_briki_it/132 от подписчика пришло вот такое мнение:

Привет. Суть make для разного рода проектов в том, что он позволяет скрыть разного рода команды и хранить их унифицированно. Посмотрим на примере. У меня есть несколько заказчиков, я для них написал небольшой набор плейбуков и ролей на ансибле. У этих плейбуков единый костяк, но они чуть отличаются per кастомер. Соответственно, я при ручных деплоях запускаю что-то типа

ansible-playbook -i inventory/customer.hosts -K --ask-vault-pass run-minimal.yml

. Таких плейбуков типа run-minimal.yml набралось уже около 30. Спустя какое-то время возникают следующие проблемы:

1. Очень надоедает писать всю эту простыню руками. Поиск по C-r не спасает, потому что плейбуков 30 * N кастомеров, запускается оно часто. Решение приходит постепенно. Сначала мы делаем

alias apl=ansible-playbook

, потом мы засовываем аргументы в shebang (а чо, так можно было? - постоянно спрашивают меня коллеги).

2. Эту хню надо запускать не только руками, но часто на проде, где надо автоматически вводить become password и vault password. Для vault в ансибле есть удобное решение. Для become нет ничего, кроме того чтобы запрашивать из extra vars. Ты к аргументам добавляешь конструкцию вида

-e @extra/vars.yml

, в которой тащишь env var, которую пробрасываешь в become. Все это снова приезжает в shebang каждого плейбука.

3. Тут внезапно оказывается, что ты в CI хочешь делать так, как есть, а на локальной машине хочешь использовать mitogen еще. И у тебя ansible.cfg в репе. И ты не хочешь вписывать mitogen_linear в него, потому что на CI нет митогена и все развалится. И ты снова придумываешь с env vars, но теперь их надо экспортить перед тем, как ты запускаешь плейбуки локально и про это надо не забывать.

4. И тут ансибл обновляется и говорит "чувак, теперь вместо sudo_user" можно использовать только "become_user" и ты идешь и все шебанги во всех плейбуках для всех кастомеров переписываешь. Ну чо, sed позапускал, все норм вроде.

Так вот. Вместо этого всего ты делаешь make и кладешь его в оригинальную репу. И в этот make вписываешь все, что тебе нужно. И когда придет время менять синтаксис, он поменяется в одном makefile, а не в 150 плейбуках. Когда надо будет что-то добавить, оно снова поменяется в 1 makefile. А еще можно выкинуть

alias apl=ansible-playbook

. А еще можно переменные окружения настраивать автоматически перед вызовом деплоя. Ну и митоген можно локально настраивать тут же, а на CI не делать этого.

И таких примеров, на самом деле, не слишком уж много и я вообще прекрасно жил без make лет примерно 15. А потом внезапно понял, что на моем объеме автоматизации он решает кучу задач и вообще очень норм. (c)


От себя добавлю - Makefile и правда бывает удобен, для того чтобы забутстрапить сборку, например. Сам использовал Makefile в прошлом году, для запуска плейбуков ansible + генерации vars для них и мне даже понравилось, но ощущения были странные.