Logstash syslog input from docker container - java

I have a java application running in a docker container on a docker host. The application uses log4j for logging and logs to syslog. I want to be able to send my syslog logs to logstash.
I changed the configurations in rsyslog config file to :
*.* ##<logstash host ip>:514
and I have in my logstash config file for syslog:
input {
syslog {
type => syslog
port => 514
}
}
and in logstash logs I got errors saying syslog tcp listener died and
exception=>#<Errno::EACCES: Permission denied - bind(2)
I thought I should probably specify where the host is in logstash configs and added the ip address of my dockerhost + port to the config file but I still get the same errors.
How can I tell logstash to look at the docker container on dockerhost for logs? am I missing a component here?
Thanks.

You need to run the process as root. normal users (ie non root) cant bind to ports less than 1024 without some setuid trickery

Related

How to set intellij remote debug?

I am trying to debug my app in testing environment, my app is running in pod, I said 'pod' because I am not familiar with Kubernetes, its manage client looks like this:app running schematic diagram. I have learn I should set idea like this idea RUN/Debug Configurations schematic diagram. And should restart and redeploy my app, I changed Dockfile firstly. the origin instruction is FROM xxx/java:alpine VOLUME /tmp ADD recruitment.jar app.jar ENTRYPOINT ["java","-Xmx2048m","-jar","/app.jar"] and I changed this to FROM xxx/java:alpine VOLUME /tmp ADD recruitment.jar app.jar ENTRYPOINT ["java","-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005","-jar","/app.jar"] but it always show error like this Error running 'face_remote': Unable to open debugger port (888.88.888.888[not real]:5005): java.io.IOException "handshake timeout". I am not sure with this ip,sicne I use 'ping 888.88.888.888' instruction can not success. I use this ip because Swagger request url's domain name's ip is this.this main enter image description here. and I guess if the app is running in docker or k8s and it will have a different Interactive mode. not same like just running in linux
most of the attached image are not visible.
IP address should be accessible from your local system
[888.88.888.888] note sure this is correct.
debug port also need to be mapped from your local system
-use port forwarding
ex:kubectl port-forward 5005:5005
If you have configure port forwarding then you can use localhost:5005 for debugging
I see three things that you can check:
Check the IP address:
The jar file runs inside a Docker container, which runs inside a pod. To access the pod you usually go through a service and an ingress. The ip you are using is most likely hitting the ingress/service or any other higher layer.
To attach a remote debugger, you will need to connect directly to the PodIP. One way of doing this is to first connect to your kubernetes cluster using the tool kubectl (some configuration required) and make a port forward from your pod: kubectl port-forward my-pod-c93b8b6df-8c4aa 5005:5005 pod (as an example, the pod instance name is my-pod-c93b8b6df-8c4aa).
This will open a connection from your local computer into the pod. Then you will need to identify the PodIP by kubectl describe pods my-pod-c93b8b6df-8c4aa and use that in IntelliJ
Check if the port is exposed:
Make sure you expose the port 5005 from the pod in your test environment (similar to exposing a port when you run the container locally).
How to do this depends a bit on how you are running your Kubernetes cluster. If you use Helm chart, you can just add a configuration like this in the port section of your deployment yaml:
- containerPort: 5005
name: debug
protocol: TCP
Check debug-command address:
Last thing is to make sure you are adding the correct address in the command line option. As IntelliJ suggest in the debug editor: for JDK9+ use …suspend=n,address=*:5005 and for JDK8 and below use …suspend=n,address=5005

Change of port number not workingin sprintboot

I changed default port number from 8080 to 8082 in application.properties file using server.port=8082. Even after changing port number, if I try to run sprint boot app, server is taking default port 8080 and application is not starting.
Error message;
Description:
Web server failed to start. Port 8080 was already in use.
Action:
Identify and stop the process that's listening on port 8080 or configure this application to listen on another port.
i solved it like this
Solution
Enter 'server.port='8080' (changed port number) in the following 'application.properties' file where you can create a project.
After connecting to the terminal
Type 'sudo lsof -i :[port number you want to check]' to see which ports are running.
Delete server.port and run it again.

Connect JVisualVM to a Remote Wildfly Instance?

