ВЫ: "многообещающих заявлений об OpenTelemetry, закончили самописным велосипедом"
Я: "OpenTelemetry — стал основой идеологии наблюдаемости. Это не просто, некая библиотека или экосистема для трассировок, метрик и логов. Micrometer, Prometheus, Grafana, Jaeger — все инструменты используют эту идеологию как основу для интеграции и стандартизации своих инструментов."
Вы снова игнорируете Концепт в рамках которого OpenTelemetry существует как решение. Это я и хотел показать цитатой, все решения следствия неких концептов OOP, AOP, REST, SOLID и тд.
Я вам предлагаю OpenTelemetry рассмотреть шире чем просто "код", я предлагаю смотреть на OpenTelemetry как на инструмент Observability.
Мне не ясно, что вы хотите вложить в "многообещающих", я не предлагаю вам решений, я предлагаю вам думать шире чем "велосипед".
Observability lets you understand a system from the outside by letting you ask questions about that system without knowing its inner workings. Furthermore, it allows you to easily troubleshoot and handle novel problems, that is, “unknown unknowns”. It also helps you answer the question “Why is this happening?”
To ask those questions about your system, your application must be properly instrumented. That is, the application code must emit signals such as traces, metrics, and logs. An application is properly instrumented when developers don’t need to add more instrumentation to troubleshoot an issue, because they have all of the information they need.
OpenTelemetry is the mechanism by which application code is instrumented to help make a system observable
Я не хочу учить писать реализации логирования, я хочу показать, что мы должны думать о наших "соседях" и в целом о продукте, частью которого мы и являемся, что бы от любого фронта до самых глубоких бэков мы могли быстро и вовремя понять что, где, когда произошло.
Как вы исполните эту парадигму, зависит от языка, локальных практик, экспертизы участников и тд.
Я призываю не относится к OpenTelemetry - как коду, это комплексная задача с влиянием на "соседей" и систему в целом.
Я вижу вы знакомы со спрингом) Даже изучили аннотации)
Вы точно адресат этой статьи, тк для вас OpenTelemetry остается "способ чет лить куда-то тд")))
Именно такие как вы и побудили меня к написанию подобной статьи, для вас диапазон влияния ваших решений заключен в рамках IDE, а я прошу вас взглянуть на картину шире. Ведь суть всех решений в рамках OpenTelemetry не обустроить "свой огород", а создать наблюдаемую систему из компонентов(множества), где вам нужно понимать всю цепочку работы продукта.
Вы подтверждаете мой тейк) Для вас это просто "самописный велосипед", а я говорил, что это концептуальный подход к разработке, где код появляется в последнюю очередь.
OpenTelemetry - нужно проектировать так же как все остальное, а то как вы ее исполните это дело 10-ое.
Посыл не в конкретной реализации. Суть в том что-бы закладывать логи, аудит, аналитику метрики и тд еще на стадии проектирования, продумывать структуру решений с учетом "а как мы и что мы должны наблюдать?". Что бы все инфо поле пересекалось, через ключи и желательно не в 5 переходов, от одного к другому и тд.
Наблюдаемость - это НЕ время в 1 запросе куда-то. Это скорость реакции и поиска проблем, в режиме рутины... каждый день
ВЫ: "многообещающих заявлений об OpenTelemetry, закончили самописным велосипедом"
Я: "OpenTelemetry — стал основой идеологии наблюдаемости. Это не просто, некая библиотека или экосистема для трассировок, метрик и логов. Micrometer, Prometheus, Grafana, Jaeger — все инструменты используют эту идеологию как основу для интеграции и стандартизации своих инструментов."
Вы снова игнорируете Концепт в рамках которого OpenTelemetry существует как решение. Это я и хотел показать цитатой, все решения следствия неких концептов OOP, AOP, REST, SOLID и тд.
Я вам предлагаю OpenTelemetry рассмотреть шире чем просто "код", я предлагаю смотреть на OpenTelemetry как на инструмент Observability.
Мне не ясно, что вы хотите вложить в "многообещающих", я не предлагаю вам решений, я предлагаю вам думать шире чем "велосипед".
Да) Да) Пошел я...)
https://opentelemetry.io/docs/concepts/observability-primer/
What is Observability?
Observability lets you understand a system from the outside by letting you ask questions about that system without knowing its inner workings. Furthermore, it allows you to easily troubleshoot and handle novel problems, that is, “unknown unknowns”. It also helps you answer the question “Why is this happening?”
To ask those questions about your system, your application must be properly instrumented. That is, the application code must emit signals such as traces, metrics, and logs. An application is properly instrumented when developers don’t need to add more instrumentation to troubleshoot an issue, because they have all of the information they need.
OpenTelemetry is the mechanism by which application code is instrumented to help make a system observable
Вы явно не уловили посыл)
Я не хочу учить писать реализации логирования, я хочу показать, что мы должны думать о наших "соседях" и в целом о продукте, частью которого мы и являемся, что бы от любого фронта до самых глубоких бэков мы могли быстро и вовремя понять что, где, когда произошло.
Как вы исполните эту парадигму, зависит от языка, локальных практик, экспертизы участников и тд.
Я призываю не относится к OpenTelemetry - как коду, это комплексная задача с влиянием на "соседей" и систему в целом.
промазал....
Я вижу вы знакомы со спрингом) Даже изучили аннотации)
Вы точно адресат этой статьи, тк для вас OpenTelemetry остается "способ чет лить куда-то тд")))
Именно такие как вы и побудили меня к написанию подобной статьи, для вас диапазон влияния ваших решений заключен в рамках IDE, а я прошу вас взглянуть на картину шире. Ведь суть всех решений в рамках OpenTelemetry не обустроить "свой огород", а создать наблюдаемую систему из компонентов(множества), где вам нужно понимать всю цепочку работы продукта.
Вы подтверждаете мой тейк) Для вас это просто "самописный велосипед", а я говорил, что это концептуальный подход к разработке, где код появляется в последнюю очередь.
OpenTelemetry - нужно проектировать так же как все остальное, а то как вы ее исполните это дело 10-ое.
Посыл не в конкретной реализации. Суть в том что-бы закладывать логи, аудит, аналитику метрики и тд еще на стадии проектирования, продумывать структуру решений с учетом "а как мы и что мы должны наблюдать?".
Что бы все инфо поле пересекалось, через ключи и желательно не в 5 переходов, от одного к другому и тд.
Наблюдаемость - это НЕ время в 1 запросе куда-то. Это скорость реакции и поиска проблем, в режиме рутины... каждый день