Over the past few days, we started to get intermittent errors within Azure Stream Analytics:
Could not resolve Event Hub host name.
The ONLY input to SA is the IoT Hub. The message is related to the the input stream. We have not altered the IoT Hub, Streaming Analytics processing, or the Message Payload - and we haven't had this error before.
Is anyone have any ideas what is causing the issue?
Todd
Yes, we are aware of the intermittent confusing diagnostics, and we have fix in. However, it's just a warning and you can safely ignore. Your job running should not be affected. You will continue notice it until we roll out deployment.
Thanks for your patience
Ming.
Related
I have setup IoT Edge up in one of our machines and installed OPC Publisher and connected it to one of our opc-ua servers which then sends data to OPC Publisher and then to IoT Hub. We have not received any data to our IoT hub for the last 10 days and suddenly today we have received the data. How can we troubleshoot why the data is missing for the last 10 days?
You can generate a support bundle on your edge device that will collect the logs of all deployed modules as well as the edge runtime logs.
sudo iotedge support-bundle --since 11d
More details on troubleshooting IoT Edge here
You can first look into the logs of the publisher and validate if the connection to the OPC UA Server was/is active. If this is fine then have a look into the edgeHub and validate if the upstream connectivity to IoT Hub was affected.
One of the most powerful tools to monitor your edge deployments is the integration with Azure Monitor. It will collect metrics from the edgeHub and edgeAgent, which combined will give you an overview of where your messages are going. It can show you how many messages are sent to your upstream endpoint and when.
Source of image
For a full overview of the capabilities, you can check out this blog post. Installation steps are here
Edit:
OPC Publisher aLso supports diagnostic logging, which will give you more information about the connections to OPC servers. To do this, you need to set the diagnostic interval. You can do this by specifying the --di command argument in your createOptions:
"OPCPublisher":{
"settings":{
"image":"<image>",
"createOptions":{
"Cmd":["di=60"]
}
},
"type":"docker",
"version":"1.0",
"status":"running",
"restartPolicy":"always"
}
The example above will log diagnostic metrics every 60 seconds. You can then upload the logs using the support bundle command from Cristian's answer, or use the UploadSupportBundle direct method to do the same without needing access to the device.
I have sent messages to Azure IoT Hub device called dev1, I could not see the messages in IoT Hub but, I can read the messages only when the client application is online when the sender is sending messages. Azure IoT Hub supports only online messaging and no offline messaging? If offline message support is there, where are these messages are stored, I couldn't see the messages in IoT Hub.
When I configure the custom endpoint as Blob storage, I can see messages are stored in blobs.
Please help me on this.
Thanks in advance
If I understand correctly you are looking for reading the messages directly on IoT Hub portal UI. If that is the case, then one of the things which you can make sure about D2C Messages in IoT Hub portal (UI perspective) is looking at the Metrics chart (See below Images). For reading the actual payload you have to make use of in-built Event Hub endpoint or routing to other supported endpoints.(You have already mentioned in your scenario-Client/Sender applications, So I think you have already known this method of reading messages)
The Metrics chart atleast tells you that the messages are received in IoT Hub (UI), you can't read them on the Portal(UI).
IoT Hub is built on top of Event Hubs, and that's where your messages will be until you start reading them. They will be stored there for 1 day by default, although you can change that up to 7 days. For more information on retention, please read this page.
I am setting up splunk to monitor continuum and its logs, which log files of continuum would be important to monitor?
Logs in VersionOne Continuum can be thought of in two categories - service logs and automation logs.
Service logs will give you insights into warnings and errors with the UI, API and other core processes. Specifically watch for CRITICAL and ERROR in the messages.
Automation logs are more targeted to the teams use of the value stream orchestration. Still, it would be useful to monitor the logs in /pi and /te for CRITICAL and ERROR, as well as the keyword failure in /pi and the keyword Error in /te, as these indicate automation routines that have completed successfully but where their goals have failed.
From time to time, all systems experience problems sending email messages. Monitoring the ctm-core log will reveal to you when the system is unable to send a notification after the max retries.
When using DeviceClient I can send messages using SendEvent and files using SendBlob. But I did not find a way to receive acknowledgement that messages/files have been received by Azure IoT Hub?
The only way I found to solve this is using serviceClient.GetFileNotificationReceiver().
Am I missing something or is this the only way?
Also it seems I need SharedAccessKeyName to use ServiceClient. But this is not present in e.g. tokens created by DeviceExplorer (which I use for DeviceClient). Any advice is appreciated.
For Java and C sdks there are IotHubEventCallback and IOTHUB_CLIENT_EVENT_CONFIRMATION_CALLBACK but for C# there is no such interface implemented.
So, for C#, a message will be sent successfully if DeviceClient.SendEventAsync() without throwing any exception, otherwise it fails.
Or you can utilize Event Hub-compatible endpoint to monitor the status of operations on your IoT hub, D2C message, file upload...
For ServiceClient, you need Azure IoT Hub connection string, not device connection string. You can find it in Configuration of Device Explorer:
We have an issue with a windows service which uses nServiceBus. At some random moment, the nServiceBus stops processing messages and direct them directly to Error queue, and I have to restart the service. After the restart, the messages arrived in the input message queue are handled, and everything gets back to normal. If we re-drop the messages which were went to error queue, it is processing it successfully without any issue.
We are using log4net logs to audit the message flow and storing in DB. The NServiceBus Handler stops to log in log4net. After we restart the windows service (NServiceBus) then it start to log again. We are NOT able to redproduce this issue in development environment. We are suspecting this could be a NService Bus Memory Leak issue. But we don't know how to confirm this issue and resolve the same.
We are planning to move this Windows Service (NServiceBus) to different server as a trial and error basis. Did anyone face this issue ever and resolved it? Please help us to resolve this issue as it is causing more troubles in Production environment.
NServiceBus Version that we are using : 2.0.0.1329
Message queue and windows service are in the same machine.
I believe you're running on a version of NServiceBus that is about 5 years old and is no longer supported. While I could give you the standard recommendation of upgrading to a more current release, it could very well be that some of the configuration APIs that you're using have been made obsolete so you may need to make some modifications there and/or in the app.configs.
I'm sorry to say that there probably isn't a better solution for you at this time.
In general, I'd suggest trying to track the NServiceBus releases somewhat more closely. If you're within 6-12 months of the current release, you should generally be in good shape.