этогик // DevOps, Infrastructure, Productivity
前往频道在 Telegram
🚀Блог DevOps-инженера. Вместе растем в хард- и софт скиллах, разбираемся как жить и работать продуктивно, ищем баланс во всем 🌿 📽 yt: https://www.youtube.com/@etogeek 🌍 site: https://etogeek.dev 🌿 chat: @etogeekchat Подробнее в закрепе 🦾
显示更多4 332
订阅者
+124 小时
+67 天
-130 天
数据加载中...
吸引订阅者
七月 '26
七月 '26
+17
在0个频道中
六月 '26
+70
在0个频道中
Get PRO
五月 '26
+79
在0个频道中
Get PRO
四月 '26
+119
在0个频道中
Get PRO
三月 '26
+161
在2个频道中
Get PRO
二月 '26
+124
在0个频道中
Get PRO
一月 '26
+130
在0个频道中
Get PRO
十二月 '25
+121
在0个频道中
Get PRO
十一月 '25
+143
在0个频道中
Get PRO
十月 '25
+154
在0个频道中
Get PRO
九月 '25
+143
在0个频道中
Get PRO
八月 '25
+132
在0个频道中
Get PRO
七月 '25
+142
在0个频道中
Get PRO
六月 '25
+124
在0个频道中
Get PRO
五月 '25
+171
在0个频道中
Get PRO
四月 '25
+138
在0个频道中
Get PRO
三月 '25
+156
在0个频道中
Get PRO
二月 '25
+168
在0个频道中
Get PRO
一月 '25
+168
在0个频道中
Get PRO
十二月 '24
+125
在0个频道中
Get PRO
十一月 '24
+132
在0个频道中
Get PRO
十月 '24
+232
在0个频道中
Get PRO
九月 '24
+271
在0个频道中
Get PRO
八月 '24
+163
在0个频道中
Get PRO
七月 '24
+159
在0个频道中
Get PRO
六月 '24
+143
在0个频道中
Get PRO
五月 '24
+239
在0个频道中
Get PRO
四月 '24
+190
在0个频道中
Get PRO
三月 '24
+282
在0个频道中
Get PRO
二月 '24
+766
在1个频道中
Get PRO
一月 '24
+30
在1个频道中
Get PRO
十二月 '23
+223
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 09 七月 | +1 | |||
| 08 七月 | +3 | |||
| 07 七月 | +3 | |||
| 06 七月 | +1 | |||
| 05 七月 | +4 | |||
| 04 七月 | 0 | |||
| 03 七月 | +2 | |||
| 02 七月 | +2 | |||
| 01 七月 | +1 |
频道帖子
Некоторое время назад столкнулся с тем, что какой-то сервис отправил мне огромное количество логов в Локи. В цитируемом посте я рассказывал процесс поиска виновника.
Сейчас проблема повторилась, и я разобрался как принудительно удалять старые логи.
Во-первых, в конфигурации должен быть активирован compactor. У меня такой конфиг:
compactor:
working_directory: {{ loki_data_dir }}/retention
compaction_interval: 10m
retention_enabled: true
retention_delete_delay: 30m
retention_delete_worker_count: 150
delete_request_store: filesystem
delete_request_cancel_period: 5m
Затем делаем такой запрос в Loki с указанием query для фильтрации и таймштампами:
curl -G -X POST 'http://localhost:3100/loki/api/v1/delete' \
--data-urlencode 'query={service="your-damned-service"}' \
--data-urlencode 'start=2026-06-05T00:00:00Z' \
--data-urlencode 'end=2026-06-25T00:00:00Z'
Смотрим статус запроса:
curl 'http://localhost:3100/loki/api/v1/delete'
[{"request_id":"d7f76f7f","start_time":1780617600,"end_time":1782345600,"query":"{service="your-damned-service"}","status":"processed","created_at":1782393974.431}]
Ждем некоторое время (compaction_interval: 10m, delete_request_cancel_period: 5m, retention_delete_delay: 30m) и наслаждаемся освобожденным местом.| 2 | Kubernetes — мощно, но сложно. 8 июля в Москве собираются инженеры, чтобы разобраться вместе: поговорить о реальных кейсах, пообщаться за круглыми столами и познакомиться с теми, кто решал похожие задачи.
Будут доклад о домашнем кластере на несколько квартир и дата-центров, разбор ИИ-агента, который управляет инфрой как админ, и дискуссии по сетям, виртуализации и безопасности.
Это юбилейный митап Deckhouse User Community — и на этот раз особенно много внимания тем, кто активно участвует в жизни сообщества. Коллеги поделятся запуском программы поддержки контрибьюторов.
Только офлайн, количество мест ограниченно, регистрируйтесь! | 1 654 |
| 3 | Уже довольно давно я сталкиваюсь с плавающими проблемами связи между Яндекс Облаком и Hetzner: у рандомного https- соединения скорость может упасть до 100кб/с. Способы стабилизировать это нашлись, а вот полностью решить так и не получилось.
Захотелось замониторить эту скорость скачивания, чтобы найти какие-то закономерности (спойлер, на нашел).
За несколько гугл-запросов подходящий экспортер не нашелся - в основом все проверяют скорость до speedtest-а, а мне нужны кастомные URL - например свой Nexus.
Время сейчас такое, что если чего то нет, или функционал не устраивает, ты просто пишешь своё. Вот и я сделал download speed exporter:
👉 https://github.com/etoosamoe/download_speed_exporter
Собираем образ контейнера, запускаем, а в Prometheus или vmagent дергаем /probe-ручку с URL-ом целевого файла. В ответ получаем метрики по скорости скачивания. Дашборд есть в комплекте.
На самом деле я сделал его уже давно, просто почему-то не рассказывал тут.
На скриншоте пример того, как скорость скачивания вообще упала до минимума на пол дня. | 2 612 |
| 4 | Работа в небольшой продуктовой компании часто расширяет границы твоей позиции. Я уже давно не просто “девопс”, который перезагружает серверы и дебажит пайплайны. Вопрос плохо это или хорошо - оставлю каждому на размышление.
Например, не так давно занимался сначала объединением двух "сайтов" Jira и Confluence в один. Такую попытку уже делал мой лид за полгода до этого, но всё разбилось об ограничения: проблемы при мерже, скачивание/загрузка бекапа и тд.
А спустя время, оказалось, что Atlassian только-только выпустили новый инструмент как раз для переноса данных между “сайтами”. Он отработал просто превосходно, перенес проекты со всеми данными, аттачами и почти ничего не поломал.
Затем приступил к миграции из Notion в Confluence. Это получилось более хаотично. Многие страницы в Ноушене были приватными. А к приватным страницам даже у админа нет доступа. Нужно просить сотрудников, у кого есть доступ, экспортировать архив, скидывать его мне, а я уже импортирую его в Confluence.
Одновременно с этим руководство захотелось разделить все статьи по пространствам - например Sales, Finance, Product и так далее. Минус Confluence по сравнению с Notion или Google Docs в том, что ты не можешь дать доступ одному человеку к одному документу. Нужно добавить человека в раздел (Space), и тогда он получит доступ ко всем открытым статьям.
Несмотря на то, что Confluence - хороший инструмент, переезд из Notion был воспринят коллегами не очень мягко. Было много непоняток с доступами, проблем с поисками “потерянных” статей, исправлений ссылок в легаси-местах, проблем с форматированием.
Суммарно наэкономили около $24к в год. Жаль не в свой карман, конечно. | 3 038 |
| 5 | В последние недели погрузился в абсолютно новую для себя штуку - мобильную разработку. Точнее, DevOps-часть для нее.
Всё новое, изначально ничего непонятно, даже то, с какой стороны подступаться к этому. Хорошо, что мы живем в 2026 году, где существуют ChatGPT и Claude. Но ответственность не позволяет навайбкодить все конфиги и решения. Вместо этого я сижу и делаю кросс-проверки, разбираюсь что и зачем нужно, какие инструменты есть, и почему именно они.
Больше, конечно, ковырялся именно с iOS частью, потому что проверять сборку проще локально - андроид телефона у меня нет. Разобрался в целом с воркфлоу разработки: Xcode, Apple Developer аккаунт, bundle-id, загрузка в App Store Connect, публикация в TestFlight для внутренних тестировщиков.
Понял, что если мы хотим тестировать приложение на dev-окружении, то по сути надо делать два приложения dev и prod. Потому что внутрь приложения зашивается конфигурация, в которой API-эндпоинты указаны. Получается, что можно собрать dev-приложение, загрузить его в App Store Connect и отправить в TestFlight для проверок. В ревью оно никогда не пойдет. А вот prod-приложение уже пойдет по пути TestFlight → Review → Store.
Отсюда вытекает то, что нужно иметь схемы и конфигурации для сборки двух приложений в одном репозитории. И Firebase конфигурации тоже - этим прямо сейчас занимаюсь. Firebase - это платформа от гугла с кучей вспомогательных сервисов для мобилок, например: аналитика и push-уведомления.
Ага, не забыть еще скриптик для инкремента версий приложений - сторы требуют обновления версии при каждой новой загрузке приложений. А еще требуют иконку для приложения. Чтобы на iOS картинку не зашакалило (частично из-за Liquid Glass), её надо сделать в Icon Composer-е с помощью SVG-элементов.
Разобрался как работают OTA-апдейты (over the air). Это когда можешь пересобрать только внутреннюю часть, запаковать ее в js-бандл и залить в s3. Приложение при запуске проверит наличие апдейта, скачает и предложит перезапуститься. Самая большая выгода - для мелких багфиксов тебе не нужно публиковать новую версию в сторы и ждать ревью. Тут надо быть осторожным, потому что добавлять функционал через OTA-апдейты без ревью запрещается правилами сторов.
Описал для разработчиков релизный процесс - как будем работать с фича-ветками, релизными ветками, версиями. Постарался сделать так, чтобы это минимально отличалось от уже привычного всем в команде процесса.
В общем, погружение в новую область это всегда так - сначала чувствуешь себя идиотом, не знаешь основных терминов. Мозг к вечеру выжат настолько, что хочется просто сесть на диван и смотреть в стену. Главное помнить - глаза боятся, а руки делают. Потихоньку, мелкими итерациями, но в итоге картина становится яснее, начинаешь лучше во всем ориентироваться. | 2 875 |
