Scylladb спонсировал этот пост.
Движение от наблюдаемости 1.0 к 2.0 добавило многое, но я думаю, что мы что -то забыли на этом пути.
Быстрое напоминание о трех столпах наблюдения 1.0. Три установленных столпа — метрики, бревен и следы. Мне нравится классифицировать их по стоимости (в терминах мониторинга системы, процессора, памяти и диска) и по сильным и слабым сторонам (кардинальность, разрешение и удержание).
- Метрики: Численные значения с ограниченной кардинальностью, неограниченным разрешением и очень долгой удержанием. У них низкая стоимость системы.
- Журналы: Журналы имеют неограниченную кардинальность, ограниченное разрешение и ограниченное удержание. Из -за использования диска они, по крайней мере, на порядок дороже, чем метрики.
- Следы: Следы имеют высокую кардинальность, низкое разрешение, длительное удержание и относительно высокий спрос на систему. Опять же, они, по крайней мере, на один или два порядка дороже, чем бревна.
Наблюдение 2.0 вводит контекст как первоклассный гражданин. Контекст — это то, что практикующие уже использовали. Тем не менее, он существовал за пределами формальной стеки наблюдения и не был явно назван. Это также добавило концепцию широких событий, давая контекст наблюдению. Оба из них пришли из -за того, что уже имело наблюдаемость, и определения того, чего не хватало.
Точно так же есть еще одна часть, которую мы использовали все время, не называя его: диагностические процедуры. Если мы не узнаем это сейчас, мы рискуем повторить одну и ту же ошибку: оставлять критическую способность из модели наблюдаемости, пока не станет слишком поздно. И если мы оставим это, у нас не будет инструментов или машинных знаний, необходимых для автоматизированного агента, чтобы выполнить эти операции при переходе на наблюдаемость 2.0.
Медицинская аналогия
Я хочу дать медицинскую аналогию. Я признаю, я смотрел слишком много эпизодов «Дом». В моей защите я также видел свою справедливую долю системных диагнозов.
Человек госпиталь поступает в больницу на основе симптомов. Сотрудники соединяют их с монитором (ОК, это очевидная часть аналогии), проходит некоторые анализы крови и отслеживает их состояние в устной форме. (Например, когда пациент кричит: «Медсестра, моя голова болит!»)
На этом этапе доктор может взглянуть на все эти входные данные и решить: «Они просто обезвожены» и отправить их домой. Это обычный диагноз первой линии, часть, которую мы почти никогда не увидим в «Доме».
Но когда первая линия диагноза не проходит, вступает в игру другой набор диагностических процедур: рентгеновский, МРТ, катетеризация, и многие другие. Они гораздо дороже и могут нести реальные риски для здоровья или благополучия пациента. Вот почему они инициируются на специальной основе, основанной на клиническом суждении, и являются целенаправленными.
В более сложных случаях вы можете услышать такие вещи, как «давайте подчеркнем их, пока симптомы не станут сильнее», или «Давайте поясним их, чтобы у них появился еще один приступ». Это преднамеренные вмешательства, чтобы сделать скрытые проблемы видимыми.
Ключевым моментом здесь является то, что диагностические процедуры являются избирательными, преднамеренными и информированными другими данными, а также опытом и пониманием исследователя.
Картирование с наблюдением
Прежде чем мы пойдем дальше, давайте проясним, как медицинская диагностика карта с наблюдаемой.
Медицинский
Наблюдаемость
Плюсы/минусы
Жизненные знаки мониторинг мониторинга мониторинга дешевого в использовании, высокой скорости дискретизации, низких бревна диаграмм пациентов с низкой кардинальностью. Любой, кто может написать что-нибудь здесь, свободную форму и неструктурированную, но есть ограничение того, сколько можно зарегистрировать анализы крови, проходит более дорого
И затем есть четвертый столб: диагностические процедуры, которые являются нашими МРТ, биопсиями и катетеризациями для систем. Это редкие, целенаправленные, иногда рискованные операции, которые мы выполняем, когда все остальное не смогло объяснить симптомы.
Диагностические процедуры в системах
Для программных систем диагностика целенаправленна, часто дорогостоящая, специальная операции, выполняемая для понимания внутреннего поведения системы. Давайте немного распаковываем это.
Во -первых, специальные и намеренные. Инициатор находится вне системы, обычно действуя в ответ на симптом или неожиданное поведение. Ключевым моментом было принято решение запустить его … человеком или автоматизацией.
Во -вторых, целенаправленно. Мы выполняем процедуру, чтобы ответить на конкретный вопрос или подтвердить гипотезу. Ключевым моментом является то, что он точный и сфокусирован (в отличие от метрик или журналов, которые являются широкими и непрерывными).
Наконец, стоимость. Это включает в себя системные ресурсы, такие как процессор, память, сеть и диск, а также любые внешние ресурсы (такие как инженер, физически подключающий зонд с сетевой картой). Стоимость также включает в себя риск: потенциальное влияние на систему и штраф, если этот риск материализуется.
Вот несколько реальных примеров диагностических процедур:
- Установка уровня журнала для отладки
- Генерируя основные дампы
- Сброс машины
- Соединение отладчика
- Диагностика работы сетевых пакетов
Любой, кто имел тенденцию к системе борьбы, вероятно, может быть связан. У вас есть причина сделать это, и вы знаете, что это имеет риск, особенно если система уже показывает деградированную производительность. Понимание более широкого контекста с точки зрения затрат и риска — это то, что имеет значение. Соединение отладчика к хозяину в тестовой среде для решения известной проблемы может принести вам повышение; Делать то же самое в производстве может уволить вас.
Диагностические процедуры обычно:
- Запускается в ответ на наблюдение.
- Сосредоточен на конкретной гипотезе.
- Потенциально разрушительный для стабильности системы.
- Непрерывно по дизайну.
Посмотрите на определение наблюдаемой википедии: «Наблюдение — это способность собирать данные о выполнении программы, внутренних состояниях модулей и общении между компонентами». Это именно то, что делают эти диагностические процедуры.
Они были здесь все время. Они важный аспект наблюдения, но они остались незамеченными и неназванными, когда были определены оригинальные колонны. Так же, как контекст в наблюдении 1.0, они всегда были частью инструментария следователя, но не на переднем плане.
Почему сейчас так важны диагностические процедуры
Есть причина для осмотра 2.0. Это начинается с «А» и заканчивается «я».
Как только вы попытаетесь научить агента ИИ понять ваш стек наблюдения, вы понимаете, что контекст сложно. Это сложно тоже для людей. Вот почему у нас есть квалифицированные инженеры, работающие интенсивно, чтобы диагностировать неисправные системы. Но мы также видим, что некоторые задачи, которые естественным образом поступают для людей, гораздо сложнее для ИИ.
В наблюдении 2.0 мы стремимся дать контекст событиям. Для людей контекст живет в наших головах (и в наших записных книжках). Этот сдвиг, вероятно, поможет при поддержке первого уровня, наблюдаемой эквивалент медсестры ER. Но скоро мы нажмем следующую шишку: этого недостаточно.
Если мы хотим, чтобы ИИ выходил за рамки отпрыскивания и активного диагноза, нам нужно дать ему колесо, а не только карту. А это означает захват диагностических процедур таким образом, чтобы машины могли понять, в комплекте с их контекстом, стоимостью и риском. Как и в случае с широкими событиями, ИИ нуждается в более широком контексте для принятия значимых решений. Это требует более широкого понимания системы и возможных результатов ее действий.
Пример распределенной базы данных
Возьмите типичную настройку высокой доступности в распределенной базе данных: Коэффициент репликации 3. Каждый кусок данных хранится на трех узлах, что позволяет системе продолжать работать нормально, если один узел снижается.
Теперь представьте, что кластер страдает от внезапных высоких задержек.
- Сценарий 1: Система перегружена. Правильным ходом может быть снижение ненужных фоновых задач или добавление большего количества вычислительных ресурсов.
- Сценарий 2: Неправильный диск на одной машине замедляет операции.
Уйдя на то, что один узел отстает от других, человек -оператор может принять решение о перезагрузке этого узла или даже удалить его из обслуживания, зная, что оставшиеся узлы могут обрабатывать нагрузку. Тот же самый человек также проверит на наличие глобальных событий, таких как постоянное обновление, чтобы решить, безопасно ли это действие.
Хотя потеря одного узла в этой настройке в порядке, потеря двух будет сломать доступность. Создание этого суждения требует широкого контекста: осознание текущих рабочих нагрузок, избыточность, недавние изменения и риски сбоев.
Для агента искусственного интеллекта, принятие правильного решения, основанного на понимании более широкого контекста, может означать разницу между:
- Сохранение системы, разумно сняв уютный узел, и
- Взяв его из высокой задержки, чтобы завершить время простоя
Что нужно для агентского искусственного интеллекта
Без явного признания и кодирования диагностических процедур, включая их предварительные условия, затраты и последствия, ИИ будет изо всех сил пытаться совершать эти нюансы.
Если мы сейчас не узнаем диагностические процедуры, мы оставим критическую способность в качестве инструментов наблюдения 2.0 и управляемых искусственным интеллектом.
Контекст отсутствовал в формальных столбах в наблюдаемости 1.0. Инструменты и операторы не были предназначены для его захвата или использования. А для агентов искусственного интеллекта создание контекста самостоятельно является особенно сложной задачей.
Тот же риск применяется к диагностическим процедурам сегодня. Люди будут продолжать выполнять эти действия из привычки и опыта, но агенты ИИ и автоматизированные системы не будут иметь крючки, гарантии или понимание, чтобы эффективно их использовать. Если мы хотим, чтобы следующее поколение наблюдаемости по -настоящему соответствовало тому, что могут сделать наши лучшие инженеры, нам нужно привести диагностические процедуры сейчас: назвать их, моделировать их и разработать для них.
Для начала нам нужен унифицированный способ их описания, снимая такие атрибуты, как риск, продолжительность, стоимость, вероятное воздействие, соображения соглашения на уровне обслуживания (SLA), критерии обратимости и воздействия. (Например, см. Это определение гипотетической диагностической процедуры.)
Прелесть этого подхода в том, что, как только мы нормализуем диагностические процедуры таким структурированным способом, мы, естественно, начнем переосмысливать их. Делая эти факторы риска явным, вместо того, чтобы полагаться исключительно на интуицию, мы можем снизить опасность того, что инженеры -поддержки уже делают сегодня — и сделать его более безопасными для агентов ИИ делать то же самое.
Во -вторых, нам понадобится унифицированный и нормализованный способ запуска таких процедур. Например, агент ИИ может выбрать подтверждение гипотезы о неисправном диске, выбрав «полную поверхность сканирования» из библиотеки диагностических процедур. Он признает потенциальное влияние на систему, определит, что она не будет нарушать обязательства SLA и выполнить их с помощью нормализованной спецификации критериев SLA: определение того, что представляет собой прерывание обслуживания в зависимости от деградации услуг, сколько времени является приемлемым прерыванием, при каких условиях останавливаться и как много системных ресурсов позволяет потреблять.
Scylladb разработан для обеспечения предсказуемой производительности в масштабе. Он принят организациями, которые требуют ультра-низкую задержку, даже с рабочими нагрузками, превышающими 1M OPS/SEC. Наша уникальная архитектура использует силу современной инфраструктуры — переводится на меньшее количество узлов, меньшую административную и снижающую затраты. Узнайте больше последних из Scylladb Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Амнон Хейман имеет 20-летний опыт разработки программного обеспечения крупномасштабных систем. Ранее он работал в Convergin, который был приобретен Oracle. Амнон имеет степень бакалавра и магистра в области компьютерных наук от технологии технологии технологии, и … Подробнее от Амнона Хеймана
