Change log level at runtime for a cf application based on SAP Java Buildpack - sap-cloud-platform

Following the guide over here:
https://sap.github.io/cloud-sdk/docs/java/guides/logging-overview#logging-overview
I am trying to use CF CLI cf set-env command to change the logs levels at runtime.
This commands executes successfully and the log levels are only changed when I do a cf restage srv or cf restart srv. srv is the name of my application.
Is there any alternative where I don't have to stop the cf application and still be able to change the log levels at runtime?

No, I think in order to reload the setting from environment variables a reload is required.
You could instead implement a new endpoint in your application where you set the log level programatically. But that depends on the logging framework you are using. E.g. for Logback this can be done as described here.

Related

Keycloak configuration on startup cli script

I'm trying to configure a dockerized Keycloak server from a startup script I put on:
/opt/jboss/startup-scripts
I found the CLI commands description to add properties as well as some other examples but don't know which properties must I add/modify in order to, for example, add a realm to Keycloak.
Is there a complete listing of Keycloak configurable properties anywhere?
The Keycloak Docker image supports execution of two types of scripts mouted to /opt/jboss/startup-scripts:
WildFly .cli scripts.
Any executable (chmod +x) script
Due to your links I assume you are interrested in the WildFly scripts.
I do not think that there is a complete listing of configurable properties for the WildFly application server used by the Keycloak Docker image. But you can Get all configuration and runtime details from CLI.
If you want to add a realm to Keycloak you can use the KEYCLOAK_IMPORT environment variable as described on the Keycloak Docker image page at "Importing a realm".

starting Mock Server automatically when running restbird docker container

i want to use the "Mock Server" feature provided with https://restbird.org/ .
When starting restbird via the provided docker image, it listens on localhost:8080 by default.
Unfortunately the configured "Mock Server" instances still need to be started via the Web Frontend as it is described in the documentation here:
https://restbird.org/docs/mock-run.html#run-mock-server
Is there a way to automatically start the "Mock Server" instances when running the docker image without logging in into the backend (via admin/admin) and clicking the "start" button ?
Reason is, i want to start the mock server inside a gitlab pipeline where i have no further interaction possibilities after the container has been started.
I can not find anything like this in the documentation.
Thanks a lot for any clues - or if it is not possible i cam make a feature request.
I have found the solution myself. One can start a specific Mock Server as described in:
https://restbird.org/docs/API-MockServer.html#start-specific-mockserver-case
This can be scripted into my pipeline after executing the docker run command.

How to check syslog in GAE

I am using the standard environment of GAE / PY.
I'd like to confirm syslog, but I could not confirm it with stackdriver logging(only request_log and activity_log).
Can not you confirm syslog with App Engine standard environment?
You do not have access to the actual syslog of the systems on top of which your standard env GAE app instances are running. I suspect the user-provided app code might not even have write permissions to such logfile.
If you're looking for logs produced by your app (for example by using the logging facility, as recommended by ), they're bundled under the request_log entries for the requests that triggered the respective code execution, see Reading Application Logs on Google App Engine from Developer Console

Change Phoenix framework process user with setgid and setuid after deploy?

We've finished our first phoenix application for internal company use and it is time now to deploy it. It will be hidden under Apache server (yep, nginx is not available as an option), and according to PCI DSS standard it should be run under readonly user. Node.js devs use some functions like this in their startup configs to change user from 'deployer' which can write to filesystem to 'runner' (readonly user) which just read the code.
So, when my app is starting up after deploy, user should be dynamically changed from 'deploy' to 'runner'. What is the best way to do it? BTW, I'm not completely understood how Cowboy works, but I guess it just runs in the background like unicorn or puma?

Is there a recommended 3rd party solution to managing logs on Bluemix?

We have a handful of Ruby (Rails/Sinatra) apps and are looking for an easy means of managing retention, search and analysis of our logs for these applications.
The initial problem was that every time we'd push a new version of our apps the logs would disappear.
We then started streaming our logs to a file via a terminal using:
cf logs AppName
however the logfiles get very big, very fast and quickly become a problem.
We know that the Bluemix Monitoring and Analytics service provides a lot of the function we need. We're looking that over but want to know if there are other recomended/proven options.
Thanks
We found several 3rd party apps that provide the functions we need.
To use any of these we first had to configure third party logging on Bluemix and used the steps below.
Any 3rd party logger that supports the syslog protocol can be used. The initial setup, registration and configuration of the log manegement service, is well covered at Configuring Selected Third-Party Log Management Services.
What will come out of the configuration step is a syslog URL which will be the destination for your logs.
Once the logging service is configured a user-provided service instance needs to be created to stream the logs to the logging service. We did this using:
cf create-user-provided-service <user-provided-service_name> -l <syslog_URL>
Last step is to bind the service instance to our Ruby apps.
cf bind-service AppName <user-provided-service_name>
For the changes to take effcet, we then had to restage our ruby apps:
cf restage AppName
There was a brief delay between when we'd see the logs generated and when they'd show up in the logger service but overall this is working out ok for us so far.