I'm using IoTA-UL in Fiware.
I need to know what messages sent to IoTA-UL were well received and what don't (i.e. because of API KEY were invalid or ultralight message were malformed because the sender included some attribute that doesn't exist).
Right know I'm using DEBUG log level, but the log it's eating my disk. Is there any way to log what I want? FATAL, ERROR, INFO and WARN log levels don't do it.
In the IoT Agent UL documentation, you can find a list with all log entries/messages that can appear in the IoTA logs.
I hope it can help you.
Related
Here is an image of a common structure we have in a few of our BizTalk orchestrations:
So when we GET information from an API and the account doesn't exist, we terminate the orchestration. This works fine and I can see the orchestration doing this and terminating when it should, but what I don't understand is why do I see the suspended message from the GET in the console? Since the exception handling works, shouldn't this stop an error showing in the console?
As a way around this, I've considered using a pipeline component to check the response message, and if it contains what would be ignored, just return null in place of the message. Would this have the desired effect? I'm more interested as to why I see the suspended messages in the console.
Yes, this is a known issue with the WCF-WebHttp adapter, that has to do with the fact that it throws it back as a SOAP formatted error, but without setting the MessageType context property (see my blog post and look for Bug: BizTalk WCF-WebHttp adapter does not set the message type on error). So although the exception is thrown back at the Orchestration and can be handled there, the message is not as BizTalk does not know what type it is and it suspends.
A workaround we use is
To set Enable Routing for failed messages on the send port
To have a send port that subscribes to all the response messages from that send port using the BTS.SPName = xxxx filter, and send port sends it to a custom NULL adapter (throw the message away), and yes, your Orchestration will still get the good response as well as the exceptions.
Update the send port that handles routing errors from other send ports that we do want to go to our exception handing to exclude those send ports which we are handling via an Orchestration.
I recently suspect I have configuration problem with the SOUTHBOUND traffic. Device already provisioned with IOTA. How do I check if the agent is receiving measurements?
First, try looking in the agent's log file, to discard errors. If you do not find anything, try changing the severity of the log file to a more comprehensive value like DEBUG.
I have never used this FIWARE IoT Agent, but with others like IoT Agent for the Ultralight if you configure the severity of the log file in DEBUG the reception of each message is shown.
If you need help to change the log file severity, start reading the agent configuration page here.
On the other hand, if you have your agent attached to an Orion context broker, you should be able to validate that you are receiving data, observing how your contexts change as you receive data. For this you have the Orion API.
EDIT:
All FIWARE agents shares a core library called node-lib and that component define interfaces to manage device provisioning and similar operations.
There are HTTP methods to create, fetch and delete devices and in particularly for updating a device. Check apiary blueprint here for more information.
As an example:
Getting all devices
curl -X GET [your_agent_host]:[port]/iot/devices
Update a device
curl -X POST [your_agent_host]:[port]/iot/devices/{device_id} -d
'{"attributes": [{
"object_id": "attr_id",
"name": "attr_name",
"type": "attr_type"} ...
]}'
I think there is no way to perform a partial update on a single device, you must specify all the attributes again.
Greetings and I hope I have been of some help!
The Flag Ocp-Apim-Tracehas been set to true.
The API Response displays this information under the Trace Tab:
Trace location was not specified in the response or trace log is not
available.
Yet no traces are available. How does one resolve this?
To enable trace, you need to include "Ocp-Apim-Trace" and "Ocp-Apim-Subscription-Key" in request header.
If the API does not require subscription, you can still get admin subscription key in developer portal. This enforces that only admin can get tracing log. To get admin subscription key if you are an admin, go to Developer Portal -> Profile -> find your target API and copy the key.
The Ocp-Apim-Trace feature enables you to specify whether or not APIM should generate a trace file on blob storage.
Setting the header to 'true' within Postman for example, will give you back a HTTP Header in the response called Ocp-Apim-Trace-Location.
This will contain the URL to your trace file, which you can open in any browser.
You might want to install a plugin/extension to be able to format JSON files properly in order to make it easy to read.
Just setting the flag Ocp-Apim-Trace to true will not suffice.
One needs to set the subscription key as well as per this doc.
https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies#Trace
So, for API's which do not have a subscription key, not sure how one can get the traces
I've implemented logging of all requests/responses using (in my AppHost.cs):
this.RequestFilters.Add(serviceLogFilter.LogRequest);
this.ResponseFilters.Add(serviceLogFilter.LogResponse);
During the logging of the request, I get the new ID from the logging table and put it into IHttpRequest.Items.
My question is: when an error occurs, like if the validation of the incoming data fails, or my business logic throws an Exception, is there a way I can customize the returned error to contain my log reference? Preferably by adding a JSON body to the error response. Alternatively, setting a custom HTTP header?
The idea is that my customer could give me a log reference if something unexcpected happens, and I would find his request and could easily reproduce the problem.
See this question on different ways to Handle exceptions from the old and New API.
To use the IHttpRequest.Items dictionary to pass data between request filters, services and response filters in the same request.
Also the InMemoryRollingRequestLogger implementation for the Request Logger plugin shows another way to be able to log all requests.
With the default behaviour when a message is not routed the message is lost.
You could create a queue that receives all messages by using the # for the routing key in the binding. Then create a process that handles all the non routed messages. The process will have to connect to the queue and receive all messages and somehow know whether they have been routed or not. What you will need to do is call the management plugin cli to return all the bindings for an exchange. Parse that result to get you this list of the bindings for the exchange and ignore any incoming message which matches the bindings. Then you can just process the ones that never got routed in the first place. You could even read them back to another queue for a worker process to consume.
have a look at this for information on the management plugin cli.
If you prefer to use the rabbitmqctl you could use
sudo rabbitmqclt report
to get a report that would need to be parsed to get all the bindings. See here