I have a problem with an Edge device that I have.
Even though no devices are sending any data, the message quota is seeing a lot of traffic even though no messages are beeing sent.
For example 14000 messages will be accumulated during 7 hrs or so.
Is there any way to debug the internal messages?
I've checked with docker logs edgeHub and docker logs edgeAgent but nothing out of the ordinary there.
If it can help someone, I had this kind of problem yesterday, sending message from my edge device with a Python test app and never find it on the cloud. I missed the async behaviour of the send_message function.
You should have something like :
# At the beginning of you code
# Create an IoT Hub client
client = IoTHubModuleClient.create_from_edge_environment()
# connect the client.
await client.connect()
# ... and in your main loop
# Send the message.
await client.send_message(message)
Your Python app should use asyncio. If you forgot await for send_message, your code will not produce errors but it just won't work.
If it works, you should see a bunch of azure sdk debug logs with a docker logs of your Python app, like :
2020-04-29 08:00:13,032 - async_clients - azure.iot.device.iothub.aio.async_clients - INFO - Sending message to Hub...
2020-04-29 08:00:13,032 - pipeline_thread - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2020-04-29 08:00:13,033 - pipeline_ops_base - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - SendD2CMessageOperation: creating worker op of type MQTTPublishOperation
2020-04-29 08:00:13,033 - pipeline_stages_base - azure.iot.device.common.pipeline.pipeline_stages_base - INFO - AutoConnectStage(MQTTPublishOperation): Connected. Sending down and adding callback to check result
2020-04-29 08:00:13,033 - pipeline_stages_mqtt - azure.iot.device.common.pipeline.pipeline_stages_mqtt - INFO - MQTTTransportStage(MQTTPublishOperation): publishing on devices/<DEVICE NAME>/modules/<MODULE_NAME>/messages/events/<PROPERTIES>
2020-04-29 08:00:13,033 - mqtt_transport - azure.iot.device.common.mqtt_transport - INFO - publishing on devices/<DEVICE NAME>/modules/<MODULE_NAME>/messages/events/<PROPERTIES>
2020-04-29 08:00:13,033 - client - paho - DEBUG - Sending PUBLISH (d0, q1, r0, m8), 'b'devices/<DEVICE NAME>/modules/<MODULE_NAME>/messages/events/<PROPERTIES>'', ... (65 bytes)
2020-04-29 08:00:13,033 - mqtt_transport - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.publish returned rc=0
2020-04-29 08:00:13,033 - mqtt_transport - azure.iot.device.common.mqtt_transport - DEBUG - Waiting for response on MID: 8
2020-04-29 08:00:13,046 - client - paho - DEBUG - Received PUBACK (Mid: 8)
2020-04-29 08:00:13,047 - mqtt_transport - azure.iot.device.common.mqtt_transport - INFO - payload published for 8
2020-04-29 08:00:13,047 - mqtt_transport - azure.iot.device.common.mqtt_transport - DEBUG - Response received for recognized MID: 8 - triggering callback
2020-04-29 08:00:13,048 - pipeline_thread - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_published in pipeline thread
2020-04-29 08:00:13,048 - pipeline_stages_mqtt - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTPublishOperation): PUBACK received. completing op.
2020-04-29 08:00:13,049 - pipeline_ops_base - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - MQTTPublishOperation: completing without error
2020-04-29 08:00:13,049 - pipeline_ops_base - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - SendD2CMessageOperation: Worker op (MQTTPublishOperation) has been completed
2020-04-29 08:00:13,050 - pipeline_ops_base - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - SendD2CMessageOperation: completing without error
2020-04-29 08:00:13,050 - pipeline_thread - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in callback thread
2020-04-29 08:00:13,051 - async_adapter - azure.iot.device.common.async_adapter - DEBUG - Callback completed with result None
2020-04-29 08:00:13,051 - async_clients - azure.iot.device.iothub.aio.async_clients - INFO - Successfully sent message to Hub
About this :
Even though no devices are sending any data, the message quota is
seeing a lot of traffic even though no messages are beeing sent
Take care of the bad interpretation of Total number of messages used. The real value you should look at is Telemetry messages sent
Related
We have a rails app(v5.2.6) running inside a unicorn.
we are bombarded with log msgs like the following:
24.33.33.243, 12.0.52.41 - - [26/Jun/2022:13:43:39 +0000] "GET /our_path HTTP/1.1" 200 - 0.0078
No idea where this log is coming from? its bombarding our log and I must find a way to filter it.
We have a custom Rails.logger, where we also filter some msg that applies to some regexs, the problem is that this msg gets to the log from another place
We have a custom module that receives messages from a Modbus Module but recently the messages started to not be delivered to the destination.
It was working fine until few days ago.
Looking at the edgeHub's log it apparently initializes correctly and then appears the following WARNINGS
<4> 2020-09-23 03:06:30.309 +00:00 [WRN] - Did not receive ack for message 8eba78ae-65f3-426f-97e6-d53681c99ab8 from device/module DEVICE_ID/MODULE_NAME
<4> 2020-09-23 03:06:30.342 +00:00 [WRN] - Error sending messages to module DEVICE_ID/MODULE_NAME
System.TimeoutException: Message completion response not received
at Microsoft.Azure.Devices.Edge.Hub.Core.Device.DeviceMessageHandler.SendMessageAsync(IMessage message, String input) in /home/vsts/work/1/s/edge-hub/src/Microsoft.Azure.Devices.Edge.Hub.Core/device/DeviceMessageHandler.cs:line 428
at Microsoft.Azure.Devices.Edge.Hub.Core.Routing.ModuleEndpoint.ModuleMessageProcessor.ProcessAsync(ICollection`1 routingMessages, IDeviceProxy dp, CancellationToken token) in /home/vsts/work/1/s/edge-hub/src/Microsoft.Azure.Devices.Edge.Hub.Core/routing/ModuleEndpoint.cs:line 166
<4> 2020-09-23 03:07:01.766 +00:00 [WRN] - Did not receive ack for message fbb1e347-d290-4527-9558-127f2d8f357d from device/module DEVICE_ID/MODULE_NAME
The Custom Module gets stuck in the first very message received from Modbus, and get it repeatedly.
However It does not impact it in receiving Command from the Cloud.
Our version of iotedge is 1.0.9.5 and the Microsoft.Azure.Devices.Client version is 1.25.0.
I am trying to assert the response for a HTTP GET
execution:
- executor: selenium
scenario: dashboard
iterations: 1
reporting:
- module: final-stats
dump-xml: results/test.xml
dump-csv: results/test2.csv
- module: junit-xml
filename: results/testfinal.xml
data-source: pass-fail
modules:
console:
disable: true
scenarios:
dashboard:
browser: Chrome
timeout: 60s
default-address: https://${URL}
requests:
- label: ignore
url: https://${URL}
actions:
- waitByXPath(/html/body/div/div[2]/div/div/div/div[4]/div[2]/form/input[4]): Visible
- keysByXPath(/html/body/div/div[2]/div/div/div/div[4]/div[2]/form/input[4]): ${USERNAME}
- keysByXPath(/html/body/div/div[2]/div/div/div/div[4]/div[2]/form/input[5]): ${PASSWORD}
- clickByXPath(/html/body/div/div[2]/div/div/div/div[4]/div[2]/form/div[4]/button)
- url: /Sites/testsite/api/level1/status/auth-service-health-check
method: GET
assert:
- contains:
- 200
subject: status-code
Error i am getting is "TypeError: first argument must be string or compiled pattern"
Please can any one help with this
All what i need to check is whether the reponse status is 200 for url: /Sites/testsite/api/level1/status/auth-service-health-check
issue is on here exactly
- contains:
- 200
subject: status-code
if i add like this error disappeared but then it checking the response body not status code
- contains:
- '200'
subject: status-code
The suggestion to check http-code instead of status-code is correct. To expand on that, check out the explanation here:
https://gettaurus.org/docs/JMeter/#HTTP-Requests
Scroll down a bit and there's a discussion of how exactly assertions work in Taurus, with some examples. Of particular note is this part:
Possible subjects are:
body
headers
http-code
Have you tried changing the subject to http-code?:
subject: http-code
To give you the background, we are running kaa server on ubuntu in combination with MongoDB and have Endpoints attached to it (max 10). Apparently I am seeing following error way too frequently on our server and this makes our Kaa client (C client) throw a segment fault error.
The work around we have found out is restarting kaa-node service on server.
We are planning to go live with product with IoT enabled features and we are worried about this.
Can someone throw light as to what might be going wrong?
I understand the problem is with zookeeper and looks like it does not find operations servers
2017-05-11 12:31:23,808 [EPS-core-dispatcher-208419] DEBUG o.k.k.s.o.s.a.a.core.TenantActor - [f8d64123-6861-446f-b937-1e1d398159c8] Processing status request
2017-05-11 12:31:23,808 [EPS-core-dispatcher-208419] TRACE o.k.k.s.o.s.a.a.c.ApplicationActor - [26309946599256320307] Received: org.kaaproject.kaa.server.operations.service.akka.messages.core.stats.StatusRequestMessage#fb460fe
2017-05-11 12:31:23,808 [EPS-core-dispatcher-208419] DEBUG o.k.k.s.o.s.a.a.c.ApplicationActor - [f8d64123-6861-446f-b937-1e1d398159c8] Processing status request
2017-05-11 12:31:23,808 [EPS-core-dispatcher-208419] TRACE o.k.k.s.o.s.a.a.core.TenantActor - [1] Received: org.kaaproject.kaa.server.operations.service.akka.messages.core.stats.ApplicationActorStatusResponse#4ab6ff6c
2017-05-11 12:31:23,808 [EPS-core-dispatcher-208419] DEBUG o.k.k.s.o.s.a.a.c.OperationsServerActor - Received: org.kaaproject.kaa.server.operations.service.akka.messages.core.stats.TenantActorStatusResponse#2fc38dcf
2017-05-11 12:31:23,813 [pool-5-thread-1] ERROR o.k.k.s.common.zk.ControlNodeTracker - Unknown Error
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /operationsServerNodes/operationsServerNodes0000000021
at org.apache.zookeeper.KeeperException.create(KeeperException.java:111) ~[zookeeper-3.4.6.jar:3.4.6-1569965]
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) ~[zookeeper-3.4.6.jar:3.4.6-1569965]
at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1270) ~[zookeeper-3.4.6.jar:3.4.6-1569965]
at org.apache.curator.framework.imps.SetDataBuilderImpl$4.call(SetDataBuilderImpl.java:274) ~[curator-framework-2.9.0.jar:na]
at org.apache.curator.framework.imps.SetDataBuilderImpl$4.call(SetDataBuilderImpl.java:270) ~[curator-framework-2.9.0.jar:na]
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:107) ~[curator-client-2.9.0.jar:na]
at org.apache.curator.framework.imps.SetDataBuilderImpl.pathInForeground(SetDataBuilderImpl.java:267) ~[curator-framework-2.9.0.jar:na]
at org.apache.curator.framework.imps.SetDataBuilderImpl.forPath(SetDataBuilderImpl.java:253) ~[curator-framework-2.9.0.jar:na]
at org.apache.curator.framework.imps.SetDataBuilderImpl.forPath(SetDataBuilderImpl.java:41) ~[curator-framework-2.9.0.jar:na]
at org.kaaproject.kaa.server.common.zk.operations.OperationsNode$1.doWithZkClient(OperationsNode.java:78) ~[zk-0.10.0.jar:na]
at org.kaaproject.kaa.server.common.zk.ControlNodeTracker.doZkClientAction(ControlNodeTracker.java:294) [zk-0.10.0.jar:na]
at org.kaaproject.kaa.server.common.zk.ControlNodeTracker.doZkClientAction(ControlNodeTracker.java:280) [zk-0.10.0.jar:na]
at org.kaaproject.kaa.server.common.zk.operations.OperationsNode.updateNodeData(OperationsNode.java:75) [zk-0.10.0.jar:na]
at org.kaaproject.kaa.server.operations.service.loadbalance.DefaultLoadBalancingService.onStatusUpdate(DefaultLoadBalancingService.java:98) [kaa-node-0.10.0.jar:na]
at org.kaaproject.kaa.server.operations.service.loadbalance.DefaultLoadBalancingService$1$1.run(DefaultLoadBalancingService.java:72) [kaa-node-0.10.0.jar:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_60]
Below is the frequency of this particular error(filename: no of occurrences of error)
kaa-node-2017-05-10.0.log:0
kaa-node-2017-05-10.1.log:0
kaa-node-2017-05-10.2.log:0
kaa-node-2017-05-10.3.log:0
kaa-node-2017-05-10.4.log:0
kaa-node-2017-05-10.5.log:0
kaa-node-2017-05-10.6.log:0
kaa-node-2017-05-10.7.log:0
kaa-node-2017-05-11.0.log:0
kaa-node-2017-05-11.1.log:0
kaa-node-2017-05-11.2.log:0
kaa-node-2017-05-11.3.log:0
kaa-node-2017-05-11.4.log:520
kaa-node-2017-05-11.5.log:0
kaa-node-2017-05-11.6.log:0
kaa-node-2017-05-11.7.log:0
kaa-node-2017-05-11.8.log:0
kaa-node-2017-05-12.0.log:0
kaa-node-2017-05-12.1.log:0
kaa-node-2017-05-12.2.log:0
kaa-node-2017-05-12.3.log:0
kaa-node-2017-05-12.4.log:0
kaa-node-2017-05-12.5.log:0
kaa-node-2017-05-12.6.log:0
kaa-node-2017-05-13.0.log:0
kaa-node-2017-05-13.1.log:0
kaa-node-2017-05-13.2.log:0
kaa-node-2017-05-13.3.log:0
kaa-node-2017-05-13.4.log:0
kaa-node-2017-05-13.5.log:0
kaa-node-2017-05-13.6.log:0
kaa-node-2017-05-13.7.log:0
kaa-node-2017-05-14.0.log:0
kaa-node-2017-05-14.1.log:0
kaa-node-2017-05-14.2.log:0
kaa-node-2017-05-14.3.log:0
kaa-node-2017-05-14.4.log:0
kaa-node-2017-05-14.5.log:0
kaa-node-2017-05-14.6.log:0
kaa-node-2017-05-14.7.log:0
kaa-node-2017-05-14.8.log:0
kaa-node-2017-05-14.9.log:0
kaa-node-2017-05-15.0.log:0
kaa-node-2017-05-15.1.log:0
kaa-node-2017-05-15.2.log:0
kaa-node-2017-05-15.3.log:0
kaa-node-2017-05-15.4.log:0
kaa-node-2017-05-15.5.log:0
kaa-node-2017-05-15.6.log:276
kaa-node-2017-05-15.7.log:875
kaa-node-2017-05-15.8.log:873
kaa-node-2017-05-15.9.log:539
kaa-node-2017-05-16.0.log:879
kaa-node-2017-05-16.1.log:878
kaa-node-2017-05-16.2.log:878
kaa-node-2017-05-16.3.log:878
kaa-node-2017-05-16.4.log:879
kaa-node-2017-05-16.5.log:880
kaa-node-2017-05-16.6.log:877
kaa-node-2017-05-16.7.log:878
kaa-node-2017-05-16.8.log:878
kaa-node-2017-05-16.9.log:735
kaa-node-2017-05-17.0.log:877
kaa-node-2017-05-17.1.log:878
kaa-node-2017-05-17.2.log:878
kaa-node-2017-05-17.3.log:878
kaa-node-2017-05-17.4.log:877
kaa-node-2017-05-17.5.log:876
kaa-node-2017-05-17.6.log:871
kaa-node-2017-05-17.7.log:868
kaa-node-2017-05-17.8.log:877
kaa-node-2017-05-17.9.log:760
kaa-node-2017-05-18.0.log:876
kaa-node-2017-05-18.1.log:876
kaa-node-2017-05-18.2.log:876
kaa-node-2017-05-18.3.log:876
kaa-node-2017-05-18.4.log:877
kaa-node-2017-05-18.5.log:880
kaa-node-2017-05-18.6.log:879
kaa-node-2017-05-18.7.log:878
kaa-node-2017-05-18.8.log:876
kaa-node-2017-05-18.9.log:746
kaa-node-2017-05-19.0.log:876
kaa-node-2017-05-19.1.log:877
kaa-node-2017-05-19.2.log:877
kaa-node-2017-05-19.3.log:879
kaa-node-2017-05-19.4.log:878
kaa-node-2017-05-19.5.log:879
kaa-node-2017-05-19.6.log:1037
kaa-node-2017-05-19.7.log:1285
kaa-node-2017-05-19.8.log:1051
kaa-node-2017-05-20.0.log:1887
kaa-node-2017-05-20.1.log:2400
kaa-node-2017-05-20.2.log:2396
kaa-node-2017-05-20.3.log:1957
kaa-node-2017-05-21.0.log:8640
kaa-node-2017-05-22.0.log:5326
kaa-node-2017-05-22.1.log:0
kaa-node-2017-05-22.2.log:0
kaa-node-2017-05-22.3.log:0
kaa-node-2017-05-22.4.log:0
kaa-node-2017-05-23.0.log:0
kaa-node-2017-05-23.1.log:0
I am using orbeon xform engine as a separate deployment with my Java Application. I followed all the steps required for separate deployment but while implementing xfroms using Orbeon I am getting following error:
"Orbeon Forms - Unauthorized
You do not have access to this page."
Inside tomcat orbeon log file it is showing following error:
392 INFO ProcessorService - Context listener - Context initialized.
522 INFO ProcessorService - Servlet initialized.
724 INFO ProcessorService - /xforms-renderer - Received request
192 INFO PageFlowControllerProcessor - unauthorized {controller: "oxf:/ops/xforms/xforms-renderer-page-flow.xml", method: "POST", path: "/xforms-renderer", status-code: "403"}
205 INFO ProcessorService - /xforms-renderer - Timing: 2465
I used RequestDispatcher in my servlet to forward my request for required XForm
ServletContext context= getServletContext();
RequestDispatcher rd= context.getRequestDispatcher("/xforms-jsp/orbeon/form.jsp");
rd.forward(request, response);
I am able to render xfrom while implementing as a integrated deployment.
May you guide where I am getting wrong.
Thanks!
If you're using separate deployment, you should be using the Orbeon servlet filter in your web.xml, and you don't need to use a RequestDispatcher in your own code. I double-checked this now with 4.0 to verify it works. (I am wondering what led you to believe that you needed to use your own RequestDispatcher, as I don't see anything about this in the separate deployment documentation.)
Note however that because of this issue, for now you also need to add the orbeon class on the <body> of your HTML, otherwise the proper styles won't apply. This is just temporary, and the class will be added automatically for you when this issue is fixed.