There is a problem with Graphite Docker images I try to run on my PC. Containers start up gracefully but I'm not able to send any message so that it would be displayed under "Metrics" tab. Volumes Mounting doesn't help either. Default storage-schema.conf should accept all messages.
The message used for testing is such:
echo "test.bash.stats 42 date +%s" | nc localhost 2003.
Moreover, most of the time (but not always) after sending above listed message "400 Bad request" error is responded.
Following images has been tested:
https://hub.docker.com/r/hopsoft/graphite-statsd/
https://hub.docker.com/r/kamon/grafana_graphite/
Any ideas, I'm missing something to configure additionally?
Despite the above explained issue there is is question related to Spring Boot Metrics export to Graphite over StatsD.
As described here http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-metrics.html in section 49.8.3 Example: Export to Statsd there is a requirement only to add com.timgroup:java-statsd-client as dependency and add property spring.metrics.export.statsd.host.
Unfortunately nothing is send to Graphite (docker image running on local PC https://github.com/kamon-io/docker-grafana-graphite). I have checked network with Wireshark (udp.port=8125). Is there maybe something missing to add into Spring boot project with metrics?
Related
Maybe anyone faced a similar problem. We have a kubeapi proxy which impersonates users using sso.
Kubectl tool works just fine with any commands unless you do tail -f
I do see that app data is coming back every 1-5 seconds, but to output it takes ~ 45 seconds.
We use http/server from standard go packages and our proxy is based of https://github.com/ericchiang/kube-oidc/issues
TCP Dump attached. Thanks
INFO [main] org.apache.nifi.bootstrap.Command Apache NiFi is currently running, listening to Bootstrap on port 20740, PID=31405
That means NiFi is running, and I can see its log in logs/nifi-app.log.
The UI is available at https://servername:9443/nifi. It successfully initiated communication with Bootstrap.
But i have this error, and the UI fails to appear. Do you have any solutions?
Failed to invoke #OnEnabled method of JettyWebSocketServer[id=01591009-1d2b-177f-e304-a7cc87d735ce] due to java.net.BindException: Address already in use
"java.net.BindException: Address already in use" means a port is already in use by something else on your system.
In this case it shows that it is coming from the JettyWebSocketServer controller service which is trying to bind to port 9998.
You can use "netstat -lntp" to see what is using port 9998. It could also be possible that you have more than one instance of the controller service with both of them configured with port 9998 and one of them is binging to it and the other fails.
Seems like a Controller Service that fails... Try browsing your flow.xml.gz and check for any ControllerServices named JettyWebSocketServer. Change their <state></state> from <state>ENABLED</state> to <state>DISABLED</state> and try running NiFi again.
You can tell it is a controller service by the #enabledannotation which invokes a method that needs to run when the controller service is enabled.
NiFi shouldn't fail to start because of a failing controller service but it seems to be the problem(probably a bug).
After it start back up, you can configure the controller service to run on a different port.
I also suggest, that if it is the case, that you open an issue to Apache about this since it seems like a pretty major bug.
I am running a RabbitMQ instance that provides MQTT over websockets via the rabbitmq_web_mqtt plugin.
For legacy reasons, I need to support a non-default WebSocket URL.
I saw in the documentation it is possible to change the port via the { port, 1234 } config, but I could not find any way to change the WebSocket URL. It is currently set to the default path of /ws
Is it possible to change the WebSocket URL without modifying the plugin?
This has been made configurable back September 2018. See already mentioned ticket.
Add line:
# echo 'web_mqtt.ws_path = /mqtt' >> /etc/rabbitmq/rabbitmq.conf
# service rabbitmq-server restart
Now being accessible by (compliant) MQTT Clients. For instance at:
ws://192.168.210.84:15675/mqtt
UPDATE: RabbitMQ now allows configuration of the WebSocket URL. See this answer.
After some research, I found out that the path is not configurable
Kibana is not loading and giving below error .. restarted the elasticsearch/Logstash service ..but issue still exist ..Memory/Sapce available on the node
Error: Request Timeout after 30000ms
at https://X.X.X.X:5601/bundles/kibana.bundlenter image description heree.js?v=10000:78465:16
What is the kibana version you are using?
Because v5.1.1 seems to have solved the issue.
You could probably remove JS client timeout, rely on backend for timeout.
As per Kibana git commit, the client timeout need not be relied upon. It could rely on backend for timeout.
So, all you need to try is:
Go to : src/kibana/services/es.js
Set requestTimeOut to 0, as shown in the git commit.
As described in the header I want to use remote services in an OSGI environment. So I decided to handle this with eclipse ECF. In my opinion a very good project to deal with OSGI remote services. So for the discovery provider I use Zoodiscovery. The services are registered with generic service property. Furthermore, Zoodiscovery is used in centralized mode and the central IP is published with a network broadcast. I got everything to work. But after a period of time the service consumer loses the remote service.
This message is shown when the remote service is discovered:
[log;+0000 2016.04.22 15:26:03:564;DEBUG;org.eclipse.ecf.provider.zookeeper;Service Discovered: ServiceInfo[uri=ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=;id=ServiceID[type=ServiceTypeID[typeName=_ecfosgirsvc._default.default._iana];location=ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=;full=_ecfosgirsvc._default.default._iana#ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=];priority=0;weight=0;props=ServiceProperties[{objectClass=de.custom.service.api.IManagerService, endpoint.id=e9dc7ac1-708d-43a6-b2fa-539beff6c732, remote.intents.supported=passByValue exactlyOnce ordered, ecf.endpoint.id=ecftcp://192.168.178.21:2121/server, ecf.rsvc.id=3, endpoint.service.id=174, service.imported.configs=ecf.generic.server, ecf.endpoint.ts=1461329304080, ecf.generic.server.hostname=192.168.178.21, ecf.endpoint.id.ns=org.eclipse.ecf.core.identity.StringID, remote.configs.supported=ecf.generic.server, endpoint.package.version.de.custom.api=1.0.0, endpoint.framework.uuid=70eaf65a-8608-0016-13af-dcea8562a726}]]]
This message is shown when the remote service is undiscovered:
[log;+0000 2016.04.22 15:28:53:125;DEBUG;org.eclipse.ecf.provider.zookeeper;Service Undiscovered: ServiceInfo[uri=ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=;id=ServiceID[type=ServiceTypeID[typeName=_ecfosgirsvc._default.default._iana];location=ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=;full=_ecfosgirsvc._default.default._iana#ecfosgirsvc://192.168.178.21:32565/osgirsvc_AMIsPeVObufIp5v5cV6pHNIvzGM=];priority=0;weight=0;props=ServiceProperties[{objectClass=de.custom.service.api.IManagerService, endpoint.id=e9dc7ac1-708d-43a6-b2fa-539beff6c732, remote.intents.supported=passByValue exactlyOnce ordered, ecf.endpoint.id=ecftcp://192.168.178.21:2121/server, ecf.rsvc.id=3, endpoint.service.id=174, service.imported.configs=ecf.generic.server, ecf.endpoint.ts=1461329304080, ecf.generic.server.hostname=192.168.178.21, ecf.endpoint.id.ns=org.eclipse.ecf.core.identity.StringID, remote.configs.supported=ecf.generic.server, endpoint.package.version.de.custom.api=1.0.0, endpoint.framework.uuid=70eaf65a-8608-0016-13af-dcea8562a726}]]]
BUT: On host system everything is fine and the service is online. If I restart the OSGI framework on consumer side everything works fine again until this Undiscovery event. The period of time between discovery and undiscovery is equal of length.
It seems as if there is a timeout undiscovering the service. If I use the service by calling a method there is no different behaviour.
Has anyone an idea what’s going on?
Thank you for help and best regards!
UPDATE:
Ok one update:
When the remote service is discovered I fetched it in a local parameter on client side. When the remote service is unpublished on client side (NOT on server side, as described in my previous post) I can call methods from the fetched instance. So the proxy is still available and it is working fine until I unpublish the remote service on server side. So the proxy is unpublished only in OSGI service registry.
Best regards!