I have launched Haproxy from docker.
I need to get logs of Haproxy.
Some direction may be useful.
My haproxy.config is as follows
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
As you have not wirtten which version from haproxy you use I will give you the answer to the latest version 2.0.2.
You can use the following line to print the logs to stdout.
log stdout format raw daemon debug
The full option set of the log directive is documented in the doc log
Don't forget to add log global in defaultsection or in every proxy section.
Related
I have developed a web microservice in Golang. I have used zap logger to log the application log in a file at location /var/log/myapp/myapp.log.
I want to see log information in file myapp.log through below command:
#kubectl logs mayappPod
But it is not working as by default STDOUT and STDERR output is redirected to kubectl logs command.
So my question is what exactly I am supposed to do to see the /var/log/myapp/myapp.log log through kubectl logs command.
Thanks,
Rohit
kubectl logs command just show you logs from container(s) you specified. And container got logs from STDOUT and STDERR.
The recommended way is to setup your logging library to write logs to STDOUT. But as a workaround you can create symlink from /var/log/myapp/myapp.log to /dev/stdout in your docker container.
Another option is not use kubectl logs at all. You could copy this log file from your pod using kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar see
I've updated jdk from 1.8_131 to 1.8_151 for CDH5. So i need to restart the cluster to make it take affect. In the begining i use cloudrea manager web page to restart, but it failed when zookeeper started which is the first step. Then I made a bad choice which is close cloudrea manager in terminal including kill -9 postgresql process. After that, i could't open the cloudrea manager web page.
I use following instructions to start the cluster.
service cloudera-scm-server-db start
service cloudera-scm-server start
service cloudera-scm-agent start
All of them are failed, because /var/log/cloudera-scm-server and /var/log/cloudera-scm-agent disappear.
So I creat these two files manually also include dg.log and cloudera-scm-agent.log
At this time, the server and agent could start. But server-db still can not. The next is some details.
Starting cloudera-scm-server-db (via systemctl): Job for
cloudera-scm-server-db.service failed because the control process
exited with error code. See "systemctl status
cloudera-scm-server-db.service" and "journalctl -xe" for details
journalctl -xe
The CM is using external DB. Failed to start embedded DB service, giving up
service --status-all
What i've done:
So, what should i do now? thank you thank you very much!!!
The above problem had been sovled.
If you open this /etc/cloudera-scm-server/db.properties file, which shown as below.
# cat /etc/cloudera-scm-server/db.properties
Auto-generated by scm_prepare_database.sh
#
Sat Oct 1 12:19:15 PDT 201
#
com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=TXqEESuhj5
com.cloudera.cmf.db.setupType=EXTERNAL
EXTERNAL is the crux.
In my CDH service, I use embedded postgresql as my server database. But it's not recommended to use by cloudera offical. I'm a new man on Cloudera, so I made a mistake.
I wrongly use a command which only prepared for Cloudera Manager Server external database.
/usr/share/cmf/schema/scm_prepare_database.sh postgresql scm scm scm_password
The above command can config db.properties
As long as you run above command, com.cloudera.cmf.db.setupType will be set to EXTERNAL(For more details about this, you can find in Cloudera docs)
The most direct and effective way is to reset password of scm.
Then
update the password
set Type as EMBEDDED
make port 7432 listening(you can use netstat -nltp to check)
in db.properties.
#vim cat /etc/cloudera-scm-server/db.properties
Auto-generated by scm_prepare_database.sh
Sat Oct 1 12:19:15 PDT 201
com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost:7432
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=new_password
com.cloudera.cmf.db.setupType=EMBEDDED
Now close all cloudera-scm service and restart in order server-db,server,agent.
If /var/log was cleared wrongly.
You can creat these files such as /var/log/cloudera-scm-server and /var/log/cloudera-scm-agent manually.
It is noteworthy that you should creat these file by user cloudera-scm, otherwise the log can not be written, and you won't find what error happened from log file.
I installed snort on Ubuntu 14.04 but am having issues seeing the alerts. I also want it to log the alerts to a GUI but am having issues also with MySQL database. Please guide.
You can test your installation running snort -v. Make sure you run snort as root user or else you will get an error as shown below.
Running in packet dump mode
--== Initializing Snort ==--
Initializing Output Plugins!
ERROR: Failed to lookup interface: no suitable device found. Please specify one with -i switch
Fatal Error, Quitting..
If snort -v is working then try running the basic IDS mode using
snort -d -l ./log -c snort.conf
where log is the directory where you want to store the log and alert files. snort.conf is the name of your snort configuration file. It should contain the your snort rules.
If you don’t specify an
output directory for the program, it will default to /var/log/snort
Here is the manual. https://www.snort.org/documents/snort-users-manual
I have installed the last version of Orion, 0.12.0, and when I send a queryContext or updateContext, the system gives me: "curl: (7) couldn't connect to host",
what's the problem?
Thanks!
After analyzing the user feedback in the question comments, the problem seems to be that Orion Context Broker is not running.
In order to start Orion Context Broker (see reference documentation in https://wiki.fi-ware.org/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_Installation_and_Administration_Guide#Running_Orion_Context_Broker for more detail) you can either:
Use the /etc/init.d/contextBroker start command (run it as root or with sudo privileges)
Using contextBroker command directly
In order to check that everything is ok, it uses to be a good idea to do a first run in foreground with maximum tracelevel activated, i.e. contextBroker -fg -t 0-255. Once you ensure that it works properly (e.g. curl version, etc.), then interrupt the process with Ctrl+C in the console and run it in background.
Hi I have the following problem with redis,
I have installed redis on Ubuntu 12.10 with
sudo apt-get install redis-server
However, then comes the start of the message server
[6793] February 6 21:46:54 # Warning: no config file specified, using the default config. In order to specify a config file use 'redis-server / path / to / redis.conf'
[6793] 6 February 6379 21:46:54 # Opening port: bind: Address already in use
What can I do that the server starts?
You should stop the current instance by using the following command.
/etc/init.d/redis-server stop
The default port for Redis, 6793, is already being used, so you'll need to find out what is using that port.
You can check by running: lsof -i :6793
You'll then need to either kill whatever is using that port or specify a different port for Redis using a config file.
pidof redis-server can get you the process id of redis-server;
OR lsof -i:6379 can get you the process id of the running instance with the default listening port 6379.
I would recommend you to check the log file for the troubleshooting possible errors.
Usually located at /var/log/redis/redis.log