Платформы наблюдения часто требуют от высококвалифицированных практиков понимания смысла и использования этих платформ. В идеале заинтересованная сторона, не являющаяся техническим специалистом, должна полагаться на мониторинг, понимание проблем или оптимизацию, а затем полагаться на платформу, которая выполнит остальную работу. При отладке средство решения проблем под управлением искусственного интеллекта обнаруживает, обновляет и устраняет проблему, а также формулирует ситуацию таким образом, чтобы ее мог понять нетехнический пользователь.
Поставщики средств наблюдения должны предлагать цельные метрики, которые можно использовать для решения бизнес-целей и предотвращения бизнес-катастроф, сказал мне недавно Билл Хайнлайн, полевой технический директор Chronосферы. Новостей здесь нет, но необходимость упростить наблюдаемость, не принижая ее, невозможно переоценить.
Но он также сказал, что нетехнические заинтересованные стороны должны быстро разобраться в том, как интерпретировать эти показатели. Это освежающий взгляд.
Еще один освежающий момент: определение целей уровня обслуживания (SLO), которое часто является последним шагом в стратегии наблюдения, должно быть первым.
Широкое внедрение инструментов наблюдения невозможно, если они слишком сложны, но многие поставщики об этом забывают. Поставщики средств наблюдения говорят о дополнительных функциях, которые они предлагают для метрик, журналов и трассировок, предполагая, что фактические пользователи или потенциальные пользователи знают, о чем они говорят, что не всегда так.
Даже на уровне технического директора пользователям может быть сложно понять, как работают их платформы и как интерпретировать данные — и зачастую именно они одобряют расходы на инструменты не только для разработчиков и инженеров по эксплуатации, но и для всех заинтересованных сторон своей организации.
Поставщики средств наблюдения часто говорят: «У нас есть новый способ агрегирования журналов или трассировок» и т. д. Но что именно это означает, если речь идет о решении системы, которая вышла из строя и привела к потере денег у организации?
Обеспечение доступности наблюдаемости для нетехнических пользователей
По словам Хайнелайна, ключевым требованием любой стратегии наблюдения должна быть простота использования для широкой аудитории, от опытного инженера до нетехнического менеджера по продукту. Эффективный инструмент должен предоставлять аналитическую информацию «из коробки», не требуя от пользователей создания сотен информационных панелей. Он должен быть таким же интуитивно понятным, как смартфон: готовым к немедленному использованию, но при этом настраиваемым.
По словам Хайнелайн, такая доступность дает возможность неспециалистам делать ценные выводы.
Менеджеру по продукту, например, не нужно быть «главным технологом», чтобы увидеть корреляцию между внезапным падением коэффициентов конверсии, резким увеличением количества ошибок в приложениях и выпуском новой версии программного обеспечения, произошедшей несколько минут назад, сказал он. Они могут сформулировать простую гипотезу, поскольку платформа предоставляет четкие и актуальные данные без шума ненужных показателей.
По словам Hineline, этот принцип был доказан во время критического сбоя в работе авиакомпании United Airlines, где приложение, отключившее авиакомпанию, было обработано в режиме реального времени. Инженер по продажам авиакомпании, который пробыл в учетной записи всего несколько дней и не имел «племенных знаний» о внутренней работе приложения, смог найти основную причину и решить проблему.
Этот опыт привел к ключевому выводу: цель состоит в том, чтобы сделать людей экспертами в инструменте, а не в каждой взаимосвязанной части сложных систем компании. По словам Хайнелайн, когда инструмент достаточно мощный и интуитивно понятный, он демократизирует решение проблем, разрушает разрозненность знаний и в конечном итоге обеспечивает лучшие и быстрые результаты для бизнеса.
По его словам, наиболее эффективные реализации наблюдаемости начинаются не с вопроса: «Какие данные мы можем собрать?» а спрашивая: «Как выглядит добро для нашего бизнеса?» Целью наблюдения является обеспечение того, чтобы технология позволяла вести бизнес так, как предполагалось. Это означает прямую привязку технических показателей к результатам бизнеса. Например, по его словам, если пользовательский опыт сайта электронной коммерции медленнее, чем у конкурента, это реальная бизнес-проблема.
Начните с SLO, чтобы ограничить сбор данных
Такое бизнес-ориентированное мышление естественным образом приводит к определению SLO, которые, по мнению Hineline, должны стать отправной точкой на пути организации к наблюдаемости.
Начиная с SLO, вы получаете «направляющие» относительно того, какие данные следует собирать. Вместо того, чтобы собирать все, команды могут начать с простой и мощной основы, основанной на важных для бизнеса сигналах, таких как время отклика, частота ошибок и насыщенность. По словам Хайнелайн, такой целенаправленный подход не только дает немедленную информацию, но и смягчает проблемы с затратами, из-за которых организации «боятся» возможности наблюдения.
Основной проблемой отрасли является бизнес-модель «собирать все». Поскольку компании «гипермасштабируются, этот объем становится огромным, и поэтому стоимость становится фактором», — сказал Хайнлайн. Это сместило фокус, добавил он, на «измерение ценности» и понимание «ценности, которую телеметрия дает мне, чтобы убедиться, что я собираю правильные вещи».
По его словам, одним из самых больших отличий ChronSphere является «возвращение этого контроля клиентам, позволяющее им понять, какую ценность телеметрия и журналы, которые они размещают на платформе, действительно возвращаются им».
По словам Хайнелайн, это направлено на устранение тенденции разработчиков собирать «все». Платформа предоставляет «метаданные, позволяющие сказать: «Хорошо, я знаю, что вам нужно 5000 показателей. Вы используете 100».
Соединение наблюдаемости с реальными потребностями бизнеса
Наблюдения Hineline коррелируют с отчетами Gartner о состоянии наблюдаемости. В отчете, опубликованном в январе этого года аналитиками Gartner Мартином Кареном, Греггом Зигфридом, Мэттом Кроссли и Мрудулой Бангерой, подавляющее большинство сценариев успешного внедрения будет зависеть от удовлетворения осязаемых и измеримых потребностей бизнеса.
По данным Gartner, к 2027 году 80% организаций, успешно применяющих наблюдаемость, достигнут более коротких задержек при принятии решений, что обеспечит конкурентное преимущество для их целевых бизнес-или ИТ-процессов.
Организации, как правило, хорошо осознают необходимость и пользу того, что предлагает надлежащая наблюдаемость. Однако они, по понятным причинам, обеспокоены тем, что на них повлияют расходы, особенно если параллельно рассматривать рост облачных технологий и другие затраты.
Мониторинг журналов часто является отправной точкой для организаций, желающих понять состояние и производительность своих систем, пишут аналитики Gartner.
«Хотя журналы часто представлены в текстовом формате, удобном для чтения человеком, это также усложняет их перемещение, обработку и хранение, а также затрудняет их перемещение, обработку и хранение», — говорится в отчете Gartner. «Организации, работающие с более чем 1 ТБ журналов в день, захотят изучить конвейеры телеметрии (дифференцированный уровень) как способ решения этих проблем».
Практический пример: журналы хроносферы в действии
Журналы Chronосферы для выявления проблем с вашими виртуальными машинами.
В июне ChronSphere представила Logs 2.0. Компания утверждает, что благодаря этому организации сокращают время восстановления и упрощают оптимизацию операций и отладку.
Хотя моя аналитическая фирма ReveCom еще не тестировала и не анализировала эту версию, мы просмотрели демо-версию ChronSphere Logs. Во время этой демонстрации был показан этап устранения неполадок с использованием недавно выпущенных возможностей ведения журнала. В демо было продемонстрировано, как ChronSphere решила внутреннюю проблему, выявленную по данным журналов.
В демо-версии Джером Фролих, инженер-программист из ChronSphere, описал, как использовалась платформа ChronSphere, когда задержка P99 для службы приема метрик увеличилась. Хотя рассматриваемый сервис выглядел работоспособным, расследование обратилось к прокси-серверу, используемому для маршрутизации периферийного трафика.
По словам Фролиха, метрики для одного конкретного экземпляра прокси отличались от других. При переключении на просмотр журналов этого прокси-сервера было обнаружено, что поставщик облачных услуг выполнил живую миграцию на виртуальной машине, на которой работал этот экземпляр.
В этом случае виртуальная машина вернулась в ухудшенном состоянии. По словам Фролиха, после того, как его сняли с флота, наблюдаемая задержка вернулась в норму. «Раньше для устранения подобной проблемы требовалось собрать воедино информацию из нескольких разрозненных источников. Теперь информация доступна на единой панели».
Продолжающаяся проблема упрощения наблюдаемости
Снижение затрат за счет уменьшения размера и перекачивания метрик в соответствии с потребностями пользователя, а не просто открытие этого крана для всех без исключения данных, определенно является плохой и дорогостоящей идеей. И Хроносфера, по крайней мере, похоже, делает серьёзную попытку сделать это, а также упростить процесс наблюдения для достижения вышеуказанных целей, как заявлено.
Конечно, это мантра других поставщиков услуг наблюдения, о которых мы недавно говорили — Chronography, а также Grafana Labs, Kloudfuse, WanAware и других.
В нынешнем виде правильное оснащение и использование преимуществ наблюдаемости остается трудным процессом, а кривая обучения крутая, если не считать претензий поставщиков. Хотя провайдеры, очевидно, осознают проблему, и будет интересно посмотреть, что они придумают, не ждите решений, которые позволят пользователю собрать все, что ему нужно знать о своих приложениях и сети, таким образом, который будет очень доступен в ближайшем будущем.
Но сюрпризы случаются.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. BC Gain — основатель и главный аналитик ReveCom Media. Его одержимость компьютерами началась, когда в начале 1980-х он взломал консоль Space Invaders, чтобы играть весь день за 25 центов в местном игровом зале. Затем он… Подробнее от Б. Кэмерона Гейна.
