Комментарии 10
А как поведет себя логгер в случае тротлинга со стороны сервера телеграм?
Отправка реализована в отдельном потоке, поэтому часть сообщений уйдет, часть просто не будет отправлена. На производительность основного кода это не должно будет повлиять. Делал по примеру того, как Microsoft сделала это в своей консольном логгере.
Одним из преимуществ — возможность оперативно смотреть возникающие критические ошибки. То есть изначально этот канал для логов актуален больше для чрезвычайных событий, которых много и сразу не будет.
Ну, и по многим причинам такой логгер применим больше для личных или мелких проектах, что тоже понижает количество данных.
Вы сами указали что он бесплатный, а место — стоит денег
Чем делать отдельный логгер не лучше ли target renderer для какого-нибудь NLog? Можно будет пользоваться единой конфигурацией. Кстати кажется например с NLog можно прям запрос делать через HTTP POST, типа https://github.com/nlog/NLog/wiki/WebService-target, сам не пробовал, но надо попробовать...
Так это не отдельный логгер. Это провайдер для родной экосистемы логирования .NET
Совместно с ним можно использовать все остальные провайдеры. Или подключить свой кастомный: https://docs.microsoft.com/en-us/dotnet/core/extensions/custom-logging-provider
Если используется markdown, то его надо эскейпить, иначе сообщение в телегу просто не придет.
UPD (библиотечка обновилась)
Используйте"Telegram": {
"LogLevel": {
"Default": "Warning"
},
"AccessToken": "1234567890:AAAaaAAaa_AaAAaa-AAaAAAaAAaAaAaAAAA",
"ChatId": @channel_namee",
"Source": "Human Readable Project Name"
}
Вместо"Telegram": {:)
"LogLevel": "Warning",
"AccessToken": "1234567890:AAAaaAAaa_AaAAaa-AAaAAAaAAaAaAaAAAA",
"ChatId": @channel_namee",
"Source": "Human Readable Project Name"
}
Провайдер логирования для Telegram (.NET 5 / .NET Core)