В идеальном мире вы бы не записывали в локальную файловую систему то, что вам нужно сохранить. Можно писать кэшированные файлы или артефакты, которые можно просто воссоздать, но не стоит помещать туда что-то важное.
https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#filesystem
Локальная файловая система, открытая для вашего приложения, является эфемерной, и хранить там важные вещи небезопасно даже в течение короткого периода времени. Вы, безусловно, можете попытаться настроить процесс, который периодически запускается и отправляет файлы журнала из вашего контейнера куда-то еще. Однако, когда ваше приложение дает сбой, вы теряете сообщения журнала, вероятно, важные из них, в которых говорится, почему ваше приложение потерпело крах, потому что ваш процесс синхронизации не успеет запуститься до очистки контейнера.
Вместо этого вы хотите настроить свои приложения для записи своих журналов в STDOUT или STDERR.
https://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html#writing
Все, что записывается в STDOUT/STDERR, автоматически захватывается платформой и отправляется в поток журнала для вашего приложения. Затем вы можете отправить поток журналов в различные надежные места.
https://docs.cloudfoundry.org/devguide/services/log-management.html
Большинство приложений можно легко настроить для записи в STDOUT/STDERR. Вы отметили spring-boot в этом посте, поэтому я предполагаю, что ваши приложения работают под управлением Spring Boot. По умолчанию Spring Boot должен войти в STDOUT/STDERR, поэтому вам не нужно ничего делать.
Однако может случиться так, что разработчики вашего приложения специально настроили приложение для отправки журналов в файл. Найдите в файле src/main/resources/application.properties
или application.yml
вашего приложения свойства logging.file.path
или logging.file.name
. Если они есть, закомментируйте или удалите их. Это должно перевести ваши журналы в STDOUT/STDERR.
https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-logging-file-output
person
Daniel Mikusa
schedule
24.04.2020