Как контролировать (микро) услуги?

Question

У меня есть набор услуг. Каждая служба содержит некоторые компоненты.

Некоторые из них являются лицами без гражданства, некоторые из них являются состояниями, некоторые являются синхронными, некоторые из них асинхронны.

Я использовал различные подходы к мониторингу и предупреждению.

Сбор и оповещение на основе протокола. Новая реликвия. Собственный велосипед.

В основном, atm Я ищу способ, как обобщить и агрегировать важные показатели для всех сервисов в одном месте. Одна из вещей, я хочу, чтобы мы контролировали больше продуктов, чем отдельные сервисы.

В качестве конечного результата я рассматриваю его как единую панель инструментов с небольшим количеством виджетов, но, глядя на эти виджеты, я был бы в состоянии сказать наверняка, если услуги могут использоваться конечным пользователям.

Возможно, кто-то может порекомендовать мне какой-то подход/методологию. Или дайте ссылку на некоторые передовые методы.

Answer 1

Мне нравится то, чего вы пытаетесь достичь! Услуга не готова к производству, если она не будет тщательно контролироваться.

Я считаю, что вы как раз описывающими идет в темы здоровья проверки и метрик.

... Я был бы в состоянии сказать наверняка, если услуги могут использоваться конечным потребителем.

Для этого вам потребуется немного:;) Чтобы убедиться, что вы в настоящее время выполняете SLA, вы должны убедиться, что все ваши услуги являются a) запущенными и b) выполняются по запросу. Обе проблемы я предлагаю посмотреть на инструментальную цепочку StatsD. Первоначально разработанный Etsy, он стал де-факто стандартом для сбора показателей.

Чтобы гарантировать, что все ваши службы запущены, мы передаем Kubernetes. Это требует нашего описания того, что должно выполняться, быть доступным извне и т. Д. И размещать на нашей инфраструктуре. Он также гарантирует, что все должно погибнуть - они будут перезапущены. Он также помогает в таких вещах, как автомасштабирование и т. Д.! Удивительный инструмент и слава для Google! Способ, которым он обеспечивает, с медицинскими чеками. Существует несколько способов обеспечить, чтобы ваш сервисный узел, загруженный Kubernetes, был жив и пинал (а именно HTTP-вызовы и скрипты CLI, но это должно быть модульным, если вам нужно что-нибудь еще!) Если Kubernetes обнаруживает нездоровые узлы, и вместо этого запустите другой узел.

Теперь, следя за тем, чтобы все ваши услуги выполнялись должным образом, вам нужно будет собрать показатели. Для всех наших услуг (и всех отдельных конечных точек), мы собираем несколько метрик через StatsD как:

• запросов/сек
• количество ошибок возвращаемого (404, и т.д ...)
• Время отклика (среднее, медиана, процентили в зависимости от услуг SLA)
• размер полезной нагрузки (Среднее)
• иногда число одновременных запросов в конечной точке, количество экземпляров в настоящее время работает
• общие показатели, как хосты используют текущий процессор и память и время безотказной работы.

Мы собираем намного больше показателей, но это примерно так. Так как StatD стал более «спецификацией протокола», чем конкретным продуктом, на выбор вы найдете множество коллекционеров, фронтов и бэкендов. Они помогают вам визуализировать состояние вашей системы, и многие из них имеют оповещения о чем-то, или какая-то комбинация показателей выходит за пределы их пороговых значений.

Дайте мне знать, если это было полезно!

Answer 2

Существует не менее трех типов вещей, которые вам понадобятся для мониторинга: хост, на котором развертывается служба, сам компонент и SLA, а некоторые из них зависят от используемого стека программного обеспечения, а также от архитектуры.

С учетом этого вы можете использовать, например, Nagios для мониторинга оборудования, на котором развертываются службы, Splunk для показателей услуг/SLA, а также для любых ошибок, которые могут возникнуть. Вы также можете использовать пакеты SNMP, если что-то пойдет не так, и у вас есть более сложная структура поддержки, это будут ваши триггеры. Не зная, как настроена ваша инфраструктура/службы, сложно вдаваться в подробности.