I have follow logs in kibana
{
"_index": "crashlytics-prod-b2c-20220628",
"_type": "log",
"_id": "qPlIqoEB1i589BiuiYcG",
"_version": 1,
"_score": null,
"fields": {
"entity_id.keyword": [
""
],
"app_version.keyword": [
""
],
"device.keyword": [
"mobile"
],
"level": [
1
],
"entity_type.keyword": [
"null"
],
"message": [
"{request: {data: {content-type: application/json, AppVersion: 2.1.0, content-length: 42}, url: https://api.test.com/api/v1/auth/refresh}, error: Http status error [400], data: {timestamp: 2022-06-28T12:28:09.167Z, status: 400, errorData: [{field: push, message: Invalid refresh token, code: }]}, payload: {Settings: {deviceId: 13913338519391707838, magentoUserId: null}, ..."],
A message contains info about app version (AppVersion: 2.1.0) in this case.
Is there way to vizualizate data based on AppVersion info,
in simle way it could be looks like
AppVersion: 2.1.0 - 90 logs row
AppVersion: 2.0.0 - 20 logs row
AppVersion: 1.9.0 - 10 logs row
Related
I am trying to populating an empty field by using patch method in Contentful. The following piece of code works in one cloned environment but does not work in another.
let patchData: OpPatch[] = [
{
op: 'replace',
path: '/fields/keywords',
value: entryKeyword,
},
];
await cmaClient.entry.patch({ entryId: entryId }, patchData, { 'X-Contentful-Version': entryVersion });
When I try to execute this, receiving a 'Unprocessable Entity' error:
UnprocessableEntity: {
"status": 422,
"statusText": "Unprocessable Entity",
"message": "Could not apply patch to entry: invalid patch",
"details": {},
"request": {
"url": "/spaces/xyz/environments/abc/entries/123456789",
"headers": {
"Accept": "application/json, text/plain, */*",
"Content-Type": "application/json-patch+json",
"X-Contentful-User-Agent": "sdk contentful-management-plain.js/7.54.2;",
"Authorization": "Bearer ...",
"user-agent": "node.js/v14.19.2",
"Accept-Encoding": "gzip",
"X-Contentful-Version": 25,
"Content-Length": 78
},
"method": "patch",
"payloadData": "[{\"op\":\"replace\",\"path\":\"/fields/keywords\",\"value\":\"test keyword\"}]"
},
"requestId": "abcd-123456"
}
I have the same exact access permissions to both environments. What am I missing out on?
I had the same issue - turned out when the entry doesn't have the filed you're trying to patch - it will throw an error like above.
I have integrated my k8s deployment with google endpoints. I have 12 services out of which 11 services are working fine with google endpoints except for one service. When its transferring requests to application container its ignoring the header values with underscore.
Implementation
I have added this in my application deployment (Ignore syntax i have it in correct format in deployment)
- args:
- --http_port
- "8081"
- --backend
- 127.0.0.1:8080
- --service
- <MY_ENDPOINT>
- --service_account_key
- /etc/nginx/creds/<MY_CREDS>
- --rollout_strategy=managed
image: gcr.io/endpoints-release/endpoints-runtime:1
imagePullPolicy: Always
name: esp
ports:
- containerPort: 8081
protocol: TCP
resources: {}
volumeMounts:
- mountPath: /etc/nginx/creds
name: service-account-creds
readOnly: true
Here in the below sample, i have sent two headers with TEST-CODE and TEST_CODE. Both are getting received at the application end when i am sending request via application port, but when i access it via esp port, i receive only header with -(hyphen) not with _(underscore). TEST-CODE is being received in the server but not TEST_CODE, when accessing via esp.
When i am sending request to my application using curl or postman via 8080 which is application port
curl -XPOST http://localhost:8080/<CONTEXT_PATH> -H "Content-Type: application/json" -H "USER-ID: abc" -H "TEST-CODE: xyz" -H "TEST_CODE: wxyz"
I get response like this
{
"timestamp": "2020-04-05T19:42:44.958564Z",
"principal": null,
"session": null,
"request": {
"method": "POST",
"uri": "http://localhost:8080/<MY_URL>",
"headers": {
"host": [
"localhost:8080"
],
"test-code": [
"xyz"
],
"content-type": [
"application/json"
],
"x-user-id": [
"abc"
],
"test_code": [
"wxyz"
],
"user-agent": [
"curl/7.52.1"
],
"accept": [
"*/*"
]
},
"remoteAddress": null
},
"response": {
"status": 200,
"headers": {
"Content-Length": [
"435"
],
"Date": [
"Sun, 05 Apr 2020 19:42:45 GMT"
],
"Content-Type": [
"application/json;charset=UTF-8"
]
}
},
"timeTaken": 633
}
When i am sending request to my application using curl or postman via 8081 which is via esp
curl -XPOST http://localhost:8081/<CONTEXT_PATH>?key=<MY_KEY> -H "Content-Type: application/json" -H "USER-ID: abc" -H "TEST-CODE: xyz" -H "TEST_CODE: wxyz"
I get response like this
{
"timestamp": "2020-04-05T19:42:57.102184Z",
"principal": null,
"session": null,
"request": {
"method": "POST",
"uri": "http://localhost/<MY_URL>?<MY_KEY>",
"headers": {
"x-real-ip": [
"127.0.0.1"
],
"x-google-real-ip": [
"127.0.0.1"
],
"x-cloud-trace-context": [
"<MY_GOOGLE_TRACE_CONTEXT>"
],
"host": [
"localhost"
],
"test-code": [
"xyz"
],
"x-endpoint-api-project-id": [
"<MY_ENDPOINT_PROJECT_ID>"
],
"content-type": [
"application/json"
],
"x-forwarded-for": [
"127.0.0.1"
],
"x-user-id": [
"abc"
],
"user-agent": [
"curl/7.52.1"
],
"accept": [
"*/*"
]
},
"remoteAddress": null
},
"response": {
"status": 400,
"headers": {
"Connection": [
"close"
],
"Content-Length": [
"256"
],
"Date": [
"Sun, 05 Apr 2020 19:42:57 GMT"
],
"Content-Type": [
"application/json"
]
}
},
"timeTaken": 21
}
Again,
Notice the difference : I am sending test code header as TEST-CODE and TEST_CODE, both are coming when i am accessing via application port, but when i am accessing via esp container, the application is receiving TEST-CODE alone, not TEST_CODE.
I have tried some other HEADERS with -(hyphen) and some with _(underscore). Every time headers with -(hyphen) is being received via esp to application but not with _(underscore).
I have took the above responses from spring actuator endpoints (actuator/httptrace)
Can someone help?
I have set up open TSDB using docker image. I am able to push data to database via HTTP post request.
[{
"metric": "sys.cpu.nice",
"timestamp": 1567764102,
"value": 18,
"tags": {
"host": "web01",
"dc": "lga"
}
},
{
"metric": "sys.cpu.abc",
"timestamp": 1567764602,
"value": 9,
"tags": {
"host": "web02",
"dc": "lga"
}
}
]
Same data is also visible on the portal but I want to retrieve this data form TSDB by API.
I used this but it's not returning actual data.
http://localhost:4242/api/search/lookup?m=sys.cpu.nice{host=*}
{
"type": "LOOKUP",
"metric": "sys.cpu.nice",
"tags": [{
"key": "host",
"value": "*"
}],
"limit": 25,
"time": 6.0,
"results": [],
"startIndex": 0,
"totalResults": 0
}
Could you please help to get data back from the database. I need to send this data to some other system.
Try using the /api/query endpoint
In your case you could try one of the following GET requests:
http://localhost:4242/api/query?m=sum:cmp.sys.db{host=server01,tenant01}&start=1h-ago
http://localhost:4242/api/query?m=zimsum:cmp.sys.db{host=server01,tenant01}&start=1h-ago
I have successfully tested the first few intents of my app with my webhook in the DialogFlow console, but testing in the Simulator gives the following error:
UnparseableJsonResponse API Version 2: Failed to parse JSON response
string with 'INVALID_ARGUMENT' error: ": Cannot find field.".
NB!!!
The first thing to notice is that it refers to "API Version 2".
No requests are reaching my webhook - so it appears that this is all within Google.
Using Chrome Developer Tools, I see the Network entry that gets this error response - some details below:
Request url from Simulator: https://assistant.clients6.google.com/v1/assistant:converse?alt=json&key=A.....
NB!!!
(Note it says 'v1')
Request Payload:
{"conversationToken":"","debugLevel":1,"inputType":"KEYBOARD","locale":"en-US","mockLocation":{"city":"Mountain View","coordinates":{"latitude":37.421980615353675,"longitude":-122.08419799804688},"formattedAddress":"Googleplex, Mountain View, CA 94043, United States","zipCode":"94043"},"query":"Talk to ","surface":"PHONE"}
Response:
{
"response": "Connect the docs isn't responding right now. Try again soon.",
"conversationToken": "GidzaW11bGF0b3JfZGV2aWNlXzM3MTQxRERFM0I0Nzk1Q0ZfMDAwMDA=",
"audioResponse": "//NExAAR... encoded audio ...",
"debugInfo": {
"assistantToAgentDebug": {
"curlCommand": "curl -v 'https://api.api.ai/api/integrations/google?token=...token...' -H 'Content-Type: application/json;charset=UTF-8' -H 'Google-Actions-API-Version: 2' -H 'Authorization: ...authorization key...' -A 'Mozilla/5.0 (compatible; Google-Cloud-Functions/2.1; +http://www.google.com/bot.html)' -X POST -d '{\"user\":{\"userId\":\"...user id...\",\"locale\":\"en-US\",\"lastSeen\":\"2017-12-15T17:22:55Z\"},\"conversation\":{\"conversationId\":\"1513778713541\",\"type\":\"NEW\"},\"inputs\":[{\"intent\":\"actions.intent.MAIN\",\"rawInputs\":[{\"inputType\":\"KEYBOARD\",\"query\":\"Talk to Connect The Docs\"}]}],\"surface\":{\"capabilities\":[{\"name\":\"actions.capability.AUDIO_OUTPUT\"},{\"name\":\"actions.capability.SCREEN_OUTPUT\"}]},\"isInSandbox\":true,\"availableSurfaces\":[{\"capabilities\":[{\"name\":\"actions.capability.AUDIO_OUTPUT\"},{\"name\":\"actions.capability.SCREEN_OUTPUT\"}]}]}'",
"assistantToAgentJson": "{\"user\":{\"userId\":\"...user id...\",\"locale\":\"en-US\",\"lastSeen\":\"2017-12-15T17:22:55Z\"},\"conversation\":{\"conversationId\":\"1513778713541\",\"type\":\"NEW\"},\"inputs\":[{\"intent\":\"actions.intent.MAIN\",\"rawInputs\":[{\"inputType\":\"KEYBOARD\",\"query\":\"Talk to Connect The Docs\"}]}],\"surface\":{\"capabilities\":[{\"name\":\"actions.capability.AUDIO_OUTPUT\"},{\"name\":\"actions.capability.SCREEN_OUTPUT\"}]},\"isInSandbox\":true,\"availableSurfaces\":[{\"capabilities\":[{\"name\":\"actions.capability.AUDIO_OUTPUT\"},{\"name\":\"actions.capability.SCREEN_OUTPUT\"}]}]}"
},
"agentToAssistantDebug": {
"agentToAssistantJson": "{\"message\":\"Unexpected apiai response format: Empty speech response\",\"apiResponse\":{\"id\":\"24ddbf1c-3930-40c6-ba50-03c0935cd1d0\",\"timestamp\":\"2017-12-20T14:05:13.766Z\",\"lang\":\"en-us\",\"result\":{},\"status\":{\"code\":200,\"errorType\":\"success\"},\"sessionId\":\"1513778713541\"}}"
},
"sharedDebugInfo": [{
"name": "ResponseValidation",
"subDebugEntry": [{
"name": "UnparseableJsonResponse",
"debugInfo": "API Version 2: Failed to parse JSON response string with 'INVALID_ARGUMENT' error: \": Cannot find field.\"."
}]
}]
},
"visualResponse": {}
}
I have been informed by Google Support that I am indeed using version V2 - I initiated this in December 2017 - long after the May 2017 "cutoff date" where V2 is supposed to be the default.
Is this a Google bug? Have I missed something setting up my intents? Or is there another setting that may be causing this?
I see that other posts in the DialogFlow forum show the same problem.
Any help is appreciated.
Added on 1/9/2018:
Contents of the Debug Tab:
{
"agentToAssistantDebug": {
"agentToAssistantJson": {
"message": "Unexpected apiai response format: Empty speech response",
"apiResponse": {
"id": "64a900d2-23e8-4833-b9de-0b207f63bffc",
"timestamp": "2018-01-08T21:08:36.821Z",
"lang": "en-us",
"result": {},
"status": {
"code": 200,
"errorType": "success"
},
"sessionId": "1515445716570"
}
}
},
"assistantToAgentDebug": {
"assistantToAgentJson": {
"user": {
"userId": "ABwppHFGoTJm5fKpau6WWwufKQE5UwkebooowZF7YhvD7PPY-hUfxU2_KRpB0LLNcLPyXasbXnRxXT6fniKk",
"locale": "en-US",
"lastSeen": "2018-01-05T15:53:11Z"
},
"conversation": {
"conversationId": "1515445716570",
"type": "NEW"
},
"inputs": [
{
"intent": "actions.intent.MAIN",
"rawInputs": [
{
"inputType": "VOICE",
"query": "talk to connect the docs"
}
]
}
],
"surface": {
"capabilities": [
{
"name": "actions.capability.AUDIO_OUTPUT"
},
{
"name": "actions.capability.SCREEN_OUTPUT"
},
{
"name": "actions.capability.WEB_BROWSER"
}
]
},
"isInSandbox": true,
"availableSurfaces": [
{
"capabilities": [
{
"name": "actions.capability.AUDIO_OUTPUT"
},
{
"name": "actions.capability.SCREEN_OUTPUT"
}
]
}
]
},
"curlCommand": "curl -v 'https://api.api.ai/api/integrations/google?token=0ffc8bcf72704850a4b4139d49a8d72e' -H 'Content-Type: application/json;charset=UTF-8' -H 'Google-Actions-API-Version: 2' -H 'Authorization: eyJhbGciOiJSUzI1NiIsImtpZCI6IjBhYTQ1NDFlNGM4ZWVhODQ0NjhmZTYxYTkzZmIxYzA2MzJkYjVhMGYifQ.eyJhdWQiOiJhY3RpdmUtZG9jdW1lbnQiLCJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJqdGkiOiIwY2U2OTdlNmE3NGFiZmVmZTdiYzhmMGU2ZGJlMzEyMDFjOWU3MzA5IiwiaWF0IjoxNTE1NDQ1NzE2LCJleHAiOjE1MTU0NDU4MzYsIm5iZiI6MTUxNTQ0NTQxNn0.hZNpVrH4o8ObGIvZ7BQV44nymekTWR_K4_jsDKCzgj74z57IDyUXNGEZs6KUFxBM_2FXiSoOxJUQZ1OhDRpkpQ6L4LELYN_JDhly7kgy-SLgKgLG6FZ4YV-8qOgr9Uxmr9SsG6NSXdiG7HvTrHLXIwA8K2siBNGGDWAIB691gAC8qsjsq4d3VnHMTeqlJ6mDoOtZ2xdLnJbK5B-OK-rLHEhX6K1-Z7rXQL3OgSwUtRVvYfHI3jqY83Xn3-uf06izkQhwVqH-W6X1REltrlxFTPW2h72D-st-QQ9euIpK3fn0x-z3ouQ17g-rGrPjKcOop9FejtKMT1tibxSkQ7qywQ' -A 'Mozilla/5.0 (compatible; Google-Cloud-Functions/2.1; +http://www.google.com/bot.html)' -X POST -d '{\"user\":{\"userId\":\"ABwppHFGoTJm5fKpau6WWwufKQE5UwkebooowZF7YhvD7PPY-hUfxU2_KRpB0LLNcLPyXasbXnRxXT6fniKk\",\"locale\":\"en-US\",\"lastSeen\":\"2018-01-05T15:53:11Z\"},\"conversation\":{\"conversationId\":\"1515445716570\",\"type\":\"NEW\"},\"inputs\":[{\"intent\":\"actions.intent.MAIN\",\"rawInputs\":[{\"inputType\":\"VOICE\",\"query\":\"talk to connect the docs\"}]}],\"surface\":{\"capabilities\":[{\"name\":\"actions.capability.AUDIO_OUTPUT\"},{\"name\":\"actions.capability.SCREEN_OUTPUT\"},{\"name\":\"actions.capability.WEB_BROWSER\"}]},\"isInSandbox\":true,\"availableSurfaces\":[{\"capabilities\":[{\"name\":\"actions.capability.AUDIO_OUTPUT\"},{\"name\":\"actions.capability.SCREEN_OUTPUT\"}]}]}'"
},
"sharedDebugInfo": [
{
"name": "ResponseValidation",
"subDebugEntry": [
{
"debugInfo": "API Version 2: Failed to parse JSON response string with 'INVALID_ARGUMENT' error: \": Cannot find field.\".",
"name": "UnparseableJsonResponse"
}
]
}
]
}
Contents of the Validation Errors Tab:
UnparseableJsonResponse
API Version 2: Failed to parse JSON response string with
'INVALID_ARGUMENT' error: ": Cannot find field.".
Screenshot of welcome intent added 1/10/2018:
The problem is a combination of two things:
There are no text replies set in the Response section.
When the Intent is triggered, it does not get sent to a webhook.
As a result, Dialogflow replies to the Assistant with no text response, which is an error.
You can correct this by making sure your welcome intent does one of the following (you don't have to do both):
Set one or more text replies. These would be sent back when the Intent is called.
Check the Use webhook box under Fulfillment. This would call your webhook when the Intent is triggered. (And then make sure that your webhook returns a valid response.)
As you speculated in your comments, you could also change the Welcome Intent to one of your other Intents that you've already tested to respond. There is nothing special about this particular Welcome Intent - it was just the one created by default for you.
Using Postman when I issue a get request to my Usergrid backend I get a response back. For example:
When I run:
https://api.usergrid.com/gss/sandbox/summaries
I get a response:
{
"action": "get",
"application": "6e9204f0-71da-11e4-9a58-bd53db9c149b",
"params": {},
"path": "/summaries",
"uri": "https://api.usergrid.com/gss/sandbox/summaries",
"entities": [
{
"uuid": "7cd5c98a-7b16-11e4-9085-b5397738dcd5",
"type": "summary",
"created": 1417629724184,
"modified": 1417629993800,
"accountId": "123123",
"accounts": [
{
"id": "123123",
"type": "Individual",
"category": "Prepaid",
"numberOfLines": 2,
"balance": {...
However when I run the request with a query:
https://api.usergrid.com/gss/sandbox/summaries?ql=select * where id=123123
I get :
"action": "get",
"application": "6e9204f0-71da-11e4-9a58-bd53db9c149b",
"params": {
"ql": [
"select * where id=123123"
]
},
"path": "/summaries",
"uri": "https://api.usergrid.com/gss/sandbox/summaries",
"entities": [],
"timestamp": 1418766878176,
"duration": 7,
"organization": "gss",
"applicationName": "sandbox",
"count": 0
I want to be able to get the complete response when I pass in an 'id' in the query as it is coming from my UI & get the response. Any ideas?
-S
Your id property is a sub-key of accounts - when dealing with objects, you can use dot notation to reference sub-keys, like account.id. Unfortunately in your case, because you're using an array ([]) of accounts in a single entity (not an {} object), those are not queryable. I did notice though that the same property exists under accountId. You could try:
https://api.usergrid.com/gss/sandbox/summaries?ql=select * where accountId=123123
If not, I'd recommend you look at using a new collection to maintain your list of accounts, and use connections to manage the relationships between the entities.