А нет ли у Вас опыта сборки Nuke'ом прямо в Gitlab?
Очень уж хочется вынести сборку инсталлеров InnoSetup прямо на машину с Gitlab для нескольких desktop-приложений…
Копаюсь в сети, готовлюсь попробовать такой «конвейер», но вменяемых доков маловато. :)
Не всё то data, что числа. Не всё то science, что напрямую исходит из высшей математики. :)))
ИМХО, «бухгалтера» таки неслабо оперируют теориями. И с числами общаются «мама не горюй» :).
А мне кажется, что проектирование (и чуть более современное моделирование) невероятно крепко связано с анализом, алгоритмами (ППР, например :)) и различными науками всевозможными.
В идеале всё это действительно engineering… Но в реалиях России и текущем периоде есть таки нюансы…
Ок. Возможно…
Просто бим-информация со сложных бим-моделей каких-либо крупных строительных объектов крайне опосредовано используется именно в бизнесс-процессах (возможно пока. Мы работаем над этим… :)).
Изначально массированное наполнение объектов модели здания всяческой информации преследовало цель быстрой «генерации» хорошо оформленной технической документации: чертежей, всевозможных аннотаций, подписей, отчётов, спецификаций и ведомостей.
Над структурированием, группировкой, стандартизацией такой информации как раз и трудятся бим-менеджеры… Ну и крупные корпорации и альянсы. Яркий представитель «BIM-контейнера» — формат IFC. Открытый, множество параметров стандартизованы, потребляется уймой САПР…
Поэтому знания, о том, как качественно юзать все эти свойства, параметры, где и как это всё дальше отображено, как сохранить тех. процесс прямой/обратной связи между объектами моделей и экспортными данными в иных средах… — ну такая себе работа с данными. :))) Поэтому и обозвал data science.
Автор не зря упоминает тесную связь с программированием (ну и с IT-сферой), собственно знания из IT весьма нужны.
Основное в Информационном Моделировании и Строительстве (вольный перевод аббревиатуры BIM) — неграфическая информация о цифровом двойнике реального объекта физического мира.
Если это модель кирпича, то в его параметрах может содержаться невероятно много информации о нём: состав, прочностные характеристики, данные о производителе, особенностях технологии кладки и многое другое.
Вся ценность такого информационного моделирования в работе с подобной информацией и связями между этой информацией.
Вот эту работу с неграфическими данными (весьма обширными) я и назвал data science. Сама отрасль проектирования входит (или граничит...) с более обширной отраслью — строительством. А там есть и экономика (спецификации, сметы, закупки), и логистика (такелажные объёмы, удельные упаковочные массы и подобное… :) ), и менеджмент сроков всех этапов.
Ну вот такая связь… Если нужно ещё подробностей, с удовольствием напишу. Спрашивайте.
Первая публикация и такой срач в комментах… Что ж так нетерпимо?!
Все же помнят про «кибениматику»? :) Математика пополам с кибернетикой. BIM — весомая область в data science. Узкая, но весомая.
Я ушёл в IT через проектирование и зачатки BIM. ALTEC_SYSTEMS, жду статью про то, как BIM пришёл на смену плоским чертежам, и «рисование» сменилось моделированием. Так держать.
Писать «сферического коня в вакууме», потому что могу — не самое выгодное занятие. Таки неплохо бы иметь «точки приложения» своего продукта. ИМХО, хороший программный продукт — результат работы какой-никакой команды. И платит всей этой команде бизнес, поэтому не получится не обращать внимания на то, как изделие продаётся…
Алерты прямо из приложения мне недоступны. Тоже костылестроение.
Эластик, как база-хранилище уже используется, хватит с неё. :)
Графана пока на уровне «как там мой Graylog, покажешь?». От неё тоже бОльшего не нужно.
Тут в комментах про нагрузку многие высказывались, решение всем стОит подбирать по «размеру». :)
Касательно грейлога — по сравнению с эластиком — это именно, что готовый продукт. Со своими ограничениями, но и очень классными фичами. Типа алертов, потоков, интеграции с лдап и всем прочим. Эластик тоже можно «сварить» со всем нужным, но необходимо тогда погружаться в его специфику
Да. Как-то так на Грейлог и вышел. Вроде легко запустился, вроде всё сразу делает…
NLog вполне официально говорит про http target и GELF у себя на сайте в разделе Integrations. :)
Повторюсь: можно и самому написать отправку под NLog. Я описал, как сам поступил. :)
Попробовать Graylog несложно, я и *.yml для быстрого развёртывания подарил.
Про алерты в Эластике руки не дошли почитать, может и это использую. Спасибо.
Затратно в чём? Траффик? Да не особо… И да — уровень логгирования на продакшене на уровне INFO. Иначе, многовато лишнего.
Буферизации не делал сначала, но теперь добавил обёртку асинхронную, где «набивается» очередь сначала. Но она для моих задач не так критична. Правда.
Изначально, конечно, хотелось знать, что на «неизвестно-где-стоящем-компе» случился exception. :)
Рад, что пригодилась моя статья. :)
Под капотом Graylog'а и так Elasticsearch. И как раз вчера на 9200 контейнера с Elasticsearch прикрутил Grafan'у. Я, если честно, в неё не особо умею, но попробую… Коллеги её любят, пусть глядят. :)
Graylog не то чтобы выигрывает чем-то, а просто чуть удобнее стартовать. Быстрее как-то. Есть удобная web-морда. Вменяемая настройка фильтров и АЛЕРТОВ. Мне очень уж оповещения хотелось об определённых ошибках. Если честно был бы голый ELK, если бы Graylog не встретил и не почитал вечерок.
Расширения под перечисленные логгеры естественно пишут люди. Как и сами логгер-библиотеки… Не знаю даже, что тут сказать. На самом деле, кроме NLog я в проекте использую стороннюю target для отправки по http. NLog позволяет custom target создавать… Но опять же, выбрал чуть более простой путь. Объект цели создаётся, в конфигурацию добавляется без ошибок, к просадкам по скорости отправки ничего не добавляет. Не появилось причин не доверять…
В комментах уже упоминали гарантированность доставки, но это не сильно к расширениям относится.
Не смог оставить этот вопрос.
На самом деле при передаче сообщения лога в виде gelf тот же NLog снабжает его sequenceId. По нему можно сортировать сообщения в самом Graylog.
Ну и нашёл блог самой Эластики: https://www.elastic.co/blog/journey-support-nanosecond-timestamps-elasticsearch
Говорят, что наносекунды реальны. :)
Надеюсь Вам это поможет.
Действительно, такое возможно. Пока у меня ни подобного опыта, ни решения подобной проблемы нет.
Искренне надеюсь на Хабр. :) В комментариях много головоломок решалось. Сам видел.
Я могу ошибаться, но порядок в сообщениях можно же привязать к timestamp самого сообщения. И порядок появления (следования) сообщений в эластике станет не так важен… Или я не так понимаю проблему?
timestamp 2020-04-25 17:35:48 +03:00 — вот такое представление в Грейлоге. Но само поле передаётся NLog'ом: «timestamp»: 1385053862.3072 — точность выше.
при этом не занимаясь ручным наполнением вот этих параметров и не ограничиваясь одним лишь message и тем, что гвоздями забито в GelfTarget. И потом в грейлоге же спокойно ищешь и по UserId и по UserName, потому что они отдельные поля..
Не-не-не… Как раз в «бонусном» методе я упрощаю себе жизнь с отправкой чего-то с кучей параметров и свойств. :) И полей в Graylog'е появляется множество, и никакой ручной работы.
То, чем набил в настройках GraylogHttpTarget — это то, что паровозом с каждым сообщением улетает. Т.с. базовая информация.
Решение с volum'ами банально не масштабируется. Если эти контейнеры уходят в какой-нибудь кубер, да даже банально просто на другом докер-хосте поднимать — сразу возникает вопрос, чтоб эти файлы и там собирались, права/место…
Сложно с этим спорить. Скорее всего это именно так.
Вариант с кроликом тоже плох тем, что в случае проблем сети — мы опять теряем логи (т.е. если nlog не смог достучаться до кролика, или тот перегружен и очередь на отправку растёт == жрёт ресурсы хоста).
NLog продолжает писать в файлик. Совсем потерять несколько тяжелее. Но да, вероятность пропусков существует.
Т.е. простой вариант — это, например, тот же logstash/filebeats для чтения/отправки логов из файла и на отдельном volume (да, я про его проблемы сказал, но это всё же простой вариант при ограниченом кол-ве хостов). Тот же filebeat будет гарантировать доставку логов после восстановления сети, может отвечать за ротацию итд. С ним тоже проблемы есть, но как вариант на старт — вполне.
Можно и так… Но хотелось чего-то простого на стороне исполняемого приложения.
Дальше развивать есть куда — лучше писать просто в stdout и собирать уже docker logging driver'ом, им же сразу класть в очередь (кролик/кафка/что у вас там ещё есть), чтоб гарантировать доставку и оттуда перекладывать в graylog. Потому что у грейлога тоже могут быть проблемы с приёмом: забитый cpu, забитый elasticsearch, сам грейлог может падать… Так что лучше иметь буфер перед ним тоже. Но это уже другая история про другие объёмы и требования.
Да. Всё так. Но, когда речь о десктоп-приложении docker logging driver'а нет. Вот шлём сразу хоть куда-нибудь. :) Скорее всего позже буду делать это через шину (Rabbit, Kaffka или whatever...)
Про AsyncWrapper почитаю. Спасибо. Как-то упустил…
Тут возразить нечего. D нарушена.
По поводу microsoft.extensions.logging поясню: это наследие от моей «специализации». При написании плагинов к САПР (Revit, Autocad) приходится балансировать на грани записи информации о событиях и сбора данных. Сбором данных увлекаться не стОит…
Либу из своего класса в статье делать никогда и не планировал. Да и контекст hosted assembly он такой себе… Буду считать это для себя следующим шагом. :)
structured logging мне как раз и обеспечивает Graylog.
Сойдёмся на том, что это один их вариантов. ИМХО, он имеет право на жизнь.
Очень уж хочется вынести сборку инсталлеров InnoSetup прямо на машину с Gitlab для нескольких desktop-приложений…
Копаюсь в сети, готовлюсь попробовать такой «конвейер», но вменяемых доков маловато. :)
ИМХО, «бухгалтера» таки неслабо оперируют теориями. И с числами общаются «мама не горюй» :).
А мне кажется, что проектирование (и чуть более современное моделирование) невероятно крепко связано с анализом, алгоритмами (ППР, например :)) и различными науками всевозможными.
В идеале всё это действительно engineering… Но в реалиях России и текущем периоде есть таки нюансы…
Просто бим-информация со сложных бим-моделей каких-либо крупных строительных объектов крайне опосредовано используется именно в бизнесс-процессах (возможно пока. Мы работаем над этим… :)).
Изначально массированное наполнение объектов модели здания всяческой информации преследовало цель быстрой «генерации» хорошо оформленной технической документации: чертежей, всевозможных аннотаций, подписей, отчётов, спецификаций и ведомостей.
Над структурированием, группировкой, стандартизацией такой информации как раз и трудятся бим-менеджеры… Ну и крупные корпорации и альянсы. Яркий представитель «BIM-контейнера» — формат IFC. Открытый, множество параметров стандартизованы, потребляется уймой САПР…
Поэтому знания, о том, как качественно юзать все эти свойства, параметры, где и как это всё дальше отображено, как сохранить тех. процесс прямой/обратной связи между объектами моделей и экспортными данными в иных средах… — ну такая себе работа с данными. :))) Поэтому и обозвал data science.
Автор не зря упоминает тесную связь с программированием (ну и с IT-сферой), собственно знания из IT весьма нужны.
Если это модель кирпича, то в его параметрах может содержаться невероятно много информации о нём: состав, прочностные характеристики, данные о производителе, особенностях технологии кладки и многое другое.
Вся ценность такого информационного моделирования в работе с подобной информацией и связями между этой информацией.
Вот эту работу с неграфическими данными (весьма обширными) я и назвал data science. Сама отрасль проектирования входит (или граничит...) с более обширной отраслью — строительством. А там есть и экономика (спецификации, сметы, закупки), и логистика (такелажные объёмы, удельные упаковочные массы и подобное… :) ), и менеджмент сроков всех этапов.
Ну вот такая связь… Если нужно ещё подробностей, с удовольствием напишу. Спрашивайте.
Все же помнят про «кибениматику»? :) Математика пополам с кибернетикой. BIM — весомая область в data science. Узкая, но весомая.
Я ушёл в IT через проектирование и зачатки BIM.
ALTEC_SYSTEMS, жду статью про то, как BIM пришёл на смену плоским чертежам, и «рисование» сменилось моделированием. Так держать.
Эластик, как база-хранилище уже используется, хватит с неё. :)
Графана пока на уровне «как там мой Graylog, покажешь?». От неё тоже бОльшего не нужно.
Тут в комментах про нагрузку многие высказывались, решение всем стОит подбирать по «размеру». :)
Да. Как-то так на Грейлог и вышел. Вроде легко запустился, вроде всё сразу делает…
sentry — мониторинг. Я таки хотел логи.
Повторюсь: можно и самому написать отправку под NLog. Я описал, как сам поступил. :)
Попробовать Graylog несложно, я и *.yml для быстрого развёртывания подарил.
Про алерты в Эластике руки не дошли почитать, может и это использую. Спасибо.
Буферизации не делал сначала, но теперь добавил обёртку асинхронную, где «набивается» очередь сначала. Но она для моих задач не так критична. Правда.
Изначально, конечно, хотелось знать, что на «неизвестно-где-стоящем-компе» случился exception. :)
Под капотом Graylog'а и так Elasticsearch. И как раз вчера на 9200 контейнера с Elasticsearch прикрутил Grafan'у. Я, если честно, в неё не особо умею, но попробую… Коллеги её любят, пусть глядят. :)
Graylog не то чтобы выигрывает чем-то, а просто чуть удобнее стартовать. Быстрее как-то. Есть удобная web-морда. Вменяемая настройка фильтров и АЛЕРТОВ. Мне очень уж оповещения хотелось об определённых ошибках. Если честно был бы голый ELK, если бы Graylog не встретил и не почитал вечерок.
Расширения под перечисленные логгеры естественно пишут люди. Как и сами логгер-библиотеки… Не знаю даже, что тут сказать. На самом деле, кроме NLog я в проекте использую стороннюю target для отправки по http. NLog позволяет custom target создавать… Но опять же, выбрал чуть более простой путь. Объект цели создаётся, в конфигурацию добавляется без ошибок, к просадкам по скорости отправки ничего не добавляет. Не появилось причин не доверять…
В комментах уже упоминали гарантированность доставки, но это не сильно к расширениям относится.
— и оттуда, и оттуда.
— http. Сделали имя третьего уровня, пробросили на 12201 контейнера Graylog.
Не смог оставить этот вопрос.
На самом деле при передаче сообщения лога в виде gelf тот же NLog снабжает его sequenceId. По нему можно сортировать сообщения в самом Graylog.
Ну и нашёл блог самой Эластики: https://www.elastic.co/blog/journey-support-nanosecond-timestamps-elasticsearch
Говорят, что наносекунды реальны. :)
Надеюсь Вам это поможет.
Искренне надеюсь на Хабр. :) В комментариях много головоломок решалось. Сам видел.
timestamp 2020-04-25 17:35:48 +03:00 — вот такое представление в Грейлоге. Но само поле передаётся NLog'ом: «timestamp»: 1385053862.3072 — точность выше.
Не-не-не… Как раз в «бонусном» методе я упрощаю себе жизнь с отправкой чего-то с кучей параметров и свойств. :) И полей в Graylog'е появляется множество, и никакой ручной работы.
То, чем набил в настройках GraylogHttpTarget — это то, что паровозом с каждым сообщением улетает. Т.с. базовая информация.
Сложно с этим спорить. Скорее всего это именно так.
NLog продолжает писать в файлик. Совсем потерять несколько тяжелее. Но да, вероятность пропусков существует.
Можно и так… Но хотелось чего-то простого на стороне исполняемого приложения.
Да. Всё так. Но, когда речь о десктоп-приложении docker logging driver'а нет. Вот шлём сразу хоть куда-нибудь. :) Скорее всего позже буду делать это через шину (Rabbit, Kaffka или whatever...)
Про AsyncWrapper почитаю. Спасибо. Как-то упустил…
По поводу microsoft.extensions.logging поясню: это наследие от моей «специализации». При написании плагинов к САПР (Revit, Autocad) приходится балансировать на грани записи информации о событиях и сбора данных. Сбором данных увлекаться не стОит…
Либу из своего класса в статье делать никогда и не планировал. Да и контекст hosted assembly он такой себе… Буду считать это для себя следующим шагом. :)
structured logging мне как раз и обеспечивает Graylog.
Сойдёмся на том, что это один их вариантов. ИМХО, он имеет право на жизнь.