Построение аналитического хранилища на 100 петабайт
•Transferir como PPTX, PDF•
0 gostou•48 visualizações
Hive in Criteo
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Построение аналитического хранилища на 100 петабайт
Semelhante a Построение аналитического хранилища на 100 петабайт (20)
Построение аналитического хранилища на 100 петабайт
- 1. Построение аналитического хранилища на 100 петабайт Александр Мазуров (Criteo) 3
- 2. 2 • { ‘UUID’ = ‘392f034c‘ ‘Client’= ‘ACME’ ‘ProductBrowsed’ = ‘45753’ } { ‘UUID’ = ‘392f034c‘ ‘Client’= ‘ACME’ ‘ProductClicked’ = ‘55674’ } http://www.dailyplanet.com Lorem Ipsum Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. $24,90 http://www.acme.com/products/. BUY Dynamite Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat null, $19,99 http://www.acme.com/products Bear Trap Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat null, $24,90 BUY { ‘UUID’ = ‘392f034c‘ ‘Client’= ‘ACME’ ‘ProductBought’ = ‘55674’ } http://www.criteo.com/stats #users time Acme: отчет о пользователях
- 3. 3 • Компания (упрощенно) $ $$ $$ $ Input • Быстро принять данные Transformation Output • Точные отчеты
- 4. 4 • Input Transformation Output OLTP OLAP Stored Procedures Построим AdTech-компанию!
- 5. 5 • Input Transformation Output OLTP Попытка №1: Установим 2-й MySQL OLAP Backup Restore Stored Procedures OLTP
- 6. 6 • Input Transformation Output Попытка №2: Классический ETL и шардинг App App App App App App App App App App C# ETL C# ETL C# ETL C# ETL OLAP Stored Procedures
- 7. 7 • Input Transformation Output Попытка №3: ETL на базе Data Lake App App App App App App App App App App
- 8. 8 • Input Transformation Output Kafka! App App App App App App App App App App
- 9. 9 • Input Transformation Output Сейчас App App App App App App App App App App …
- 10. 10 • “ ” 30+ команд 75K+ физических ядер, 1PB RAM, 100+ PBs хранилище данных Несколько Execution Engines (Hive, MR, Cascading, Scalding, Spark) 15T Records Read 300K Jobs 2T Records Written 10PB Data Processed /день
- 11. 11 • Данные (с репликами) 64 PB 36 % Логи Аналитика 58 PB 32 % Engine (ML,…) 24 PB 13 % Cловари 5 PB 3% Presto 4 PB 2% Legacy 4 PB 2%
- 12. 12 • Hive I. Зачем Hive? II. Hive CLI: первые шаги и грабли III. Hive на Mesos 1. Consul 2. Хуки 3. Новые клиенты 4. Мониторинг 5. Тестирование новых версий
- 13. 13 • Зачем Hive? SQL-интерфейс к данным на HDFS 1. Hive Metastore — схема данных и отображение объектов в директории и файлы HDFS 2. Hive Execution Engine (CLI или HiveServer2) — разбор, построение и выполнение запросов в Hadoop
- 14. 14 • Hive I. Зачем Hive? II. Hive CLI: первые шаги и грабли III. Hive на Mesos 1. Consul 2. Хуки 3. Новые клиенты 4. Мониторинг 5. Тестирование новых версий
- 15. 15 • CLI на железе 0.metastore Metastore Thrift Bare metal сервер CLI 1.metastore Metastore Thrift Недостатки • Galera — не верьте рекламе
- 16. 16 • Реклама Galera : • Multi-master синхронные репликации • Передача 'transaction sets’ всем нодам На практике: • Запись только на один мастер, иначе риск deadlock’ов • Чтение тоже не всегда синхронное В Criteo • Три сервера MySQL • JDBC fallback вместо DNS Round Robin Metastore и MySQL
- 17. 17 • CLI на железе 0.metastore Metastore Thrift Bare metal сервер CLI 1.metastore Metastore Thrift Недостатки • Galera – не верьте рекламе • Приложения должны размещаться на том же сервере, что и CLI • Сложно поддерживать Chef-рецепты. • Долгий цикл для запуска нового релиза – 2 недели • Сложно мониторить • Сложно масштабировать • Проблемы с тестированием новых версий Hive
- 18. 18 • Hive I. Зачем Hive? II. Hive CLI: первые шаги и грабли III. Hive на Mesos 1. Consul 2. Хуки 3. Новые клиенты 4. Мониторинг 5. Тестирование новых версий
- 19. 19 • Новое направление Mesos/Marathon Простое конфигурирование Можно управлять количеством CPU, памятью, количеством экземпляров приложения Можно одновременно иметь несколько разных Hive версий Автовосстановление (проверка состояния приложения, перезапуск) HiveServer2 Доступ через тонких клиентов Централизованный мониторинг JDBC-доступ
- 20. 20 • … HiveServer2 Thrift Client App #1 Bare metal сервер Beeline HiveServer2 Instance #1 Thrift JDBC v1.2.0 Hive на Mesos HiveServer2 Thrift Client App #N HiveServer2 Instance #M Thrift JDBC v1.2.0 … … HiveServer2 Instance Thrift JDBC v2.3.0 Metastore Instance #1 Thrift v1.2.0 Metastore Instance #K Thrift v1.2.0 … Metastore Instance Thrift v2.3.0
- 21. 21 • Hive I. Зачем Hive? II. Hive CLI: первые шаги и грабли III. Hive на Mesos 1. Consul 2. Хуки 3. Новые клиенты 4. Мониторинг 5. Тестирование новых версий
- 22. 22 • • Децентрализованный отказоустойчивый discovery- сервис и key-value хранилище • Любое Criteo Marathon’s приложение автоматически регистрируется в Consul: o Адрес приложения — хост и порты o Состояние приложения (health status) — up или down Consul
- 23. 23 • Hive I. Зачем Hive? II. Hive CLI: первые шаги и грабли III. Hive на Mesos 1. Consul 2. Хуки 3. Новые клиенты 4. Мониторинг 5. Тестирование новых версий
- 24. 24 • Hive Hooks • Metastore Discovery • Сериализация данных (SerDe) • Авторизация • Логирование запросов • ...
- 25. 25 • $ hive --service hiveserver2 # lots of crazy stuff --hiveconf hive.metastore.uris=consul://localhost:8500/hive-metastore --hiveconf hive.metastore.uri.resolver=org.apache.hadoop.hive.contrib.metastore.hooks.consul.ConsulURLHook
- 26. 26 • Hive I. Зачем Hive? II. Hive CLI: первые шаги и грабли III. Hive на Mesos 1. Consul 2. Хуки 3. Новые клиенты 4. Мониторинг 5. Тестирование новых версий
- 27. 27 • cr-beeline: обертка для beeline, берет адрес сервера из Consul Scala-клиент (мы любим Scala в Criteo) • https://github.com/criteo/hive- client • В два раза меньше по размеру, чем Hive-JDBC-Standalone jar libraryDependencies ++= Seq( "org.apache.thrift" % "libthrift" % "0.10.0", "org.rogach" %% "scallop" % "3.0.3", "org.jline" % "jline" % "3.3.0", "org.apache.hadoop" % "hadoop-common" % "2.6.5", "org.apache.hadoop" % "hadoop-auth" % "2.6.5", ) $ cr-beeline ... Beeline version 1.1.0-cdh5.11.0 by Apache Hive 0: jdbc:hive2://mesos-slave-001> Клиенты HiveServer2
- 28. 28 • Hive I. Зачем Hive? II. Hive CLI: первые шаги и грабли III. Hive на Mesos 1. Consul 2. Хуки 3. Новые клиенты 4. Мониторинг 5. Тестирование новых версий
- 29. 29 • Thrift JMX remote JMX HTTP JDWP Hive-клиенты: beeline, приложения Метрики: VisualVM, JConsole,… Метрики: Prometheus Отладка: Java IDE Текущие и завершенные запросы, открытые сессии, конфигурация WebUI
- 30. 30 • Мониторинг и оповещения Elastic Search Kibana Consul Prometheus Local Storage Graphite Grafana AlertManager E-mail Slack OpsGenie SLAB
- 31. 31 •
- 32. 32 •
- 33. 33 •
- 34. 34 •
- 35. 35 •
- 40. 40
- 41. 41
- 42. 42
- 43. 43 • Hive I. Зачем Hive? II. Hive CLI: первые шаги и грабли III. Hive на Mesos 1. Consul 2. Хуки 3. Новые клиенты 4. Мониторинг 5. Тестирование новых версий
- 44. 44 • Hive Upgrade Test Framework HiveServer2 1.2.0 Restore/Upgrade История Hive запросов с метриками Cuttle Scheduler HiveServer2 New Отчеты Backup / Restore Сравнение версий Hive • Найти обратные несовместимости в запросах • Изменения в производительности (CPU, память) https://github.com/criteo/cuttle
- 45. 45 • • Автоматическое тестирование пользовательских функций (UDF) • HiveServer2 Cluster Monitoring (HIVE-13457) Новые проекты
- 46. 46 • • Можно начинать и с одного MySQL-сервера • Hadoop решает из коробки большой ряд задач • Hive — надежный инструмент для обработки больших объемов данных. • С помощью хуков можно настроить Hive под нужды компании • Hive в облаке, с Metastore discovery на базе Consul — надежная масштабируемая система Выводы
- 47. 47 •
Notas do Editor
- Здравствуйте, коллеги. Меня зовут Александр Мазуров, я разработчик в компании Criteo, где занимаюсь разработкой и поддержкой аналитических баз данных. До этого 10 лет работал в Европейском Центре Ядерных исследований, где участвовал в разработке программ для обработки событий (так называемые Event Processing Frameworks), а также в анализе результатов эксперимента. Так что если вас интересует как там все устроено в ЦЕРНе или моя следующая тема, то Welcome подходите, спрашиваете. Мой доклад можно логически разделить на две части. Сначала я покажу эволюцию нашей платформы, расскажу какие шишки набили и как пришли к решению позволяющему нам хранить и обрабатывать большие объемы данных. Затем с масштабов компании спустимся чуть ниже и я расскажу о Hive - важном инструменте для обработки такого большого объема данных (click)
- Как много из вас знают о компании Criteo? Как я и знал немного, а между тем это большая по меркам Европы технологическая компанию в мире рекламы, c более 30 офисами по всему миру, в том числе в Москве, 7 дата центрами (Европе, Азии, Америке), В компании работают более 600 разработчиков, 200 аналитиков и более 1000 продажников. Головной офис и большинство разработчиков располагается в центре Парижа. Компания занимается прежде всего персонализированным ретаргентингом, показывая пользователям рекламу наших клиентов на других сайтах и мобильных устройствах учитываю при этом историю действий пользователя. Т.е. если вы посмотрели отеля на сайте Booking.com, а затем увидели рекламу отеля на вашем любимом сайте новостей – то это скорее всего мы! Если сравнивать. например, с AdWords, то мы ему сильно проигрываем по трафику, но берем за счет умных алгоритмов, быстрых отчетов и вообще хорошего User Experience - клиент четко понимает за что он платит деньги. (Click) Основным источником данных для нас является действия пользователей Интернета, а у нас их примерно 1.2 миллиарда уникальных в месяц. (Click) Они заходят на страницы продуктов наших клиентов (Click) (Click) Лог о заходе отправляется нам (Click) (Click) Или он заходит н а сайт нашего паблишера, например. газеты (Click) Видит рекламу и (Click) … только когда щелкаем на рекламе мы это записываем. Компания не берет плату за показы (Click) (Click) (Click) Так же мы записываем факт покупки товара (Click) Мы предоставляем клиентам отчеты, они платят нам деньги, а мы платим нашим издателям Цель компании оптимизировать доход. Это как я уже говорил достигается за счет умных алгоритмов. Основанных на машинном обучении и натренированных на поведение пользователей интернета. Думаю теперь вы имеете представление о компании и сейчас я расскажу о том как компания из небольшого стартапа превратилась в большую компанию. Эту история может быть вполне справедлива и для вашего будущего стартапа, так что делайте выводы
- Давайте начнем с того, что функции почти каждой компании можно сократить до одной – трансформация данных в доход. Т.е # Быстро принять и записать данные # Агрегировать их, вытянуть полезную информацию # … и сделать выводы на основе данных # В нашем случае данные - это действия посетителей, а выход, например, отчеты клиентам о том почему они должны нам заплатить на основе этих данных или о том как мы должны улучшить наши алгоритмы
- Итак давайте построим AdTech компанию. У вас есть идеи и небольшой бюджет, и что вы делаете # Берете готовое решение, в нашем случае, банерокрутилка OpenX, закачиваете туда банеры, сбоку прикручиваете алгоритмы # И все пишите в базу, отчеты генерируется с помощью хранимых процедур Это простое решение хорошо работает, до тех пор пока все не начинает работать очень хорошо и увеличивается поток информации из вне. Вы становитесь жертвой вашего успеха. Проблема очевидна – конкуренция за систему ввода/вывода - online transaction processing пишет данные, а online analytical processing одновременно пытается читать. Из за этой конкуренции все становится очень медленно
- Первое, что приходи на ум – это установить второй сервер для отчетов и заносить туда данные из первой базы Стало лучше, но клиентская база растет, а у нас все еще только одна мастер база, время на backup и восстановление становятся проблемой. А еще нужны новые дата центра поближе к пользователям. Что делать?
- Решение на основе OpenX и MySQL уже не устраивают. # Внутри компании пишутся программы отвечающие за показ баннеров, real time bidding, т.е. программы которые доступны извне компании # Эти программы могут работать в разных датацентрах и пишут логи в обычный syslog # В какой-то момент времени логи выгружаются и обрабатываются нашими программами на С# и результаты записываются в SQL Server. Да, хочу заметить, что долгое время мы были ориентированы на решения Microsoft, но на текущий момент все изменилось Как мы видите мы построили современный ETL стек с разделёнными OLTP и OLAP. НО… Проблема в приложениях… Для каждого нового форматы данных приходится писать отдельную С# программу, что требует много ресурсов, К встает вопрос масштабирования – программы не справляются с большим потоком данных, нужно из как-то параллелить на многих машинах И тут на ум приходит а что если данные из логов аккумулировать в одном месте и потом обрабатывать их сколько душе угодно?
- # Тут нам на помощь приходит Hadoop. HDFS предоставляет надежное и масштабируемое хранилище для наших данных. # Hive и Cascading поверх YARN и MapReduce обеспечивают нам функции ETL, они заменили наши самописные C# программы # SQL Server остается основным бэкэндом для отчетов Теперь у нас есть реально масштабируемая платформа
- Еще одну проблему, которую нам предстояло решить – это проблему с логами. # У нас не было репликации логов по серверам. Если один из сервером с логами выходил из строя, то требовалось время на восстановление логов c этой машины и мы не могли предоставить отчеты в срок. # Тут нам на помощь пришла Kafka со встроенными релегациями и восстановление от ошибок. Мы все еще можем иметь проблемы с потерей датацентра, но сбой одного из серверов уже не проблема для нас
- На сегодняшний день у нас 7 датацентров. Мы добавили Spark и новые фреймворки для Hadoop. Для растущего объема отчетов добавляем новые базы данных. Например, сейчас к уже существуешему кластеру Vertica мы тестируем новый на 1PB на выделенных серверах. Изначально такой большое хранилище разрабатывалось для Facebook, но они от него отказались и мы решили использовать его у себя. Так же внутри нашей компании мы думаем протестировать ClickHouse. Если вам интересно, то больше про Hadoop вы можете узнать завтра в 10 утра в этом же зале от моего коллеги Сергея Корсакова.
- Если по цифрам, то Criteo обладает самым большим Hadoop кластером в Европе. Раньше мы конкурировали с Spotify в размере, но они ушли в облако Amazon. Если кратко то в день мы обрабатываем до 10PB данных и записываем в 100 петабайтное хранилище данных
- Что же ма такое храним на 100PB. Прежде всего хочу уточнить, что 100PB это с учетом реплик на HDFS, чтобы понять реальный объем данных нужно все делить на 3. # Большую часть, 64PB и 36% кластера у нас занимают сырые логи, которые большой частью хранятся в виде JSON файлов, но сейчас как и остальные данные мы начали хранить из формате parquet. Логи у нас хранятся 30 дней # Из логов мы агрегируются данные для наших аналитиков и разработчиков алгоритмов. Данные здесь у нас обычно хранятся 13 месяцев (кроме словарей – из мы можем хранить сколько угодно Хочу здесь заметить, что логи и аналитика у нас хранятся в структурированном виде и доступны из Hive, о котором я поговорю позднее. Остальное пространство у нас занимают Presto, старые данные и данные пользователей. Из всего выше вы увидели как за 10 лет компания из маленького стартапа с одной MySql сервером превратилась в компанию ворочающую большими объемами данных. И по секрету скажу скоро мы открываем новый датацентр и почти удвоим наш Hadoop кластер. Нет, я не пропагандирую всем переходить на Hadoop, можно начать с малого, с малого бюджета и если полетит то вы можете добиться того же.
- Hive предоставляет SQL интерфейс к структурированным файлам на HDFS. Эти файлы должны быть в формате поддерживаемым Hive, например, CSV или Parquet. Информация о том какие данные и где хранятся в файлах должны быть зарегистрированы в Hive Metastore Помимо Metastorа. Hive Command Line Interface или HiveServer отвечают за парсинг запросов, построение и запуск плана выполнения запроса на кластере. В качестве экзекутора мы вы основном используем медленный MapReduce, а не Spark, поскольку в нашем случае более непривередлив в плане работы с памятью для произвольных запросов
- Наша история работы с Hive началась чем-то похожим на первые шаги в начале пути компании – мы выбрали самый простой способ. Этот способ заключался в том, что мы установили толстый Command Line клиент для Hive на машины где работали наши аналитики и запускались программы для обработки данных с HDFS. Это своего рода gateway перед Hadoop кластером. Метастор размещался так же на меньшем выделенном сервере и клиент подключался к нему через Thrift протокол. В качестве backendа для метастор у нас использовался Galera кластер с MySql базами, в случае проблем с один из серверов Hive CLI автоматически переключался на второй. # Какие же недостатки. Этот подход сильно напоминает монолит в мире разработки программ # Приложения должны размещаться на том же сервере, что и CLI, а с учетом того все это находится под управлением Chef # У нас возникают проблемы с поддержкой Chef рецептов, которые пишутся несколькими командами и из за этого у нас # Был долгий цикл запуска нового релиза – 2 недели, а нам хотелось бы в течение часа! # Остальные проблемы связаны со сложностью мониторинга того что запускается в Hive CLI – это отдельный процесс в пользовательском пространстве и непонятно куда и как складываться логи # И проблема масштабирования и управления нагрузкой– нужно было покупать новые сервера, которые порой простаивали бы
- Здесь я вас хочу дать один совет – не верьте реклами # Из рекламы Galera кластера мы хотели получить multi-master репликации # А на практике получили алерты по среди ночи из за deadlock’ов, да и чтение не всегда синхронное # В итоге у нас только один мастер и мы используем JDBC fallback вместо DNS Round Robin. Это наше слабое место
- Наша история работы с Hive началась чем-то похожим на первые шаги в начале пути компании – мы выбрали самый простой способ. Этот способ заключался в том, что мы установили толстый Command Line клиент для Hive на машины где работали наши аналитики и запускались программы для обработки данных с HDFS. Это своего рода gateway перед Hadoop кластером. Метастор размещался так же на меньшем выделенном сервере и клиент подключался к нему через Thrift протокол. В качестве backendа для метастор у нас использовался Galera кластер с MySql базами, в случае проблем с один из серверов Hive CLI автоматически переключался на второй. # Какие же недостатки. Этот подход сильно напоминает монолит в мире разработки программ # Приложения должны размещаться на том же сервере, что и CLI, а с учетом того все это находится под управлением Chef # У нас возникают проблемы с поддержкой Chef рецептов, которые пишутся несколькими командами и из за этого у нас # Был долгий цикл запуска нового релиза – 2 недели, а нам хотелось бы в течение часа! # Остальные проблемы связаны со сложностью мониторинга того что запускается в Hive CLI – это отдельный процесс в пользовательском пространстве и непонятно куда и как складываться логи # И проблема масштабирования и управления нагрузкой– нужно было покупать новые сервера, которые порой простаивали бы
- В компании стали активно развивать собственное облако на основе Mesos и Marathon. На данный момент у нас более 600 нодов. Мы стараемся наши приложения переносить туда. Для каждого приложения у нас отдельный контейнер с простым конфигурационным файлом, мы можем легко масштабироваться, запускать одновременно несколько версий Hive и плюс в случае проблем mesos может перезапустить приложение # Но вместо Hive CLI мы должны использовать HiveServer2, на Mesos к которому подключаются тонкие клиенты. HiveServer это единая точка входа для клиентов, что упрощает мониторинг и отладку. То есть мы переходим от монолита к клиент-серверной архитектуре.
- # Итак у нас есть Мезоз # Мы развертываем на нем наши Hive сервера и # Метастор сервера. Как Hivesever находит Metastore сервера, которые могу то появляется, исчезать? # Через Consul. Еще год назад такой возможности не было в Hive, но с помощью наших разработчиков в компании мы добавили такую возможность в основную ветку Hive и вы сейчас можете это использовать. На данный моменте мы наверно единственная компания, которая использует такую динамическую систему # Для хранения метаданных мы используем те же базы, что и для Hive CLI # Приложения с железа также перекочевали в Mesos # и так же получают адреса сервисов через Consul. # В дополнение мы может тестировать новые версии и конфигурации Hive. # Так же для наших аналитиков есть возможность получать доступ к Hive с гетевеев Поскольку мы используем ту же базу, что и hive CLI, то две системы могут существовать одновременно. Мы сейчас постепенно выводим из пользования Hive CLI
- В компании у нас большой Consul cluster и любое Mesos приложение у нас автоматически регистрирует свой адресы и открытые порты. С помощью выбора произвольного hive сервера мы может управлять распределение нагрузки
- Как я говорил мы написали hook для Hive серверы, который определяет адрес метастора через консул. Нам пришлось написать не только реализацию хука но и его интерфейс. Я хочу сказать, что в Hive очень богатая система хуков, которые вы можете настраивать через конфигурационные файлы. Я перечислю только те для которых мы написали свои реализации: Для логов у нас собственный формат данных в JSON – для его чтения мы написали свой код В продакшене мы не хотим, чтобы наши пользователи добавляли собственный JAR файлы с реализацией их Hive функций – хук для авторизации Или мы сделали так, чтобы информация о запущенных запросах шла в Kafku – хук для перехвата всех запросов Там еще много всевозможных хуков – вы можете настроить систему под себя
- Вот примерно так у нас выглядит конфиг – указваем адрес консул сервиса и как нам обрабатывать этот адрес.
- Мы должны обеспечить нашим пользователям удобные доступ к Hive # Из командной строки мы сделали так, чтобы consul был незаметен – пользователи не должны знать к какому hive серверу они подключаются # В комании мы любим Scala, у нас работает, например, разработчик web frameworka Lift на скале - Гийом Борn Для удобства разработчиком у нас есть небольшая библиотека в открытом доступе. Пользуйтесь
- У нас каждый hive server предоставляет следующие сервисы – # # Через Thrift протокол подключаются клиента для запуска запросов # C помощью JMX # вы может смотреть на метрики online # Или определенные метрики для вашего Prometheus сервиса # Через JDWP вы можете отлаживать ваш hive server в любимой IDR. А если вы грамотно настроите Hadoop, то смотреть на out of memory dump # И так же мы можем посмотреть на состояние сервиса через web интерфейс