Пятничный деплой
4.74K subscribers
1.51K photos
35 videos
167 files
7.95K links
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://xn--r1a.website/s/count0_digest
Download Telegram
Открытые практикумы DevOps и Linux by REBRAIN: 20 и 21 октября
Количество мест строго ограничено. Успевайте зарегистрироваться. Запись практикума NGINX by REBRAIN в подарок за регистрацию!

Rebrain x DataArt: Управление Kubernetes кластером с помощью Terraform. 20 октября 19.00 МСК

Регистрация
: https://kutt.it/C6rmh5

🔹Зачем это надо, если есть yaml?
🔹Как подключиться?
🔹Какие подводные камни?

Кто ведет?
Александр Снеговой - Cloud/DevOps Architect в DataArt. Сертифицированный AWS и GCP Architect. Выступает с докладами про cloud и DevOps. 7 лет в IT.

Linux by Rebrain: Мониторинг на примере Prometheus. 21 октября 20.00 МСК

Регистрация
: https://kutt.it/VLDTBy

🔹Виды мониторинга
🔹Что такое prometheus
🔹Обзор необходимых компонентов
🔹Установка и настройка

Кто ведет?
Буранов Андрей - Специалист по UNIX-системам в компании Mail.Ru Group. Опыт работы с ОС Linux более 7 лет. Опыт преподавания более 5 лет. Входит в топ 3 лучших преподавателей образовательных порталов.
Forwarded from Мониторим ИТ
We’re making Prometheus use less memory and restart faster

A few months ago, I blogged about memory-mapping of full chunks of the head block from disk. The feature, which was introduced in Prometheus v2.19.0, brings down memory usage and restart time.

Additionally, there’s another Prometheus feature in progress that snapshots in-memory data during shutdown for faster restarts; it’s expected to cut down the restart times by a big factor. Интересно, как это.
Начинаешь свой путь в IT? Попробуй силы в Java-разработке на реальных задачах и создай приложение, которое украсит твоё портфолио.

Ждём тебя на бесплатном интенсиве 22–24 октября в 16:00!
Нужна только регистрация: 👉 https://clc.am/pNHxRQ

Ты узнаешь, как:
✔️ писать код на Java и вносить в него изменения;
✔️ отлавливать исключения и обрабатывать их;
✔️ читать и записывать файлы в Java;
✔️ подключать внешние библиотеки.

🔊 За три дня под руководством опытного разработчика ты создашь приложение, которое записывает звук с микрофона, сохраняет запись в файл и отправляет его в Dropbox!

🎁 Авторы трёх лучших проектов получат сертификаты на 30 000 рублей для поступления на любой онлайн-курс университета Skillbox, а все участники, дошедшие до конца, — электронную книгу Кей Петерсон и Дэвида Колба «Век живи — век учись» от издательства «МИФ».
Интересная статья, которая познакомит вас с паттерном Расширение интерфейса в Go: https://proglib.io/w/c9b49350
Go MeetUp

1. RPC over NATS — умная доставка сообщений - Александр Ковалев, Go Teamlead, IVA Technologies
Для обеспечения быстрой, надежной и масштабируемой доставки сообщений между компонентами, было решено использовать NATS .io в качестве транспорта и модифицированный JSON RPC, как начальную реализацию протокола. Что из этого уже получилось, какие возможности дает такой подход и что еще планируется сделать.

2. Go Modules в production - Данилкин Илья, Senior Engineer, Scrum Master, Авито
Со времени анонса модулей прошло уже 2 года. За это время их успели выпустить в виде официального эксперимента, сломать и починить несколько раз.
Готовы ли они к использованию в проде? Зачем переезжать с dep/Glide (и как)? Как работать с ними в IDE?
__________________________________

🗓 29 октября 18:00–20:00, Четверг

🌐 ОНЛАЙН

Регистрация на мероприятие
Forwarded from Админим с Буквой (bykva)
Настройка Heartbeat для проверки работы системы мониторинга

Расскажу на примере prometheus, alertmanager, opsgenie.

opsgenie:
0) создаем команду
1) по адресу https://app.opsgenie.com/settings/heartbeat создаем хартбит по нужным вам параметрам (severity, на кого повесить, описание). Запоминаем имя (далее ${name})
2) идем в интеграции, создаем для prometheus - именуем, назначаем команду, получаем api ключ.
https://app.opsgenie.com/settings/integration/integration-list (далее ${opsgenie_api_key})

alertmanager.yml:

