Логирование, трассировка и метрики — это три столпа наблюдаемости системы.
На диаграмме выше представлены их определения и типичные архитектуры.
Логирование
Логирование записывает дискретные события в системе. Например, можно зафиксировать входящий запрос или обращение к базе данных как события. Логирование имеет наибольший объем данных. Стек ELK (Elastic-Logstash-Kibana) часто используется для построения платформы анализа логов. Обычно мы определяем стандартизированный формат логирования для различных команд, чтобы можно было использовать ключевые слова при поиске среди большого количества логов.
Трассировка
Трассировка обычно ориентирована на запросы. Например, пользовательский запрос проходит через API-шлюз, балансировщик нагрузки, сервис A, сервис B и базу данных, что может быть визуализировано в системах трассировки. Это полезно при попытках выявить узкие места в системе. Мы используем OpenTelemetry для демонстрации типичной архитектуры, объединяющей три столпа в единую структуру.
Метрики
Метрики обычно представляют собой агрегируемую информацию из системы. Например, QPS сервиса, отзывчивость API, задержка сервиса и т.д. Исходные данные записываются в базы данных временных рядов, такие как InfluxDB. Prometheus извлекает данные и преобразует их на основе предопределенных правил оповещения. Затем данные отправляются в Grafana для отображения или в менеджер оповещений, который затем рассылает уведомления или предупреждения по электронной почте, SMS или в Slack.
На диаграмме выше представлены их определения и типичные архитектуры.
Логирование
Логирование записывает дискретные события в системе. Например, можно зафиксировать входящий запрос или обращение к базе данных как события. Логирование имеет наибольший объем данных. Стек ELK (Elastic-Logstash-Kibana) часто используется для построения платформы анализа логов. Обычно мы определяем стандартизированный формат логирования для различных команд, чтобы можно было использовать ключевые слова при поиске среди большого количества логов.
Трассировка
Трассировка обычно ориентирована на запросы. Например, пользовательский запрос проходит через API-шлюз, балансировщик нагрузки, сервис A, сервис B и базу данных, что может быть визуализировано в системах трассировки. Это полезно при попытках выявить узкие места в системе. Мы используем OpenTelemetry для демонстрации типичной архитектуры, объединяющей три столпа в единую структуру.
Метрики
Метрики обычно представляют собой агрегируемую информацию из системы. Например, QPS сервиса, отзывчивость API, задержка сервиса и т.д. Исходные данные записываются в базы данных временных рядов, такие как InfluxDB. Prometheus извлекает данные и преобразует их на основе предопределенных правил оповещения. Затем данные отправляются в Grafana для отображения или в менеджер оповещений, который затем рассылает уведомления или предупреждения по электронной почте, SMS или в Slack.