CNCF спонсировал этот пост.
Поскольку компании стремятся более близко отслеживать здоровье своих приложений в реальном времени, многие сталкиваются с общей задачей: слишком много инструментов, предоставляющих различные форматы, сигналы и ценности. С почти 90% команд, использующих от двух до 10 инструментов наблюдения, самая сложная часть заставляет их всех хорошо играть вместе.
Часто различные инструменты будут использовать свою собственную терминологию для обозначения сигналов или атрибутов наблюдения. И между ними нет совместимости. В то время как можно назвать выполненным запросом, другие называют его операцией или функцией. Или можно ссылаться на работу операции как продолжительность, в то время как другой называет ее задержкой. А для команд, которым поручено мониторинг потенциальных проблем с производительностью, а также оптимизацию облачных расходов, эти расхождения являются основной головной болью.
Точно так же, как попытка объединить две электронные таблицы, где имена столбцов не совпадают, а значения могут не выровнять, различные соглашения об именах в разных системах создают ненужную сложность.
В то время как разработчики часто создают сценарии или процессоры данных для автоматизации процесса сбора, большая часть этой работы по -прежнему выполняется вручную, делая поддержание этих инструментов и поддерживая их синхронизацию с развивающимися моделями именования все более сложными. Это монополизирует ценное время, которое в противном случае можно было бы потратить на предоставление новых продуктов и возможностей. Это может повлиять на то, как быстро организации могут обнаружить проблемы в своих приложениях.
Воздействие имеет два раза: критические метрики могут быть упущены из виду, потому что они хранятся под неожиданным именем, и, казалось бы, функциональные панели мониторинга могут внезапно сломаться, когда кто -то меняет метрическое имя где -то в трубопроводе, оставляя команды запутанными в том, что пошло не так.
По мере того, как прикладные среды становятся более сложными, требования к бюджетам более интенсивны и задержки в устранении неполадок в более финансово разрушительных, компаниям должна быть в состоянии мгновенно понимать деятельность всех своих приложений, независимо от того, какие инструменты или инструменты они используют.
Четкие, последовательные семантические соглашения для сигналов телеметрии открывают более сложные подходы к наблюдению в рамках программной экосистемы с открытым исходным кодом, ориентированными на совместимость и избегание блокировки поставщиков. С постоянно растущим списком общих схем именования OpenElemetry, предприятия теперь имеют набор стандартизированных соглашений, чтобы помочь упростить их рабочие процессы.
Больше не наблюдается, обрабатывается в бункерах. Пользователи все чаще могут просто указывать метрику, которую они хотят отслеживать, и вспомогательная платформа должна работать между базовыми инструментами и языками программирования, чтобы создать единый интеллект, который предприятиям необходимы для лучшего контроля над своим ИТ -ландшафтом.
Вот как повышение семантических соглашений для телеметрии сигналов готово к обновлению наблюдения.
Постепенное решение
Создание стандартных соглашений об именах — сложная работа. Это может занять месяцы, если не дольше. После того, как первоначальная терминология согласована, и прототипы выпущены для общественности, разработчики OTEL консолидируют обратную связь со многими пользователями, охватывая все основные языки программирования и могут настроить соглашение об именах, добавить разъяснения или полностью отрезать части Конвенции.
В течение этого времени конвенции считаются «в разработке», и пользователи могут ожидать некоторых нарушений. Но этот ориентированный на сообщество подход помогает гарантировать, что после того, как конвенции в конечном итоге стабилизированы, они фактически будут приняты в реальном мире в широкой и разнообразной пользовательской базе. Фактически, большое количество обратной связи часто сигнализирует о огромном спросе среди разработчиков.
Это постоянная попытка улучшить предлагаемые конвенции, а также добавить новую терминологию. Но как только схемы перечислены как «стабильные», термин становится де -факто стандартом, что дает разработчикам уверенность в том, чтобы теперь укрепить свои рабочие процессы.
Лучшие мониторные панели, быстрее
Из -за широкого спектра существующей терминологии поставщики, предоставляющие базовые платформы наблюдения, борются за создание единых шаблонов, которые могут быть легко приняты конечными пользователями. Без стандартных соглашений об именах в разных инструментах операторы платформы не могут быть уверены, что панели панели будут работать у каждого клиента. Вместо этого разработчики приносят вручную каждый раз строить эти панели мониторинга, отталкивая их от фактического предоставления инноваций, которые требуют клиентов.
Если поставщики программного обеспечения для наблюдаемой программного обеспечения имеют набор общей терминологии для ссылки, они могут начать выпускать предварительно созданные панели мониторинга, разработанные вокруг результатов, а не метрики. Прямо сейчас большинство мониторинга отслеживают информацию, такие как использование процессора или использование памяти. Но с помощью набора стандартизированных семантических сигналов, охватывающих метрики по профилям, журналам, следам и пролетам, поставщики платформ могут объединить все метрики, необходимые, например, оптимизировать расходы на облачные данные, что облегчает и быстро для организаций принять и получить ценность.
И это создает более совместимую экосистему, которая может помочь отдельным разработчикам оптимизировать свои собственные — и их команды — окружающую среду. Часто они могут даже не знать, что могут собирать определенные показатели, пока семантические соглашения не будут представлены в их библиотеках. Общий словарь улучшает сотрудничество по перекрестной команде, которое буквально демократизирует доступ к данным в различных областях бизнеса.
Лучшая часть: список конвенций только станет дольше и лучше. Чем больше пользователей начинают принимать эти определения, тем больше обратной связи получает Отель, тем быстрее, что стандарты перемещаются от эксперимента к стабильному. Чем больше компаний могут уверенно интегрировать эти стандартные имена и сигналы в свою экосистему наблюдения, тем быстрее они могут создать взаимодействие, необходимое для запуска высокопроизводительных приложений наиболее экономически эффективным способом.
Чтобы узнать больше о Kubernetes и облачной нативной экосистеме, присоединяйтесь к нам в Kubecon + CloudNativecon Europe в Лондоне 1–4 апреля.
Облачный фонд Cloud Computing Foundation (CNCF) проводит критические компоненты глобальной технологической инфраструктуры, включая Kubernetes, Prometheus и Angoy. CNCF является нейтральным домом для сотрудничества, объединяющий ведущих разработчиков отрасли, конечных пользователей и поставщиков. Узнайте больше последних из CNCF Trending Stories YouTube.com/ThenewStack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Мэрилия Гутьеррес — инженер -программист штата в Grafana Labs, сосредоточившись на наблюдении с Opentelemetry. В проекте Opentelemetry она является утверждением для семантических соглашений базы данных, JS SDK и португальской локализации, а также поддерживающей опыта. Прежде чем … Подробнее от Мэрилии Гутьеррес
