23:00:03 connecting to file storage 2009/11/10 23:00:04 connecting to meow API 1... 2009/11/10 23:00:05 connecting to meow API 2... 2009/11/10 23:00:06 connecting to meow API 3... 2009/11/10 23:00:22 GET /meow -> [200] "meow" 2009/11/10 23:00:33 GET /meow -> [200] "meow" 2009/11/10 23:00:44 GET /woof -> [400] "bad request"
библиотеки тоже хотят делать трейсинг, но не быть vendor-specific - Как разработчик библиотеки (возможно) вы тоже не хотите привязываться к какому-то вендору, а хотите дать пользователю возможность самому выбирать
имплементация - API отделена от имплементаций (spec + libs) - lib dev может использовать API - app dev может использовать API и имплементацию - “каноничная” имплементация для каждого ЯП - Vendor-agnostic - Pluggable - Содержит все, что надо - tracing - monitoring - logging
OpenTelemetry обратно совместим с OpenTracing и OpenCensus - После выхода стабильной версии OpenTelemetry в каждом ЯП разработка OpenTracing и OpenCensus прекращается - Поддержка OpenTracing и OpenCensus 2 года (с лета 2019) - Переход на OpenTelemetry возможен сразу через Bridges - В новых проектах предполагается использование API
новый Span - возвращает активный Span - делает указанный Span активным SpanContext - серилиазируемые данные, передаваемые между уровнями приложения (между разными Span) Содержит TraceId, SpanId, TraceFlags и др. поля.
метод, и т.п.) Вкладывается один в другой по стеку (дереву) прохождения запроса. Включает - Имя - Родительский Span (Span, SpanContext или null) - timestamp начала - timestamp окончания - Map Attribute - Список Events - Ссылки на другие Spanы - Статус и прочие метаданные
атрибуты/параметры Span - Доабвлять Event (имя, набор Attribute, timestamp) - лог внутри Span - Устанавливать статус (Ok, Cancelled, NotFound и еще 14) - Изменять имя - Возвращать контекст
- timestamp (неявно собирается на стороне SDK) - instrument definition (имя, тип, опции) - label set (key-value для использования потом) - value (signed integer или floating point)
можно писать код сразу с трейсингом, а подключить его потом - меньше работы разработчика, больше переиспользования, стандартные практики - одинаковый API для разных сервисов, уменьшение связанности - меньше работы DevOps, разные сервисы (tracing, monitoring) ходят через один API для разных сервисов и ЯП - Vendor-agnostic - библиотеки могут быть инструментированы без привязки к вендору -> не нужно жертвовать observability, подключая 3rd party библиотеки