receivers:
- name: deadmansswitch
webhook_configs:
- url: https://api.opsgenie.com/v2/heartbeats/${name}/ping
send_resolved: true
http_config:
basic_auth:
password: ${opsgenie_api_key}
route:
group_by:
- job
group_interval: 5m
group_wait: 10s
receiver: default
repeat_interval: 1m
routes:
- receiver: deadmansswitch
match:
severity: DeadMansSwitch
repeat_interval: 1m

prometheus.yml -> далее если у вас правила вынесены в отдельный файл, если нет, ну, сами поправите)

...
rule_files:
- /etc/prometheus/prometheus.rules
...

prometheus.rules:

groups:
- name: prometheus.alerts.rules
rules:
- alert: PrometheusAlertmanagerE2eDeadManSwitch
expr: vector(1)
for: 5m
labels:
severity: DeadMansSwitch
annotations:
summary: "Prometheus AlertManager E2E dead man switch (instance {{ $labels.instance }})"
description: "Prometheus DeadManSwitch is an always-firing alert. It's used as an end-to-end test of Prometheus through the Alertmanager.\n VALUE = {{ $value }}\n LABELS: {{ $labels }}"

Как это работает:
1) в течение 5 минут прометей проверяет выражение vector(1), которое всегда будет отдавать 1, а значит фейлиться.
2) через 5 минут (а затем еще каждую минуту) он будет пиннать алертменеджер и говорить что есть проблема.
3) Алертменеджер будет долбиться раз в минуту на специальный урл opsgenie.
4) В настройках хартбита вы выставляете время которое считаете нормальным для того чтобы система оповещения лежала. и далее ход конём:
5) если у вас погиб прометей (или сеть до алертменеджера), он не будет долбить алертменеджер и рефрешить гарантированный алерт. в таком случае автоматически происходит разрезолв алерта (по-умолчанию 5 минут) и перестают посылаться сообщения на урл из п.3. Тогда по истечению таймаута из п4. на вашу команду упадет алерт о том что хартбит просрочен.
6) если у вас умер алертменеджер (или связность до апи opsgenie), то по истечению таймаута из п4. на вашу команду упадет алерт о том что хартбит просрочен.

т.о. такая связка гарантирует что вся цепочка от мониторинга до алертменеджера и апишки opsgenie находится в работоспособном состоянии

Источник знаний:
- https://xn--r1a.website/metrics_ru
- https://docs.opsgenie.com/docs/heartbeat-api
- https://github.com/prometheus/alertmanager/pull/444#issuecomment-428493861

#prometheus #opsgenie #alertmanager
Forwarded from CatOps
​​Wake up Neo, Kubernetes Services not exist.

And it uses random LB strategy, not round-robin.

Good news - it can be ignored in some cases, but in the worst case (long-lived TCP connections + frontend services less than backend) pods may not be able to handle traffic and horizontal scaling won't help.

To choose the right pill, take a cup of something and read about load balancing and scaling long-lived connections in K8s.

#kubernetes
Forwarded from linkmeup
Тут Google внезапно разоткровенничался и рассказал про свои проблемы с DDoS. Проблемы у них интересные: 2,5Tbs (не вчера, а два года назад) и 690 миллионов пакетов в секунду от IoT ботнета.
Ты там как? Прикрутил уже на свой микротик радиатор побольше?

https://cloud.google.com/blog/products/identity-security/identifying-and-protecting-against-the-largest-ddos-attacks
Вчера AWS выпустил Origin Shield для CloudFront - своей услуги CDN. Из названия мне показалось, что речь про некий экран, который позволит пользователю получать контент только от узлов CDN, блокируя трафик до origin, но на деле нововведение оказалось гораздо полезнее.

Origin Shield имплементирует дополнительный уровень кеширования, который позволит Edge локациям (географически распределенные точки присутствия CloudFront) обновлять свой локальный кеш не из origin, а непосредственно из этого слоя.

Иными словами, если вы расположились в eu-west-1 и настроили CloudFront на раздачу по всему миру, то все Edge локации будут запрашивать контент у ваших серверов в eu-west-1, тем самым создавая серьезную нагрузку на ваш origin. В случае с Origin Shield обновление кеша будет запрашиваться непосредственно с узлов CloudFront в eu-west-1, и только локальный CloudFront будет “мучать” ваш origin.

Такое решение лучше всего подходит для динамического контента, такого как видеостриминг. Имплементация единого слоя кеширования позволит уменьшить затраты на вычислительные мощности origin’ов или перенаправив их в другое русло, хоть на то же транскодирование видеоконтента.

Важно! Имейте в виде, что Origin Shield имеет добавочную стоимость, так что прежде чем радостно ставить галочку в консоли CloudFront сравните расходы на трафик с Origin Shield с трафиком и ценой на compute origin’а.

А то будете потом писать мне, что клавды клятые вас грабят.