I'm trying to connect JVisualVM, running on my local machine, to a remote machine which is running a WildFly server (version 8.1.0, to be specific.)
I didn't configure the WildFly server myself, and I don't know who did, but I do know that I can log in as an administrative user from my local machine by pointing my browser at:
https://[ip address of the remote machine]:9443/console
Note that it's https, not ordinary http, and that the port for that has been set to 9443 (I think the default is 8080 or 9990 or something... IDK, I saw a lot of port numbers online. I have been explicitly told that http was disabled for this WildFly server).
I can SSH into the remote machine. I can navigate to the bin directory for WildFly and run jboss-client.sh. I have to connect on port 9999 (I think the default is 9990 for that?)
I copied the jboss-client.jar (under bin/client) to my local machine and ran JVisualVM from the command line like this:
.\jvisualvm.exe -cp:a C:\[path to]\jboss-client.jar
It launches fine. File > Add Remote Host: Then I entered the IP. OK. I right clicked on it under Remote in the tree and picked Add JMX Connection. I entered
service:jmx:http-remoting-jmx://[ip]:9999
I checked off that I wanted to use the security credentials and entered the username and password. Checked off to save the security credentials. Left "Do not require SSL Connection" unchecked. Hit OK. It immediately spat out the message
Cannot connect to admin#service:jmx:http-remoting-jmx://[ip]:9999 using service:jmx:http-remoting-jmx://[ip]:9999
I also tried the port 9443, 9990, and 8080 instead. None of those worked. I tried https instead of http in the protocol name. That also didn't work.
What am I missing? How is it that I can access the console, and connect with jboss-client.sh, but I can't use JVisualVM? Is there some log I can use somewhere to see what's wrong? Maybe someone can point out a configuration I've missed somewhere?
Not sure if it's important or not, but my local machine is running Windows 10 with JDK8 installed. The WildFly server is using Java 6 on CentOS 6.3.
You need to add the jboss-client.jar (or jboss-cli-client.jar) to the class path for JVisualVM. The library can be found in the bin/client directory of the WildFly install.
I used the following command to add the library to the class path.
jvisualvm --cp:a ~/servers/wildfly-10.0.0.Final/bin/client/jboss-client.jar
Then I used service:jmx:remote+http://[ip]:[port] and was able to connect.
I don't know if someone else is also (still) having the same issue (Wildfly10 on a remote machine where management console is available at 9443 with HTTPS). The following worked for me.
For ssh connections:
Starting jvisualvm with jboss-client.jar
jvisualvm --cp:a #JBOSS_HOME/bin/client/jboss-client.jar
Using the following connection string:
service:jmx:remote+https://remote-server:9443
NOTE: I used here remote+https
Provide username and password
Hope this helps.
you missed run jstatd command in remote host ,
this little program is RMI server that possible connection from client to remote host though you using jmx connection it used jmxrmi protocol for that connection .
so first in remote host create file name as security.policy with this contain :
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
off course you must in file section for linux put explicit path and then of creation this file put it in bin directory of jdk.home
then you should run this command on remote host
$JAVA_HOME/bin/jstatd -J-Djava.security.policy=path of /security.policy -J-Djava.rmi.server.hostname=remote ip address -J-Djava.net.preferIPv4Stack=true
then you could connect to server off course with correct settings.
Include jboss-cli-client.jar and jboss-client.jar under \lib\visualvm\platform\lib and restart jvisualvm to pickup new jars.

java remote debugging Tomcat app: Why does the JVM not listen?

I want to remote debug an application running in Tomcat 7. Tomcat is running as a service on a Win2008 server.
I added the following to the Java options in the Java Configuration Panel of Tomcat:
-Xdebug -Xrunjdwp:transport=dt_socket,address=4711,server=y,suspend=n and opened the firewall on my workstation and the server for this port.
But when I try debugging from IntelliJ 9 on my workstation, I get an error message Unable to open debugger port : java.net.ConnectException "Connection timed out: connect". The jvm is the standatd Sun/Oracle 64 bit JVM version 1.6.0_27.
I verified that the command line parameters are in use by accessing ManagementFactory.getRuntimeMXBean().getInputArguments() within the application deployed to Tomcat and logging the result to the log file.
I verified via Wireshark on my workstation and on the server that the TCP request on port 4711 is sent from my pc and arriving on the server, but there is is no answer. Running netstat -a on the server does not show a process listening on this port. So I assume somehow Tomcat/JVM does not start the remote debugging.
You need to put -Xdebug and -Xrunjdwp... on separate lines in the Java panel of the Tomcat Service Configuration Panel.
So having:
-Xdebug -Xrunjdwp:transport=dt_socket,address=4711,server=y,suspend=n
will not work, but:
-Xdebug
-Xrunjdwp:transport=dt_socket,address=4711,server=y,suspend=n
will.

Connect remote server for logging using Log4J

I want To Connect to the remote server to write my log files using Log4J Socket Appender
My log.properties file is as below
log4j.rootLogger=DEBUG, BLAH
# to connect to the remote server
log4j.appender.BLAH=org.apache.log4j.net.SocketAppender
# set set that layout to be SimpleLayout
log4j.appender.BLAH.layout=org.apache.log4j.SimpleLayout
#log4j.appender.BLAH.File= admin.log
log4j.appender.BLAH.Port= xx
log4j.appender.BLAH.RemoteHost= <remoteIp>
I tried connecting localhost too with port number 22 and 8080
I am making a mistake some where in the connection .
I get the following error
log4j:ERROR Could not connect to remote log4j server at [localhost]. We will try again later.
or
Give me any suggestions to write the log files in a remote server machine.
You should have a server running which listens to a given port. The log4j should connect to this server for logging.
Type the following in command prompt to start the listener
Java org.apache.log4j.net.SimpleSocketServer 4712 PATH_TO_THE_FILE\log4jServer.properties
Eg
java org.apache.log4j.net.SimpleSocketServer 4712 C:\log4j-server.properties
log4j-server.properties may contain something like this.
> log4j-server.properties will contain normal configuration of log4j.
> log4j.rootLogger=debug, stdout
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.Target=System.out
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%t %-5p %c{2} - %m%n
In the client side, your log4j config will look like this
log4j.rootLogger=DEBUG, BLAH
# to connect to the remote server
log4j.appender.BLAH=org.apache.log4j.net.SocketAppender
# set set that layout to be SimpleLayout
log4j.appender.BLAH.layout=org.apache.log4j.SimpleLayout
#log4j.appender.BLAH.File= admin.log
log4j.appender.BLAH.Port= 4712
log4j.appender.BLAH.RemoteHost=10.225.226.58
Replace the IP and Port(without conflicting the standard ports) as per your configuration.
Hope this would help.
Port 22 and 8080 are usually used by SSH and HTTP respectively. The SocketAppender is expecting to talk to a SocketNode using its own TCP-based protocol. So you need to start one up, on a different port of your choice.
Note that when you try to log to a remote server, you'll need to have that port open on the firewall.

Categories

Resources