if i have three machines running Consul,two Servers and one Client,if one of these machines is shut down,how can i get a error message form Consul,With command line 'consul members' i can get the running info:
then i want to know whether Consul provides any other methods to tell me which machine is in error state
If agent shut down you can't get error message via agent end points.
You can get error in log file (that you specified on agent start) at the server where agent was down.
Related
Problem:
I'm using apache nifi on ubuntu 18.04 on virtualbox 6.1. I manage to use apache nifi once without any problems. The log in page using localhost:8443 works the first time, but after a while when I start apache nifi again (e.g. after a reboot of the machine) and when I goto localhost:8443 again I do not get a page to log into nifi anymore.
All that appears are some symbols and I cannot log into nifi like the first time. Basically I want to be able to log into apache nifi. I'm not sure why the symbols appear instead of the log in page.
Here's what I do:
I start apache nifi-1.16.3 from its installation with its start command:
bin/nifi.sh start
bin/nifi.sh status
Nifi looks to start correctly and the status command shows that nifi is running
I then enter localhost:8443/nifi/login in firefox web browser and I am presented a page that only contains symbols.
What i've tried:
I've downloaded nifi again and started another instance using the fresh download. This does the same i.e. it will show the login page correctly the first time I use it. Then when I try to access the login page after a time via the localhost it will show the symbols instead of the log in page.
I've checked to see whether the port 8443 is being used by something else but it seems free. When nifi is running I check the port, then I shut it down. Once it is shut down no other service etc. is using port 8443. When trying to access localhost:8443 instead of the symbols it shows "Unable to connect" when nifi is shutdown down.
Not sure what else to explore to solve this issue where I can't access the log in GUI through the localhost.
Just add a secure HTTP protocol like this: Local Host
I am new to JMeter. I have created one script for our application. Now our complete system architecture is deployed on AWS. So, we have created one EC2 instance as "Load Generator" to run my script with 100 user load. Script is working fine on my local system but it is not working on that instance.
Every time I am getting below error. I have also tried to run from non-GUI mode as well but result is same.
Error: Response code: Non HTTP response code: java.net.ConnectException Response message: Non HTTP response message:
Connection timed out (Connection timed out)
Please help me out here. How to resolve this issue on EC2 instance.
I had a similar problem (my tests were executed on Microsoft's Azure).
The issue was that the system being tested had a IP white list.
When I ran it on my local machine, it was already within our VPN
(whitelisted).
When it was executed on Azure, the VM had a
dynamic IP which was not whitelisted.
I'm developing a Web App, I need to get the logs of mesos , Normally, I can get that with
Url: http://host:5051/files/read.json?
but when the Master or Slave restart , I could not get the logs..
Please tell me how could I get that ?
All logs are stored in the log directory you specify via a --log_dir flag. I'm not sure you can access logs from previous runs via WebUI, but you can definitely ssh into the specific machine.
This is our first steps using big data stuff like apache spark and hadoop.
We have a installed Cloudera CDH 5.3. From the cloudera manager we choose to install spark. Spark is up and running very well in one of the nodes in the cluster.
From my machine I made a little application that connects to read a text file stored on hadoop HDFS.
I am trying to run the application from Eclipse and it displays these messages
15/02/11 14:44:01 INFO client.AppClient$ClientActor: Connecting to master spark://10.62.82.21:7077...
15/02/11 14:44:02 WARN client.AppClient$ClientActor: Could not connect to akka.tcp://sparkMaster#10.62.82.21:7077: akka.remote.InvalidAssociation: Invalid address: akka.tcp://sparkMaster#10.62.82.21:7077
15/02/11 14:44:02 WARN Remoting: Tried to associate with unreachable remote address [akka.tcp://sparkMaster#10.62.82.21:7077]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: Connection refused: no further information: /10.62.82.21:7077
The application is has one class the create a context using the following line
JavaSparkContext sc = new JavaSparkContext(new SparkConf().setAppName("Spark Count").setMaster("spark://10.62.82.21:7077"));
where this IP is the IP of the machine spark working on.
Then I try to read a file from HDFS using the following line
sc.textFile("hdfs://10.62.82.21/tmp/words.txt")
When I run the application I got the
Check your Spark master logs, you should see something like:
15/02/11 13:37:14 INFO Remoting: Remoting started; listening on addresses :[akka.tcp://sparkMaster#mymaster:7077]
15/02/11 13:37:14 INFO Remoting: Remoting now listens on addresses: [akka.tcp://sparkMaster#mymaster:7077]
15/02/11 13:37:14 INFO Master: Starting Spark master at spark://mymaster:7077
Then when your connecting to the master, be sure to use exactly the same hostname as found in the logs above (do not use the IP address):
.setMaster("spark://mymaster:7077"));
Spark standalone is a bit picky with this hostname/IP stuff.
When you create your Spark master using the shell command "sbin/start-master.sh". go the the address http://localhost:8080 and check the "URL" row.
I notice no accepted answer, just for info I thought I'd mention a couple things.
First, in the spark-env.sh file in the conf directory, the SPARK_MASTER_IP and SPARK_LOCAL_IP settings can be hostnames. You don't want them to be, but they can be.
As noted in another answer, Spark can be a little picky about hostname vs. IP address, because of this resolved bug/feature: See bug here. The problem is, it's not clear if they "resolved" is simply by telling us to use IP instead of hostname?
Well I am having this same problem right now, and the first thing you do is check the basics.
Can you ping the box where the Spark master is running? Can you ping the worker from the master? More importantly, can you password-less ssh to the worker from the master box? Per 1.5.2 docs you need to be able to do that with a private key AND have the worker entered in the conf/slaves file. I copied the relevant paragraph at the end.
You can get a situation where the worker can contact the master but the master can't get back to the worker so it looks like no connection is being made. Check both directions.
Finally of all the combinations of settings, in a limited experiment just now I only found one that mattered: On the master, in spark-env.sh, set the SPARK_MASTER_IP to the IP address, not hostname. Then connect from the worker with spark://192.168.0.10:7077 and voila it connects! Seemingly none of the other config parameters are needed here.
Here's the paragraph from the docs about ssh and slaves file in conf:
To launch a Spark standalone cluster with the launch scripts, you
should create a file called conf/slaves in your Spark directory, which
must contain the hostnames of all the machines where you intend to
start Spark workers, one per line. If conf/slaves does not exist, the
launch scripts defaults to a single machine (localhost), which is
useful for testing. Note, the master machine accesses each of the
worker machines via ssh. By default, ssh is run in parallel and
requires password-less (using a private key) access to be setup. If
you do not have a password-less setup, you can set the environment
variable SPARK_SSH_FOREGROUND and serially provide a password for each
worker.
Once you have done that, using the IP address should work in your code. Let us know! This can be an annoying problem, and learning that most of the config params don't matter was nice.
I have a Windows Azure VM running VS2013 Load Test Controller and a second Azure VM running 2013 Load Test Agent.
I have not been able to get the two communicating successfully. I added the hostname and IP of each VM to the other's HOSTS file. I also created a local admin account with the same username and password on both machines. Neither machine is joined to a domain. I have also created endpoints for each VM to port 6901/TCP. I am able to telnet from the agent VM to port 6901 on the controller VM.
When I apply the test agent configuration settings, it fails on "Test agent could not connect to the test controller." In the agent configuration log, I see:
Could not get the status from the test agent. Exception: Failed to
connect to an IPC Port: The system cannot find the file specified.
In the event viewer, I see:
Unable to connect to the controller on 'controllerVM:6901'. The agent
can connect to the controller but the controller cannot connect to the
agent because of following reason: A connection attempt failed because
the connected party did not properly respond after a period of time,
or established connection failed because connected host has failed to
respond 168.62.XX.XX:6910. Make sure that the firewall on the test
agent machine is not blocking the connection.
I have been completely unable to work around this issue so far. I need help please.
Can you Check your c:\windows\system32\drivers\etc\hosts file both agent and controler .
If there is an entry assigned to 127.0.0.1 remove that.
When you install the Agent/Controller, be sure to use the same user (Admin) Account (Run as...). This account have to be in the group TeamTestAgentService on the controller.
In addition, after setup, the wizard will try to connect agent to the test controller. What's the status ?
MSDN explains here how to install/configure the test rig in a workgroup.
There is also a complete troubleshoot guide here.