Как стать автором
Обновить
13
0.1

Пользователь

Отправить сообщение

Увидел заголовок, долго думал, чем женщинам не угодил hex...

Про самое интересное и не рассказали - как измерить АКТУАЛЬНОЕ отставание по времени. Дельта между now() и таймстэмпом сообщения не показательна, потому что когда по этой дельте мы переваливаем за SLO, то уже поздно пить боржоми.

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

Ну и уже традиционное замечание по kafka-go - незачем городить свой велосипед для вычисления лага - у ридера есть стата с этой метрикой. А для консьюмер групп всё равно нужно запускать по ридеру на партицию, тогда метрика всегда будет корректная.

Конвейер-молотилка данных. Исходно писался, чтобы подразобраться в тонкостях работы с разными штуками, сейчас тихонько работает, перемалывая геоданные и всякие событийные вещи - https://github.com/gekatateam/neptunus

... паузы GC неприемлемы. Именно поэтому крупные компании всё чаще выбирают Rust (или даже C++) в этих средах

А что, когда-то было иначе? Где-то, где важен каждый такт, были языки с ГЦ? По личному опыту, там всегда сидели плюсы, которые сейчас вытесняются растом.

Ну а Го осел в нишах, где нужна параллельность-конкуррентность

Можно ли закрыть досрочно?
Можно. Более того — нужно, если можете. Мы даже делаем скидку до 10% за это.

Этак выходит, что можно оформить рассрочку, тут же оплатить полностью и получить скидку?

Не надо так

reader := kafka.NewReader(kafka.ReaderConfig{
    Brokers:        []string{"localhost:9092"},
    Topic:          "my-topic",
    GroupID:        "my-group",
    CommitInterval: 0, // Отключаем автоматический коммит
})

for {
    msg, err := reader.ReadMessage(context.Background())
    if err != nil {
        panic(err)
    }
    fmt.Printf("Received: %s\n", string(msg.Value))

    // Коммитим оффсет вручную после обработки
    err = reader.CommitMessages(context.Background(), msg)
    if err != nil {
        panic(err)
    }
}

Ридер не следит за тем, что коммитит, после реблансировки консьюмеров можно внезапно обнаружить, что произошел коммит в уже чужую партицию.

Лучше создать консьюмер группу и в её рамках обрабатывать старт нового поколения - https://pkg.go.dev/github.com/segmentio/kafka-go#Generation.Start

Плюс в том, что пока горутины, запущенные в Start(), не завершат работу, клиент не отдаст ОК на перебалансировку. Это даёт время дообработать и закоммитить уже вычитанное.

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

Исправил, спасибо

На андроид почему-то не обрабатывается нажатие кнопки "назад" (что вверху слева, что системной), обратно в ленту из поста приходится возвращаться переходом на главную по иконке

нам нужно снимать экран, действия пользователя, сайты, на которых он сидит, и используемые приложения

Это точно функционал, которому место в тайм-трекере? Во-первых, кажется, что без этого переход с электрона не нужОн, во-вторых, не вяжется с позиционированием продукта; цитата с сайта:

ведите учёт рабочего времени без нарушения личных границ

Предлагаю ЖизньЕнтерпрайзЕдишн (по аналогии)

Каждая клетка - отдельный класс, реализующий интерфейс:

type Cell interface {
	GetState() state
	NextState() error
  UpdateState() error
}

Где state - специальный отдельный тип, под капотом маппящий 1 как "жив" и 0 как "мёртв", чтоб можно было расширяться и добавлять новые состояния.

При вызове NextState() каждая клетка должна сходить в один из апи-сервисов, узнать состояние соседей, высчитать своё следующее состояние и приготовиться обновиться по вызову UpdateState().

Создаем сервис-менеджер, который может хранить в себе кусочек поля:

type CellManager struct {
    Cells []Cell
}

func (m *CellManager) Initialize(from, to int64) error {}

func (m *CellManager) Next() error {}

func (m *CellManager) Update() error {} 

Менеджеры клеток можно разделить по нескольким дата-центрам, каждый из менеджеров может обслуживать свой кусочек поля. 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-систем, и там специфическая кухня, о которой думают в первую очередь «продажники».

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

Но вы правы, тема не раскрыта, постараюсь затронуть её в дальнейшем
1

Информация

В рейтинге
4 364-й
Зарегистрирован
Активность

Специализация

SRE
Старший