🚀 Разгоняем kube-prometheus-stack: секретный ингредиент в Observability

🔥 9 июня в 20:00 мск — бесплатный вебинар «Разгоняем kube-prometheus-stack».
Мониторинг не должен тормозить, особенно когда что-то идёт не так.

Что разберём:

– как ускорить отклик Grafana при работе с большими объёмами данных,
– что замедляет Prometheus и как с этим бороться,
– как сократить сетевой трафик мониторинга без потерь,
– как не положить observability-инфру при инциденте,
– и какие архитектурные подходы помогают сделать мониторинг отказоустойчивым.

Оптимизируйте kube-prometheus-stack и держите руку на пульсе — даже в условиях пиковых нагрузок.

👉 Регистрируйтесь здесь:
https://vk.cc/cMB9gr

Занятие приурочено к старту курса "Observability: мониторинг, логирование, трейсинг", на котором вы научитесь строить эффективные системы мониторинга, работать с Prometheus, Grafana, ELK и другими инструментами, визуализировать метрики.

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Полное руководство по Docker Secrets

Даже если вы использовали Docker для небольших или локально разработанных программ, вы могли обнаружить, что он может быть довольно трудным для решения более сложных задач. Особенно это касается управления секретами и совместного использования - областей, которые часто упускаются из виду при работе с контейнерными приложениями.

https://earthly.dev/blog/docker-secrets/

#devops #девопс

Подпишись 👉@i_DevOps

Оповещение об аномалиях в Prometheus

Изучаем, как настраивать оповещения об аномалиях для сезонных данных в Prometheus.

В Auto Trader мы стремимся создавать оповещения, которые большинство сможет использовать «из коробки», а не жестко прописывать их под конкретные сценарии. Мы хотим, чтобы вы могли развернуть сервис и сразу получить отдачу от платформы — особенно когда речь идет об отслеживании и оповещениях по вашим «Golden Signals» или управлении затратами.

https://bookflow.ru/opoveshhenie-ob-anomaliyah-v-prometheus/

#devops #девопс

Подпишись 👉@i_DevOps

Жизненный цикл управления уязвимостями в DevSecOps

Это первый пост из серии, которая будет глубоко погружаться в архитектуру программы DevSecOps. Цель этой серии — представить целостный обзор DevSecOps как совокупности технологически управляемых, автоматизированных процессов. Какие инструменты и технологии играют роль в DevSecOps? Как мы можем использовать технологии, чтобы настроить команды разработчиков на успех? Как мы выстраиваем роли и зоны ответственности для обеспечения слаженности, безопасности и скорости? На эти и другие вопросы мы ответим по мере развития серии.

Последние три года я в профессиональной роли строил программу DevSecOps в своей компании с нуля. Возможно, отдельные части этой серии не будут напрямую применимы к вашей организации, но её ключевые идеи и общий подход всё равно могут оказаться полезными. Следующее заявление о миссии отражает мой подход к DevSecOps:

«Моя задача — внедрить процесс разработки программного обеспечения по принципу secure-by-design, который предоставляет командам разработчиков возможность самостоятельно отвечать за безопасность своих цифровых продуктов. Мы добьёмся успеха за счёт контроля и обучения, а благодаря технологически ориентированной и автоматизированной архитектуре DevSecOps снизим трение и сохраним высокую скорость работы.»

https://blog.gitguardian.com/vulnerability-management-lifecycle-in-devsecops/


#devops #девопс

Подпишись 👉@i_DevOps

Безопасность по умолчанию: программное обеспечение в DevSecOps

Это второй пост в серии, посвящённой архитектуре программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как набора технологически управляемых автоматизированных процессов. Если вы не читали первый пост, обязательно ознакомьтесь с ним!

В этой статье речь пойдёт скорее не о принятии решений, а об опыте разработчиков. Мы узнаем, как снабдить наших инженеров программного обеспечения инструментами, которые позволят им самостоятельно обеспечивать безопасность своего кода, и как поддержать их с помощью автоматизации. Прежде чем приступать, хочу ещё раз озвучить своё основное утверждение по DevSecOps:

«Моя задача — внедрить процесс разработки программного обеспечения с безопасностью по умолчанию, который даст командам инженерии возможность самостоятельно отвечать за безопасность своих цифровых продуктов. Мы добьёмся успеха с помощью контролей и обучения, а также снизим трение и сохраним скорость разработки благодаря технологически управляемой автоматизированной архитектуре DevSecOps.»

https://blog.gitguardian.com/secure-by-design-software-in-devsecops/

#devops #девопс

Подпишись 👉@i_DevOps

Целостность и безопасность конвейера в DevSecOps

