Отличный видос сегодня посмотрел про организацию логирования в "нормальных" проектах.
Волей случая зацепила меня и тема логирования. Новый человек пришедший в компанию открыл нам глаза на то что у нас логирования в компании как такового вообще нет. Мы все это время думали что простого console.log/print/System.Debug с последующим чтением текстовой портянки это верх мастерства. Но как оказывается это просто дно разработки. В общем мне была поставлена задача изучить ELK стек и попробовать поучаствовать в наведении порядки.
Начал изучать тему и понял насколько мы скучно живем в нашей компании 
Вот отличный пример как надо заморачиваться чтобы ваш проект не доставлял вам попаболь по ночам.
Все больше погружаюсь в тему .net и понимаю что все что было напилено за столько лет на python/nodejs не серьезно. Да, python/nodejs (php/ruby туда же) оправдано для разработки каких-то простых web приложений. Но только сейчас до меня стало доходить в чем разница enterprise разработки и разработки "домашних" проектов.
Пара полезных ссылок для себя на память:
https://www.elastic.co/what-is/elk-stack - "ELK" is the acronym for three open source projects: Elasticsearch, Logstash, and Kibana.
https://serilog.net/ - simple .NET logging with fully-structured events
Не связано с темой логирования, но полезно для изучения
https://graphviz.org/ - Graphviz is open source graph visualization software.
https://dotnet.microsoft.com/apps/aspnet/signalr - Incredibly simple real-time web for ASP.NET
https://devblogs.microsoft.com/aspnet/introducing-project-tye/ - an experimental developer tool that makes developing, testing, and deploying microservices and distributed applications easier.
https://datalust.co/seq - centralized structured logs for .NET, Java, Node.js
Главный вопрос - можно ли это все применить в рамках форса?
Вот это хороший вопрос!
У меня он тоже появился. Пока точно не скажу, но если удастся (или возможно уже есть готовое решение, но я не люблю готовые решения) заставить форс отправлять логи в ElasticSearch то это конкретно для нашего проекта это будет бомба. Потому что в SF части проекта логирование отсутствует от слова ВООБЩЕ. В случае каких либо проблем наши SF разрабы могут только руками развести - пока не воспроизведем ничего не узнаем. А смысл логирования как раз в том чтобы понять что произошло без непосредственного воспроизведения и желательно видеть что происходить не конкретно сейчас но и происходило в прошлом.
А на счет .net - развиваться вне Salesforce всегда полезно! Есть задачи которые Salesforce не под силу и данный опыт позволит толкнуть развитие проекта дальше.
Немного поясню. Просто отправлять логи в ElasticSearch не проблема. Проблема в том как сделать это красиво. Чтобы логи собирались и отправлялись независимо от текущего контекста SF. Чтобы создание логов не тормозило основную логику и чтобы вывалившийся эксепшен не сьедал логи и при этом не сожрать тонну лимитов salesforce. Это хорошая задачка на подумать. Если будет время подумать в этом направлении для SF то обязательно поделюсь своим прогрессом.
Я "логи" отправляю себе на почту. try...catch и в catch sendEmail со stack trace.
Ты правильно поставил в кавычки - ты отправляешь не логи, а эксепшены которые отловил.
А что делать с эксепшенами которые не отловил?
А что если надо логать инфу просто о жизни приложения? Какие REST запросы приходили, какие страницы и кем открывались, что вообще и когда происходило в коде.
Скажу из опыта что логирование в Salesforce отсутствует как понятие от слова "вообще"! В принципе оно и понятно - Salesforce разорится если предоставит внутренний инструмент для ведения логов. А логи это крайне серьезный инструмент для понимания как работает код. Вот к примеру у нас в компании из НЕ-SF проектов в день собирается 1Гб логов. И это кстати очень мало по меркам нормальных проектов. Зато мы можешь открыть и посмотреть когда и какие запросы приходили, собрать информацию о жизни любого запроса, собрать информацию о запросах к базе, скорости работы и прочей фигне.
Зато как касается вопрос Salesforce тут тьма непроглядная. Типичный пример - SF работает с внешним сервисом по REST API. Какого хрена не логать запрос и ответ? Каждый раз у же на протяжении многих лет самый распространенный и тупой вопрос от SF тимы - "у нас что-то не работает, но мы не знаем что и почему!" а еще хуже "клиент написал что у него вчера не работало, но мы не знаем что и почему" НО уверены что это связано с внешним сервисом. Какой запрос, куда посылали никто сказать не может. Приходится садиться и опираясь на временной период искать запросы которые могли стать причиной отказа логики в SF.
И это хорошо если на нашей стороне запрос отвалился с 500 Internal Exception. А если запрос вернул 200 ответ, но возможно формат не тот или входные параметры не те? Тут можно собирать удочки и идти домой.
А было бы логирование нормальное в SF - взял бы SF разработчик посмотрел в логах что тогда-то и тогда-то уходил запрос на внешний сервис, пришел ответ, а потом выпал эксепшен. Сразу видно где реально проблема. Весь поиск причины занял бы пару минут, и можно было бы со 100% уверенностью писать разрабам внешнего сервиса мол "идарасы, почему вы шлете нам не тот ответ который в документации описан"? 
Но чет все равно ничего не меняется
Ты зря гонишь, дебаги уже давно есть, просто чтобы их посмотерть тебе нужно -
Запросить доступ через систему в ЛМА, запросить доступ к оргу
А потом уже дебажить логи путем отправки новых запросов, потому что маловероятно, когда тебе приходит баг что чтото не работает, ктото пытался включать логирование на уровне в сф. Это касаемо проекта Ж)
А кастомные логи тянут на полноценный пакет, который никто не оплатит(это 1), а 2 - это то что каждый лог тянет CPU time + heap size. И лучше оставить рабочуюю основную часть пакету(которая приносит деньги), чем иметь логирование
Это касается только СФ, в .net / python - ресурсы считай неограничены, можно хоть 5 пакетов для логировнаия поставить
Вот я про это и говорю. Чтобы получить логи надо воспроизвести ошибку. Этим никто заморачиваться не хочет, а чаще ошибку просто не получается воспроизвести. Поэтому самый частый таск который к нам присылают из SF это скриншот экрана от клиента с ошибкой и сообщение мол нихера не работает разбирайтесь. Хорошо если на скрине хотя бы ошибка видна
Таки да, но вопрос логирования должен закладываться в разработку изначально. Почему про это никто не думает странно. Кстати это касается и НЕ SF комманд . Уже прошло года 4 как существует проект, и только сейчас задумались а правильно ли мы ведем логи
Зато кстати новый проект который запустили новые разрабы стартанул очень грамотно. Они сразу подняли отдельное приложение для логирования (самописное) со своей базой и стали логать туда все запросы приходящие/уходящие с ответами. Каждый чих логают. Я недавно над их базой с логами писал веб морду для поиска по логам и удобному отображению инфы. Сейчас все от этого тула и логов писаются от радости, потому что видят и с ходу понимают что у какого клиента происходит и в каком месте отвалилось. И не надо ничего воспроизводить. Просто шедевр. А было бы по старинке начался бы ад - слей базу локально, подними приложение локально, воспроизведи ситуацию с запросами. На старом проекте я так делаю постоянно. И это уже порядком подзаипало. Куча инстансов, куча баз данных. Нужный инстанс пока локально поднимешь, пока настроишь все, воспроизведешь это издец.
Логирование сжирает свои ресурсы и тут ты должен определиться(не как разраб, а как дядя который вливает деньги), хочешь видеть логи или хочешь продать продукт(и поднять бабла). А как я уже писал - логи отжирают свой кусок из ресурсов, например задебажить Request/Response в случае большого запроса - сжирает 0.5 секунды CPU тайма(это сериализация исходящего и десереиализация входящих данных), а всего таких секунд - 10.
Каждый System.debug оставленный в коде отжирает по 0.01-0.1 секунды(варьируется)
Получилось суммарно больше 10 секунд - лови CPU timeout
А сейчас представь, что тебе надо отправить эти логи на какой-то API, чтобы потом при случае посмотреть,
все запросы на API в одной транзакции суммируются, если твой API долго будет отвечать, твой таймаут в 2 минуты(лимит сф) потихонечку будет ожираться и на действительно важные действия(по типу интеграции с какой нибудь сложной системой) не останется времени и свалится ошибка с таймаутом. Да это можно обойти через асинхронную отправку, но тут будут свои сложности с валидацией ошибок, не будет гарантии что твой лог ушел и тд.
Да и СФ - вероятнее всего на код-ревью пошлет тебя нахер, с тем что ты на какой то левый API сливаешь целиком все запросы.
Если делать логирование на орге - требуется много места, кто за это будет платить? Клиент который покупает пакет, точно не хочет платить за место, которое по идее вообще не должно использоваться на хранение левых данных, так как он покупает продукт, а не систему логирования.
С тем же логированием на орге(как и с API), не все однозначно, так как с большой долей вероятности можно будет вылетать по CPU или heapsize.
Опять же, кто будет платить за разработку или за пакет в случае покупки стороннего пакета?
Поэтому логируют только ошибки которые сваливаются в try{}catch() блоках, а не каждый пук с запросами на API
Ну тут уж надо выбирать. Либо платить человеко/часы за общения с клиентами, воспроизведение ошибок, недополученную прибыль от недовольных клиентов или потратить деньги на толковое логирование и разруливание проблем на лету пока клиент об этом не стал стучать. Понятное дело что если бы Salesforce мог то уже давно бы предлагал нормальное логирование из коробки.
В общем я к тому, что мы все тут собравшиеся про логирование ничего не знаем и не думаем. Стоит обратиться к опыту реальных мировых проектов чтобы начать делать хорошо, пока проект еще находится на начальной стадии. Когда появятся клиенты, будет уже поздно 
Либо платить за таких специалистов, которые сразу сделают так, что понятие баг пропадёт из проекта(по крайней мере на проде) и останутся только улучшения и, иногда, доработки, когда сделали что-то не так как клиент представлял
п.с. я редко вообще встречаю менеджмент в местных компаниях, который ценит качество кода, т.к. это дорого и многие клиенты неплохо покупают и джуниорский код, продаваемый как сеньорский
п.п.с. про баги, вызванные чужим говнокодом на проде, можно не писать. От этого можно уйти только если говнокодеры пропадут совсем
Либо платить за таких специалистов, которые сразу сделают так, что понятие баг пропадёт из проекта(по крайней мере на проде) и останутся только улучшения и, иногда, доработки, когда сделали что-то не так как клиент представлял
п.с. я редко вообще встречаю менеджмент в местных компаниях, который ценит качество кода, т.к. это дорого и многие клиенты неплохо покупают и джуниорский код, продаваемый как сеньорский
п.п.с. про баги, вызванные чужим говнокодом на проде, можно не писать. От этого можно уйти только если говнокодеры пропадут совсем :)
Чем круче спец, тем сложнее разбирать его косяки :)
АХАХАХА! В точку!!! Актуально пипец
Либо платить за таких специалистов, которые сразу сделают так, что понятие баг пропадёт из проекта(по крайней мере на проде) и останутся только улучшения и, иногда, доработки, когда сделали что-то не так как клиент представлял
п.с. я редко вообще встречаю менеджмент в местных компаниях, который ценит качество кода, т.к. это дорого и многие клиенты неплохо покупают и джуниорский код, продаваемый как сеньорский
п.п.с. про баги, вызванные чужим говнокодом на проде, можно не писать. От этого можно уйти только если говнокодеры пропадут совсем :)
Чем круче спец, тем сложнее разбирать его косяки :)
Моё мнение, что крутость нужно определять по принципу - код должен быть таким, чтобы написал сеньор и понял джуниор, а не написал джуниор, а понял только сеньор
