Pull to refresh

Comments 13

заставляет использовать определённый формат логов

У нас используется OpensSearch (бесплатный аналог Kibana). Может потреблять логи в любом формате. Трейсбеки из текстовых логов разбиваются по строке на отдельные записи и сгрупировать их можно только по имени сервиса. В общем получается нечитаемое месиво. Так, что требование по формату не так уж и плохо, оно сильно повышает качество работы. Так как данных у нас много, то индексы построенны только по определённым полям.

Работает с любыми форматами/схемами логов

У вас на картинке цветом отображается уровень логирования и поле время подозрительно похоже на время в логе. Как у вас получается это делать с любым форматом?

Что выйдет из такого вот лога?

from logging import exception
try:
    1/0
except:
    exception("My error")

"""
ERROR:root:My error
Traceback (most recent call last):
  File "<input>", line 2, in <module>
ZeroDivisionError: division by zero
"""

Я, наверное, не совсем точно выразился. Имелось в виду, что оно работает с любой схемой таблицы, а не с любым форматом логов. То, как логи парсятся и попадают в базу - отдельный вопрос.

Я ваш проект видел пару недель назад. Только тогда не задалось с демкой, не пускало.
Выглядит приятно. Напоминает DataDog. Интересно сделано решение с добавлением фильтров по полям по выбранному сообщению.

FlyQL - это вы сами придумали DSL?

Сортировка логов жестко зашита?

А как именно не пустило? :) (вроде никто больше не жаловался)

FlyQL - это вы сами придумали DSL?

да

Сортировка логов жестко зашита?

В настоящий момент да. Были мысли сделать возможность задавать сортировку. Но вообще, в первую очередь целился именно в просмотр логов, а там обычно сортировка как таковая не очень нужна

Честно говоря уже не помню.

FlyQL напомнил DataDog язык запросов.


Вопрос: можно ли настроить кастомно поля для логов Otel? Они у себя имеют ResourceAttributes и LogAttributes, а у меня они Attributes и Resource.

Да. Сам по себе telescope не знает ничего про Otel. Он может работать с произвольной clickhouse таблицей (пока там есть time поле)

Т.е. то, как называются поля в базе совершенно не важно

Я подумал, что сортировка не сделана из-за issue ClickHose с order by и limit - он выбирает вообще все столбцы даже, те что в сортировке не нужны. Потому, если указать в запросе Attributes и Resources, то запрос очень долго будет отрабатывать или помрет, т.к. будет грузить гигабайты данных.

Мы это обходим или не используя order by, или с подзапросом.

Именно это искали!! как вовремя!! будем пробовать 100% !!

Приходите с фидбеком. Очень ценно получить инфу от тех, кто пробует использоавть.

очень прикольно, но, оно прибито гвоздями к clickhouse? может сделать разные источники данных?

Спасибо. Технически, нет - не прибито.

Как раз недавно добавил поддержку чтения логов для docker containers, что бы иметь возможность использовать telescope для локальной разработки (релиза и обновления документации еще не было - запилю как будет время).

В будущем, вероятно, появится какая-то система плагинов, что бы можно было добавить свой источник или изменить поведение существующих (например то, как строиться SQL запрос ,добавив в эту механику своей логики)

Sign up to leave a comment.

Articles