• За что bim-менеджер получает 100 тысяч и как им стать. Личный опыт
    0
    Не всё то data, что числа. Не всё то science, что напрямую исходит из высшей математики. :)))
    ИМХО, «бухгалтера» таки неслабо оперируют теориями. И с числами общаются «мама не горюй» :).
    А мне кажется, что проектирование (и чуть более современное моделирование) невероятно крепко связано с анализом, алгоритмами (ППР, например :)) и различными науками всевозможными.
    В идеале всё это действительно engineering… Но в реалиях России и текущем периоде есть таки нюансы…
  • За что bim-менеджер получает 100 тысяч и как им стать. Личный опыт
    0
    Ок. Возможно…
    Просто бим-информация со сложных бим-моделей каких-либо крупных строительных объектов крайне опосредовано используется именно в бизнесс-процессах (возможно пока. Мы работаем над этим… :)).
    Изначально массированное наполнение объектов модели здания всяческой информации преследовало цель быстрой «генерации» хорошо оформленной технической документации: чертежей, всевозможных аннотаций, подписей, отчётов, спецификаций и ведомостей.
    Над структурированием, группировкой, стандартизацией такой информации как раз и трудятся бим-менеджеры… Ну и крупные корпорации и альянсы. Яркий представитель «BIM-контейнера» — формат IFC. Открытый, множество параметров стандартизованы, потребляется уймой САПР…
    Поэтому знания, о том, как качественно юзать все эти свойства, параметры, где и как это всё дальше отображено, как сохранить тех. процесс прямой/обратной связи между объектами моделей и экспортными данными в иных средах… — ну такая себе работа с данными. :))) Поэтому и обозвал data science.
    Автор не зря упоминает тесную связь с программированием (ну и с IT-сферой), собственно знания из IT весьма нужны.
  • За что bim-менеджер получает 100 тысяч и как им стать. Личный опыт
    +1
    Основное в Информационном Моделировании и Строительстве (вольный перевод аббревиатуры BIM) — неграфическая информация о цифровом двойнике реального объекта физического мира.
    Если это модель кирпича, то в его параметрах может содержаться невероятно много информации о нём: состав, прочностные характеристики, данные о производителе, особенностях технологии кладки и многое другое.
    Вся ценность такого информационного моделирования в работе с подобной информацией и связями между этой информацией.
    Вот эту работу с неграфическими данными (весьма обширными) я и назвал data science. Сама отрасль проектирования входит (или граничит...) с более обширной отраслью — строительством. А там есть и экономика (спецификации, сметы, закупки), и логистика (такелажные объёмы, удельные упаковочные массы и подобное… :) ), и менеджмент сроков всех этапов.
    Ну вот такая связь… Если нужно ещё подробностей, с удовольствием напишу. Спрашивайте.
  • За что bim-менеджер получает 100 тысяч и как им стать. Личный опыт
    +2
    Первая публикация и такой срач в комментах… Что ж так нетерпимо?!
    Все же помнят про «кибениматику»? :) Математика пополам с кибернетикой. BIM — весомая область в data science. Узкая, но весомая.
    Я ушёл в IT через проектирование и зачатки BIM.
    ALTEC_SYSTEMS, жду статью про то, как BIM пришёл на смену плоским чертежам, и «рисование» сменилось моделированием. Так держать.
  • Программист не должен решать задачи бизнеса
    +5
    Писать «сферического коня в вакууме», потому что могу — не самое выгодное занятие. Таки неплохо бы иметь «точки приложения» своего продукта. ИМХО, хороший программный продукт — результат работы какой-никакой команды. И платит всей этой команде бизнес, поэтому не получится не обращать внимания на то, как изделие продаётся…
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Алерты прямо из приложения мне недоступны. Тоже костылестроение.
    Эластик, как база-хранилище уже используется, хватит с неё. :)
    Графана пока на уровне «как там мой Graylog, покажешь?». От неё тоже бОльшего не нужно.
    Тут в комментах про нагрузку многие высказывались, решение всем стОит подбирать по «размеру». :)

    Касательно грейлога — по сравнению с эластиком — это именно, что готовый продукт. Со своими ограничениями, но и очень классными фичами. Типа алертов, потоков, интеграции с лдап и всем прочим. Эластик тоже можно «сварить» со всем нужным, но необходимо тогда погружаться в его специфику

    Да. Как-то так на Грейлог и вышел. Вроде легко запустился, вроде всё сразу делает…

    sentry — мониторинг. Я таки хотел логи.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    NLog вполне официально говорит про http target и GELF у себя на сайте в разделе Integrations. :)
    Повторюсь: можно и самому написать отправку под NLog. Я описал, как сам поступил. :)
    Попробовать Graylog несложно, я и *.yml для быстрого развёртывания подарил.
    Про алерты в Эластике руки не дошли почитать, может и это использую. Спасибо.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Затратно в чём? Траффик? Да не особо… И да — уровень логгирования на продакшене на уровне INFO. Иначе, многовато лишнего.
    Буферизации не делал сначала, но теперь добавил обёртку асинхронную, где «набивается» очередь сначала. Но она для моих задач не так критична. Правда.
    Изначально, конечно, хотелось знать, что на «неизвестно-где-стоящем-компе» случился exception. :)
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Рад, что пригодилась моя статья. :)
    Под капотом Graylog'а и так Elasticsearch. И как раз вчера на 9200 контейнера с Elasticsearch прикрутил Grafan'у. Я, если честно, в неё не особо умею, но попробую… Коллеги её любят, пусть глядят. :)
    Graylog не то чтобы выигрывает чем-то, а просто чуть удобнее стартовать. Быстрее как-то. Есть удобная web-морда. Вменяемая настройка фильтров и АЛЕРТОВ. Мне очень уж оповещения хотелось об определённых ошибках. Если честно был бы голый ELK, если бы Graylog не встретил и не почитал вечерок.
    Расширения под перечисленные логгеры естественно пишут люди. Как и сами логгер-библиотеки… Не знаю даже, что тут сказать. На самом деле, кроме NLog я в проекте использую стороннюю target для отправки по http. NLog позволяет custom target создавать… Но опять же, выбрал чуть более простой путь. Объект цели создаётся, в конфигурацию добавляется без ошибок, к просадкам по скорости отправки ничего не добавляет. Не появилось причин не доверять…
    В комментах уже упоминали гарантированность доставки, но это не сильно к расширениям относится.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Пара ответов:
    — и оттуда, и оттуда.
    — http. Сделали имя третьего уровня, пробросили на 12201 контейнера Graylog.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Вот это пропустил. Что ж, тогда либо подождать, либо для выравнивания последовательности сообщений использовать sequenceId.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    +1

    Не смог оставить этот вопрос.
    На самом деле при передаче сообщения лога в виде gelf тот же NLog снабжает его sequenceId. По нему можно сортировать сообщения в самом Graylog.
    Ну и нашёл блог самой Эластики: https://www.elastic.co/blog/journey-support-nanosecond-timestamps-elasticsearch
    Говорят, что наносекунды реальны. :)
    Надеюсь Вам это поможет.

  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Действительно, такое возможно. Пока у меня ни подобного опыта, ни решения подобной проблемы нет.
    Искренне надеюсь на Хабр. :) В комментариях много головоломок решалось. Сам видел.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Я могу ошибаться, но порядок в сообщениях можно же привязать к timestamp самого сообщения. И порядок появления (следования) сообщений в эластике станет не так важен… Или я не так понимаю проблему?
    timestamp 2020-04-25 17:35:48 +03:00 — вот такое представление в Грейлоге. Но само поле передаётся NLog'ом: «timestamp»: 1385053862.3072 — точность выше.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Не встречался. Может кто-нибудь увидит вопрос и подскажет?
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    :) Он неплох. Как только подведёт, уйду на что-то другое. Обязательно.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    NLog поддерживает передачу структур из коробки.
    при этом не занимаясь ручным наполнением вот этих параметров и не ограничиваясь одним лишь message и тем, что гвоздями забито в GelfTarget. И потом в грейлоге же спокойно ищешь и по UserId и по UserName, потому что они отдельные поля..

    Не-не-не… Как раз в «бонусном» методе я упрощаю себе жизнь с отправкой чего-то с кучей параметров и свойств. :) И полей в Graylog'е появляется множество, и никакой ручной работы.
    То, чем набил в настройках GraylogHttpTarget — это то, что паровозом с каждым сообщением улетает. Т.с. базовая информация.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Решение с volum'ами банально не масштабируется. Если эти контейнеры уходят в какой-нибудь кубер, да даже банально просто на другом докер-хосте поднимать — сразу возникает вопрос, чтоб эти файлы и там собирались, права/место…

    Сложно с этим спорить. Скорее всего это именно так.
    Вариант с кроликом тоже плох тем, что в случае проблем сети — мы опять теряем логи (т.е. если nlog не смог достучаться до кролика, или тот перегружен и очередь на отправку растёт == жрёт ресурсы хоста).

    NLog продолжает писать в файлик. Совсем потерять несколько тяжелее. Но да, вероятность пропусков существует.
    Т.е. простой вариант — это, например, тот же logstash/filebeats для чтения/отправки логов из файла и на отдельном volume (да, я про его проблемы сказал, но это всё же простой вариант при ограниченом кол-ве хостов). Тот же filebeat будет гарантировать доставку логов после восстановления сети, может отвечать за ротацию итд. С ним тоже проблемы есть, но как вариант на старт — вполне.

    Можно и так… Но хотелось чего-то простого на стороне исполняемого приложения.
    Дальше развивать есть куда — лучше писать просто в stdout и собирать уже docker logging driver'ом, им же сразу класть в очередь (кролик/кафка/что у вас там ещё есть), чтоб гарантировать доставку и оттуда перекладывать в graylog. Потому что у грейлога тоже могут быть проблемы с приёмом: забитый cpu, забитый elasticsearch, сам грейлог может падать… Так что лучше иметь буфер перед ним тоже. Но это уже другая история про другие объёмы и требования.

    Да. Всё так. Но, когда речь о десктоп-приложении docker logging driver'а нет. Вот шлём сразу хоть куда-нибудь. :) Скорее всего позже буду делать это через шину (Rabbit, Kaffka или whatever...)

    Про AsyncWrapper почитаю. Спасибо. Как-то упустил…
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Тут возразить нечего. D нарушена.
    По поводу microsoft.extensions.logging поясню: это наследие от моей «специализации». При написании плагинов к САПР (Revit, Autocad) приходится балансировать на грани записи информации о событиях и сбора данных. Сбором данных увлекаться не стОит…
    Либу из своего класса в статье делать никогда и не планировал. Да и контекст hosted assembly он такой себе… Буду считать это для себя следующим шагом. :)
    structured logging мне как раз и обеспечивает Graylog.
    Сойдёмся на том, что это один их вариантов. ИМХО, он имеет право на жизнь.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    У нас объёмы пока не такие. Но пока опыт позитивный. :)
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0

    Спасибо за комментарий. :)

  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Ну… не так уж, чтобы совсем фейспалм… :) Масштабирование, прогноз нагрузки, архитектура резервирования — это всё итерационные задачи. Нет предела совершенству. Как разраб, я мониторю жизненные показатели элементов этой системы. Но в определённой степени. В одиночку такая инфраструктура не создаётся и не поддерживается. Поглядим, во что это вырастет.
    Формально с моей стороны «ракеты ушли». Дальше «будем посмотреть». А надёжностью и мощностью агрегатора логов я, конечно же, займусь. Спасибо. :)
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    1. Абсолютно надёжных систем не бывает в принципе… :) Но я дал для примера файлик для композера: там volume'ы живут отдельно. Поэтому, если сам сервис «испортился» можно «переподнять» весьма быстро. А данные (с высокой вероятностью) должны выжить. Но тут только поиск, только эксперименты.
    2. Думал об этом. Причин не нашёл. Rabbit'а хватает. Честно.
    3. Как раз Грейлог позволяет работать с отчётами, алертами, фильтрами, потоками… :) Этим и привлёк.

    Не буду утверждать, что это конечное решение и я на этом остановлюсь.
  • Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт
    0
    Вечер добрый. :) Спасибо.
    Масса ответов.
    1. Под капотомм Грейлога как раз живёт эластик и монго. Просто морда понравилась.
    Сложности эксплуатации на весьма большую долю решаются тем, что грейлог поддерживает связывание в «кластер». Каждый экземпляр — одна нода. Если с ней проблемы, но слушать может другая.
    2. Да. Вероятность такой ситуации возможна. Но ведь есть файлик с логом! :)
    И как раз начал работать над логами в режиме NLog->RabbitMQ->Graylog. А это уже гораздо надёжнее. +из пункта выше ноды…
    3. Признаюсь, с sentry не знаком. Есть такое упущение. В любом случае я заострил внимание на разумности сбора сообщений. + в некоторых случаях внешний мониторинг с обратной связью не применим (параноидальные настройки сети на предприятиях, например...).

    В любом случае решение не самое идеальное и, возможно, не охватывает все варианты использования и ситуации, но… для удовлетворения базовых потребностей в контроле своих продуктов подходит. :)
    Спасибо за реакцию. Наводит на размышления.
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    +1
    Хорошо. А есть смысл где-то указывать, что статья изменена?
    … новенький я… не привык ещё…
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    0
    А… :) Лично не юзаю, вот и слэнгом не владею. Теперь буду.
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    +1
    Согласен. И даже немного допилил уже, только статью не стал править. Считаете нужно?
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    0
    Пардон… На кубике?… что-то не понял…
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    0
    Да. Как раз ответил на это ниже. :)
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    0
    Подтверждаю. Сам натыкался на такие описания…
    И действительно много где рекоментуют убивать connections, когда они особо не нужны.
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    0
    Хм… Действительно, особо не за чем его закрывать.
    Будем воспринимать этот кусок кода, как цитату от авторов фреймворка xBIM :).
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    0
    Смею предположить, что в методе Close() для этого объекта есть и Dispose() (внутри...). Это распространённое поведение похожих steam объектов. Вроде как попользовались и избавились, когда больше не нужен.
  • Linux контейнер для .NET Framework приложения (когда сложно уйти на .Net Core)
    0
    Образ собран, контейнер с ним запущен и работает. Всё это на удалённой Linux-машине. Поэтому новые сборки засылаю туда *.bat'ом примерно таким:

    set CONT=containername
    set FLD=appfolder
    set REMOTE=-H tcp://ip.ad.res.ss:port
    docker %REMOTE% cp .\_pub\. %CONT%:/%FLD%
    docker %REMOTE% restart %CONT%