Полагаю, упоминая Grafana, вы имеете ввиду Grafana APM, которая по свои сути как раз является одним из игроков рынка observability платформ.
Вы правильно упоминаете архитектуру размещения в облаке. На рынке РФ это так и не прижилось - у кого то по требованиям безопасности это запрещено, кто-то боится, что данные "утекут", другие опасаются "рубильника", который может в момент отключить доступ к данным в облаке. За 10+ лет я встречал только 2-3 заказчика, которые готовы были размещать мониторинг в облаке. Все предпочитают on-premise установки. Наш продукт Ключ-АСТРОМ также размещается в периметре у заказчика.
И вот тут, уже, лично мое мнение, место для сравнения, потому что elastic (elasticsearch + kibana + (metrics|file)beats + apm server + logstash + apm agent) vs grafana стек (grafana + tempo + alloy + mimir + loki + opentelemetry collector + faro + opentelemetry agent)
Посмотрите - тут даже буквами много текста получилось). Набор решений, конечно, хороший, но для каждого из них нужна своя инфраструктура, своя экспертиза, "подружить" их между собой и хорошая высококвалифицированная и дорогая команда. При этом никакой вендорской поддержки. Если что-то сломалось - придется чинить самим, с найденными CVE придется смириться.
Elastic быстрее внедряется
Вот тут готов поспорить. Сама серверная часть Ключ-АСТРОМ разворачивается примерно за 15 минут. Агенты еще быстрее. Для получения трассировок внедрять отдельно OpenTelemetry не нужно, подбирать отдельно агент для Java или NodeJS, для Go или .NET иди др. тоже не нужно.
Что такого особенного в вашем продукте, что не сможет Elastic APM агенты или Opentelemetry агенты которыми в ряде случаев можно обернуть вендорское приложение?
На самом деле довольно много, например, в рамках одного решения получить мониторинг трейсов (без внедрения OpenTelemetry), привязать их к действиям пользователя в браузере или мобильном приложении, дать бизнесу сведения о выполнении SLO, аналитикам - воронки продаж и конверсии с разбивкой, например, по регионам, из трейса посмотреть лог, который к нему относится, тут же просмотреть сведения о работе сетевого оборудования, посмотреть Execution plan в БД, получить сведения о CVE, проанализировать причины крэшей в мобильном приложении, при наступлении проблемы понять насколько она критичная, влияет ли на конечных пользователей и где ее корневая причина.
А можно уточнить, в чем конкретно сложность? В Java для logback это 5 строчек xml конфигурации, для Log4j2 и spring boot одна строчка, для .NET так же просто. Если в nodejs приложении используется pino то, добавить в логи traceid - 3 строчки кода. opentelemetry агенты весьма неплохо прокачались за последнее время.
Я приведу пример, как простая, с виду, задача может затянуться на недели работы и согласований - поставить задачу, выделить ответственного, поставить в тест, прогнать нагрузочное тестирование, повторить на препроде, создать ЗНИ, согласовать с безопасниками, дождаться техокна для релиза, написать отчет и все ради нескольких строчек кода.
Никакое внедрение коммерческого APM решения, магическим образом не выделит ответственных и не наладит процессы разбора инцидентов.
Ну тут тяжело поспорить. Конечно, культура использования APM должна быть в компании. Для этого обычно выделяется ответственный со стороны заказчика, проводятся обучения и консультации команд
Ага, а если ИИ ошибся?
Тут не совсем то место, где применяются галлюцинации. Система выстраивает базовые линии по работе приложения, в случае их отклонений ИИ анализирует связи по горизонтали и вертикали, чтобы установить причинно-следственную связь. Человеческий фактор тут отсутствует, поэтому итоговый результат получается точным.
Если решение облачное - то это зависит от модели ценообразования. Если как в Grafana Cloud то вот вообще не факт, так как стоимость там привязана к кол-ву логов, метрик и может расти нелинейно. Если же модель как у Elasticsearch Cloud то немного проще, но надо внимательно следить за местом на горячих и холодных нодах, так как elastic очень прожорливый до места. Я понимаю, что вы пишете про свое решение, но как писал выше нет возможности зайти на ваш сайт. У вас же там есть открытые цены, да? :)
у нас модель прозрачная - конечно, вся информация на сайте приведена :)
Да, это довольно частая ситуация.в этом же и проблема. В то время когда потребителем мониторинга инфраструктуры является только одна команда (или несколько), то observability платформы используют сразу разные смежные подразделения - разработчики видят как работает их код, техподдержка фиксирует инциденты и сразу понимают к кому идти, бизнес следит за SLO, аналитики смотрят пользовательский путь и все это они делают в одной системе. Инфраструктуру мониторить легко и многие инструменты это делают. Но проблемы на проде - это обычно ошибки в коде, интеграции, настройка garbage collector, логические ошибки. и при этом, зачастую, с инфраструктурой все прекрасно. Объединить всю информацию о системе и найти там проблему, а еще дать информацию для бизнеса - это и есть наблюдаемость (observability)
Понял мысль. В целом хотел описать как меняется подход к анализу инцидентов и мониторингу, может получилось слишком просто. Окей, статья вводная, для начала. К технической части тоже перейду — там уже будет больше конкретики. Про «передёргивания» интересно — можете указать конкретный кусок?
Согласен, в B2B вопрос доверия и ответственности за решение критичный.
Я в статье скорее разбирал, что происходит уже после выбора, когда система живет в проде: поддержка, изменения, разбор инцидентов. Там как раз и видна разница между подходами.
Статья в первую очередь для тех, кто уже сталкивался с мониторингом на практике — собирал стек на open-source или разбирал инциденты в проде. С главной все ок, скорее всего, у вас включен впн :)
Спасибо за столь детальный разбор.
Полагаю, упоминая Grafana, вы имеете ввиду Grafana APM, которая по свои сути как раз является одним из игроков рынка observability платформ.
Вы правильно упоминаете архитектуру размещения в облаке. На рынке РФ это так и не прижилось - у кого то по требованиям безопасности это запрещено, кто-то боится, что данные "утекут", другие опасаются "рубильника", который может в момент отключить доступ к данным в облаке. За 10+ лет я встречал только 2-3 заказчика, которые готовы были размещать мониторинг в облаке. Все предпочитают on-premise установки. Наш продукт Ключ-АСТРОМ также размещается в периметре у заказчика.
Посмотрите - тут даже буквами много текста получилось). Набор решений, конечно, хороший, но для каждого из них нужна своя инфраструктура, своя экспертиза, "подружить" их между собой и хорошая высококвалифицированная и дорогая команда. При этом никакой вендорской поддержки. Если что-то сломалось - придется чинить самим, с найденными CVE придется смириться.
Elastic быстрее внедряется
Вот тут готов поспорить. Сама серверная часть Ключ-АСТРОМ разворачивается примерно за 15 минут. Агенты еще быстрее. Для получения трассировок внедрять отдельно OpenTelemetry не нужно, подбирать отдельно агент для Java или NodeJS, для Go или .NET иди др. тоже не нужно.
На самом деле довольно много, например, в рамках одного решения получить мониторинг трейсов (без внедрения OpenTelemetry), привязать их к действиям пользователя в браузере или мобильном приложении, дать бизнесу сведения о выполнении SLO, аналитикам - воронки продаж и конверсии с разбивкой, например, по регионам, из трейса посмотреть лог, который к нему относится, тут же просмотреть сведения о работе сетевого оборудования, посмотреть Execution plan в БД, получить сведения о CVE, проанализировать причины крэшей в мобильном приложении, при наступлении проблемы понять насколько она критичная, влияет ли на конечных пользователей и где ее корневая причина.
Я приведу пример, как простая, с виду, задача может затянуться на недели работы и согласований - поставить задачу, выделить ответственного, поставить в тест, прогнать нагрузочное тестирование, повторить на препроде, создать ЗНИ, согласовать с безопасниками, дождаться техокна для релиза, написать отчет и все ради нескольких строчек кода.
Ну тут тяжело поспорить. Конечно, культура использования APM должна быть в компании. Для этого обычно выделяется ответственный со стороны заказчика, проводятся обучения и консультации команд
Тут не совсем то место, где применяются галлюцинации. Система выстраивает базовые линии по работе приложения, в случае их отклонений ИИ анализирует связи по горизонтали и вертикали, чтобы установить причинно-следственную связь. Человеческий фактор тут отсутствует, поэтому итоговый результат получается точным.
у нас модель прозрачная - конечно, вся информация на сайте приведена :)
Да, это довольно частая ситуация.в этом же и проблема. В то время когда потребителем мониторинга инфраструктуры является только одна команда (или несколько), то observability платформы используют сразу разные смежные подразделения - разработчики видят как работает их код, техподдержка фиксирует инциденты и сразу понимают к кому идти, бизнес следит за SLO, аналитики смотрят пользовательский путь и все это они делают в одной системе. Инфраструктуру мониторить легко и многие инструменты это делают. Но проблемы на проде - это обычно ошибки в коде, интеграции, настройка garbage collector, логические ошибки. и при этом, зачастую, с инфраструктурой все прекрасно. Объединить всю информацию о системе и найти там проблему, а еще дать информацию для бизнеса - это и есть наблюдаемость (observability)
Понял мысль. В целом хотел описать как меняется подход к анализу инцидентов и мониторингу, может получилось слишком просто. Окей, статья вводная, для начала. К технической части тоже перейду — там уже будет больше конкретики. Про «передёргивания» интересно — можете указать конкретный кусок?
Согласен, в B2B вопрос доверия и ответственности за решение критичный.
Я в статье скорее разбирал, что происходит уже после выбора, когда система живет в проде: поддержка, изменения, разбор инцидентов. Там как раз и видна разница между подходами.
Статья в первую очередь для тех, кто уже сталкивался с мониторингом на практике — собирал стек на open-source или разбирал инциденты в проде.
С главной все ок, скорее всего, у вас включен впн :)