Про самое интересное и не рассказали - как измерить АКТУАЛЬНОЕ отставание по времени. Дельта между now() и таймстэмпом сообщения не показательна, потому что когда по этой дельте мы переваливаем за SLO, то уже поздно пить боржоми.
Для себя вывел подход вычислять реальное отставание через лаг в штуках, деленный на скорость обработки за интервал. Не идеально, но подсвечивает проблему заранее.
Ну и уже традиционное замечание по kafka-go - незачем городить свой велосипед для вычисления лага - у ридера есть стата с этой метрикой. А для консьюмер групп всё равно нужно запускать по ридеру на партицию, тогда метрика всегда будет корректная.
Конвейер-молотилка данных. Исходно писался, чтобы подразобраться в тонкостях работы с разными штуками, сейчас тихонько работает, перемалывая геоданные и всякие событийные вещи - https://github.com/gekatateam/neptunus
... паузы GC неприемлемы. Именно поэтому крупные компании всё чаще выбирают Rust (или даже C++) в этих средах
А что, когда-то было иначе? Где-то, где важен каждый такт, были языки с ГЦ? По личному опыту, там всегда сидели плюсы, которые сейчас вытесняются растом.
Ну а Го осел в нишах, где нужна параллельность-конкуррентность
Плюс в том, что пока горутины, запущенные в Start(), не завершат работу, клиент не отдаст ОК на перебалансировку. Это даёт время дообработать и закоммитить уже вычитанное.
DevSecOps - очередная попытка натянуть сову на глобус заткнуть несколько позиций одной вакансией. В лучшем случае на выходе имеется выгоревший инженер, в худшем к этому добавляется дыра в безопасности. Доколе же будет страдать бедная сова?
На андроид почему-то не обрабатывается нажатие кнопки "назад" (что вверху слева, что системной), обратно в ленту из поста приходится возвращаться переходом на главную по иконке
нам нужно снимать экран, действия пользователя, сайты, на которых он сидит, и используемые приложения
Это точно функционал, которому место в тайм-трекере? Во-первых, кажется, что без этого переход с электрона не нужОн, во-вторых, не вяжется с позиционированием продукта; цитата с сайта:
ведите учёт рабочего времени без нарушения личных границ
Каждая клетка - отдельный класс, реализующий интерфейс:
type Cell interface {
GetState() state
NextState() error
UpdateState() error
}
Где state - специальный отдельный тип, под капотом маппящий 1 как "жив" и 0 как "мёртв", чтоб можно было расширяться и добавлять новые состояния.
При вызове NextState() каждая клетка должна сходить в один из апи-сервисов, узнать состояние соседей, высчитать своё следующее состояние и приготовиться обновиться по вызову UpdateState().
Создаем сервис-менеджер, который может хранить в себе кусочек поля:
Менеджеры клеток можно разделить по нескольким дата-центрам, каждый из менеджеров может обслуживать свой кусочек поля. Next() и Update(), конечно, асинхронные.
Для большей ентерпрайзности можно положить всё в кубер, а каждый менеджер пусть хранит данные в выделенной базёнке, и чтоб всё масштабировалось налету в зависимости от изначально заданного размера поля.
Теперь нам нужен апи-сервис. Апи-сервис должен знать о расположении всех менеджеров (допустим, что эта информация хранится в кластере Consul). Когда апи получает команду на обновление, он асинхронно кидает команду на менеджеры о вычислении следующего состояния. Когда все вычисления завершаются, отдаётся команда на обновление.
К апи-сервису прилагается какой-нибудь веб-сервер с фронтом, который отображает красивую картинку.
P.S. не воспринимайте серьёзно, просто идея за обеденной чашкой кофе.
Обеими руками за подобного рода статьи, но пока что ваши тексты, вопреки заголовкам, акцентируют внимание на спутнике.
Уделяйте внимание и другим вакцинам, пожалуйста. Без этого, пока что, всё вот это смотрится как очередная реклама, которая на фоне, во-первых, отсутствия в РФ иностранных вакцин, во-вторых, непризнания спутника ВОЗ, степень доверия не сильно-то и повышает
Statsd - это, по сути, аккумулятор. Бросаете в него метрики, он из них, согласно настройкам, делает счётчик (суммирует все значения), датчик (отдает самое свежее), и т.п.
У этого механизма есть не упомянутая в документации особенность, которая может знатно попить крови - page_capacity должен быть строго меньше max_bytes (понятно, что больше делать неразумно, но даже равенство этих параметров не допускается).
Несоблюдение чревато внезапной остановкой обработки событий при внешнем отсутствии явных проблем.
Не упомянуты низкопрофильные, оптические, свитчи, ни слова о других производителях, кроме черри, затронуты только попсовые "цвета" переключателей.
Статья ради рекламы.
Для заинтересовавшихся - рекомендую ознакомиться с https://geekboards.ru/page/mechanical_switches_v2. Здесь разобрано много типов и производителей свитчей, от этого уже можно отталкиваться при дальнейшем выборе.
Вы не дочитали до конца)
Текущая статья — только о мониторинге. Логи, трейсы, детали реализации будут дальше.
Потом, возможно, попробуем в рамках другой статьи собрать всё в минимальный Observability.
К тому же, Instanta платная, а мы тут пробуем собрать решение на OpenSource.
Но тут очень тонкая грань проходит:
Есть метрики работоспособности бизнес-процессов — это «иженерный мониторинг». Тут задача состоит в обеспечении функционирования бизнеса.
А есть бизнес-метрики — данные о продажах, притоку/оттоку клиентов, графики выручки и прочее. Это зона BI-систем, и там специфическая кухня, о которой думают в первую очередь «продажники».
Вторую категорию я не рассматриваю — нет релевантного опыта.
Увидел заголовок, долго думал, чем женщинам не угодил hex...
Про самое интересное и не рассказали - как измерить АКТУАЛЬНОЕ отставание по времени. Дельта между now() и таймстэмпом сообщения не показательна, потому что когда по этой дельте мы переваливаем за SLO, то уже поздно пить боржоми.
Для себя вывел подход вычислять реальное отставание через лаг в штуках, деленный на скорость обработки за интервал. Не идеально, но подсвечивает проблему заранее.
Ну и уже традиционное замечание по kafka-go - незачем городить свой велосипед для вычисления лага - у ридера есть стата с этой метрикой. А для консьюмер групп всё равно нужно запускать по ридеру на партицию, тогда метрика всегда будет корректная.
Конвейер-молотилка данных. Исходно писался, чтобы подразобраться в тонкостях работы с разными штуками, сейчас тихонько работает, перемалывая геоданные и всякие событийные вещи - https://github.com/gekatateam/neptunus
А что, когда-то было иначе? Где-то, где важен каждый такт, были языки с ГЦ? По личному опыту, там всегда сидели плюсы, которые сейчас вытесняются растом.
Ну а Го осел в нишах, где нужна параллельность-конкуррентность
Этак выходит, что можно оформить рассрочку, тут же оплатить полностью и получить скидку?
Не надо так
Ридер не следит за тем, что коммитит, после реблансировки консьюмеров можно внезапно обнаружить, что произошел коммит в уже чужую партицию.
Лучше создать консьюмер группу и в её рамках обрабатывать старт нового поколения - https://pkg.go.dev/github.com/segmentio/kafka-go#Generation.Start
Плюс в том, что пока горутины, запущенные в
Start()
, не завершат работу, клиент не отдаст ОК на перебалансировку. Это даёт время дообработать и закоммитить уже вычитанное.DevSecOps - очередная попытка
натянуть сову на глобусзаткнуть несколько позиций одной вакансией. В лучшем случае на выходе имеется выгоревший инженер, в худшем к этому добавляется дыра в безопасности. Доколе же будет страдать бедная сова?Исправил, спасибо
На андроид почему-то не обрабатывается нажатие кнопки "назад" (что вверху слева, что системной), обратно в ленту из поста приходится возвращаться переходом на главную по иконке
Это точно функционал, которому место в тайм-трекере? Во-первых, кажется, что без этого переход с электрона не нужОн, во-вторых, не вяжется с позиционированием продукта; цитата с сайта:
Предлагаю ЖизньЕнтерпрайзЕдишн (по аналогии)
Каждая клетка - отдельный класс, реализующий интерфейс:
Где state - специальный отдельный тип, под капотом маппящий 1 как "жив" и 0 как "мёртв", чтоб можно было расширяться и добавлять новые состояния.
При вызове NextState() каждая клетка должна сходить в один из апи-сервисов, узнать состояние соседей, высчитать своё следующее состояние и приготовиться обновиться по вызову UpdateState().
Создаем сервис-менеджер, который может хранить в себе кусочек поля:
Менеджеры клеток можно разделить по нескольким дата-центрам, каждый из менеджеров может обслуживать свой кусочек поля. Next() и Update(), конечно, асинхронные.
Для большей ентерпрайзности можно положить всё в кубер, а каждый менеджер пусть хранит данные в выделенной базёнке, и чтоб всё масштабировалось налету в зависимости от изначально заданного размера поля.
Теперь нам нужен апи-сервис. Апи-сервис должен знать о расположении всех менеджеров (допустим, что эта информация хранится в кластере Consul). Когда апи получает команду на обновление, он асинхронно кидает команду на менеджеры о вычислении следующего состояния. Когда все вычисления завершаются, отдаётся команда на обновление.
К апи-сервису прилагается какой-нибудь веб-сервер с фронтом, который отображает красивую картинку.
P.S. не воспринимайте серьёзно, просто идея за обеденной чашкой кофе.
@NavalnyTeam прокомментируйте, пожалуйста.
Если описанное имеет место быть (во что очень верится), под угрозой находится каждый, кто что-либо делал на вашем сайте.
Если метрики вам действительно необходимы, может, стоит перейти на Гугл аналитикс?
Обеими руками за подобного рода статьи, но пока что ваши тексты, вопреки заголовкам, акцентируют внимание на спутнике.
Уделяйте внимание и другим вакцинам, пожалуйста. Без этого, пока что, всё вот это смотрится как очередная реклама, которая на фоне, во-первых, отсутствия в РФ иностранных вакцин, во-вторых, непризнания спутника ВОЗ, степень доверия не сильно-то и повышает
Эту тему, в рамках эссе об аниме, подробно разбирал Кунгуров на личном канале
Строго рекомендуется к ознакомлению, даже если аниме вам не нравится
Statsd - это, по сути, аккумулятор. Бросаете в него метрики, он из них, согласно настройкам, делает счётчик (суммирует все значения), датчик (отдает самое свежее), и т.п.
По поводу persisted queue на Logstash
У этого механизма есть не упомянутая в документации особенность, которая может знатно попить крови - page_capacity должен быть строго меньше max_bytes (понятно, что больше делать неразумно, но даже равенство этих параметров не допускается).
Несоблюдение чревато внезапной остановкой обработки событий при внешнем отсутствии явных проблем.
Мало, мало информации.
Не упомянуты низкопрофильные, оптические, свитчи, ни слова о других производителях, кроме черри, затронуты только попсовые "цвета" переключателей.
Статья ради рекламы.
Для заинтересовавшихся - рекомендую ознакомиться с https://geekboards.ru/page/mechanical_switches_v2. Здесь разобрано много типов и производителей свитчей, от этого уже можно отталкиваться при дальнейшем выборе.
Текущая статья — только о мониторинге. Логи, трейсы, детали реализации будут дальше.
Потом, возможно, попробуем в рамках другой статьи собрать всё в минимальный Observability.
К тому же, Instanta платная, а мы тут пробуем собрать решение на OpenSource.
Но тут очень тонкая грань проходит:
Есть метрики работоспособности бизнес-процессов — это «иженерный мониторинг». Тут задача состоит в обеспечении функционирования бизнеса.
А есть бизнес-метрики — данные о продажах, притоку/оттоку клиентов, графики выручки и прочее. Это зона BI-систем, и там специфическая кухня, о которой думают в первую очередь «продажники».
Вторую категорию я не рассматриваю — нет релевантного опыта.
Но вы правы, тема не раскрыта, постараюсь затронуть её в дальнейшем