Это третий пост из серии глубокого погружения в архитектуру программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как совокупности ориентированных на технологии и автоматизированных процессов. Обязательно ознакомься также с первой и второй частью!

На данном этапе мы разобрали, как управлять уже существующими уязвимостями и как предотвращать появление новых. Теперь у нас есть жизненный цикл разработки ПО (SDLC), который обеспечивает создание программного обеспечения, безопасного «с самого начала». Осталось лишь разобраться, как обеспечить исполнение и защиту созданной нами архитектуры.

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


https://blog.gitguardian.com/pipeline-integrity-and-security-in-devsecops/

#devops #девопс

Подпишись 👉@i_DevOps

Стили взаимодействия микросервисов: 5 секретов, которые изменят ваш подход к backend-разработке

Взаимодействие между микросервисами — это больше, чем просто REST или RPC. Это фундамент архитектуры, от которого зависит масштабируемость, надёжность и производительность всей системы.

📌 Что будет на вебинаре:

— 5 ключевых стилей взаимодействия микросервисов: REST, gRPC, event-driven, messaging, CQRS;
— Сравнение: синхронное vs. асинхронное взаимодействие — плюсы, минусы, типичные ошибки;
— Когда использовать брокеры сообщений и какую роль играют очереди;
— Советы по построению отказоустойчивых коммуникаций между сервисами;
— Как логировать и отслеживать взаимодействия между микросервисами;

👉 Регистрация и подробности о курсе Highload Architect: https://vk.cc/cMHfWt

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Bash-совет: анализ неудачных SSH-логинов и бан «горячих» IP 🔒🐚

Хотите быстро узнать, какие IP вызывают максимум неудачных попыток входа в SSH, и оперативно заблокировать самых настырных? Ниже скрипт:

#!/usr/bin/env bash
# ssh_fail_analyzer.sh
# Анализ неудачных SSH-попыток и вывод TOP-10 IP

LOG_FILE="/var/log/auth.log"       # путь к логам (для CentOS: /var/log/secure)
TOPN=10                            # сколько IP показывать

echo "Топ $TOPN IP с неудачными SSH-входами:"
grep -E "Failed password for" "$LOG_FILE" \
  | grep -oP '(?<=from )[\d\.]+' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -n "$TOPN"

Как это работает

1. grep -E "Failed password for"
Ищем все строки с неудачными попытками.
2. grep -oP '(?<=from )\[\d.]+'
С помощью PCRE-регулярки достаём только IP-адреса после слова "from".
3. sort | uniq -c | sort -rn
Сортируем, считаем вхождения и выводим в порядке убывания.
4. head -n "\$TOPN"
Ограничиваем результат топ-10.


🛠 Можно добавить в crontab ежедневный запуск и автоматическую отправку отчёта на почту или сразу бан «горячих» IP через iptables:

# в crontab: каждый день в 00:10
10 0 * * * /path/to/ssh_fail_analyzer.sh | mail -s "SSH Fail Report" admin@example.com

Или сразу блокировать подозрительные IP, если они превысили порог:

THRESHOLD=50
for ip in $(grep -E "Failed password for" "$LOG_FILE" \
              | grep -oP '(?<=from )[\d\.]+' \
              | sort | uniq -c \
              | awk -v t="$THRESHOLD" '$1 > t {print $2}'); do
  iptables -I INPUT -s "$ip" -j DROP
  echo "$(date): Заблокирован $ip за превышение $THRESHOLD неудачных попыток" >> /var/log/ssh_ban.log
done

👉@bash_srv

Почему нельзя парсить вывод ls(1)

Команда ls(1) достаточно хорошо справляется с отображением атрибутов одного файла (по крайней мере, в некоторых случаях), но когда просишь у неё список файлов, возникает огромная проблема: Unix позволяет использовать в имени файла почти любой символ, в том числе пробелы, переносы строк, точки, символы вертикальной черты, да и практически всё остальное, что вы можете использовать как разделитель, за исключением NUL.
Существуют предложения по «исправлению» этой ситуации внутри POSIX, но они не помогут в решении текущей ситуации (см. также, как правильно работать с именами файлов). Если в качестве стандартного вывода не используется терминал, в режиме по умолчанию ls разделяет имена файлов переносами строк. И никаких проблем не возникает, пока не встретится файл, в имени которого есть перенос строки. Так как очень немногие реализации ls позволяют завершать имена файлов символаи NUL, а не переносами строк, это не позволяет получить безопасным образом список имён файлов при помощи ls (по крайней мере, портируемым способом).

https://habr.com/ru/articles/823298/

#devops #девопс

Подпишись 👉@i_DevOps