The log entries of my app result in jsonPayload while the gae request log entries use protoPayload. Just like in protoPayload, I added a requestId in my logging that shows up in jsonPayload. However, when using the log viewer where "Show entries from same request" action, I don't see my log entries since the filter uses protoPayload.requestId="xyz". I tried to use an or condition with jsonPayload.requestId="xyz" but that didn't help. Ideally I wouldn't even want to manually edit the clause as it will be painful to do everytime. Seems like per the following documentation, the requestId in each of these types of payloads don't map to the same underlying bigquery field.
https://cloud.google.com/logging/docs/export/bigquery
There is also a "trace" field directly on the log entry and that is same for all the related logs. However, there is no field called trace to search. Doing a text search does return all the entries. While this works, again the UX is bad as it requires first drilling down to the request log entry, copying the trace value and then doing a query.
So, are there any other options to tie the request log entry with the rest of the app log entries for that request easily?
There is a field called "trace" that is on the log entry which works. I think I was confused with the "traceId" within the protoPayload. Note that to get the "trace" field to show up with json payload, the field name should be "logging.googleapis.com/trace"
Related
I have a web form from which I want to save the data from the very first page to an index by using this sample code below.
Startup.Init<SomeModel>("http://localhost:8983/solr/somemodels");
var solr = ServiceLocator.Current.GetInstance<ISolrOperations<Quote>>();
solr.Add(new SomeModel() {Id=1001; Content="Some Content"});
solr.Commit();
On the very last page, the user is given a chance to change/update his entries on the form. Should I also use this line of code?
solr.Add(new SomeModel() {Id=1001; Content="New Content"});
Also, is this a good practice - having indexes updated in this fashion?
You can consider the below things.
Is there any chance that user does something in the first page and drops off in before reaching the last page?
If this is valid scenario and data loss is not acceptable, you should
save the data.
If you only want to save the data when use reaches at the last page, then you should do the below.
You should save the data which you want to be saved between pages. At the last page, you save it too SOLR.
Hope you are also using some backend data source to save the data and solr for search use cases. In this case, it is advisable to update one doc once per operation.
In case of Cassandra as backend. there are chances for tombstone when you update a document multiple times.
I am not able to get removed users using a delta link retrieved from a previous call of https://graph.microsoft.com/v1.0/groups/delta
Explanations:
I retrieve the groups using the query
https://graph.microsoft.com/v1.0/groups/delta
which returns the results correctly
Then I keep the delta link
(example of delta link from JSON response: "#odata.deltaLink": "https://graph.microsoft.com/v1.0/groups/delta?$deltatoken=7VBZ66f3HT ...
)
I remove manually a user which belongs to a group to be sure the delta link works and returns the removed user id.
-> nothing at all is returned.
According to their documentation, it should work:
https://learn.microsoft.com/en-us/graph/delta-query-groups#deltalink-response
Moreover, when i do the same thing with delta user query, it works fine, the removed user is returned with user delta link.
Question:
Does anyone is experiencing this issue and did you find any solution?
I didn't reproduce your issue on my side. I am using Microsoft graph explore to test the api.
When I accessed the final nextLink response, I got the deltaLink.
Then I removed two users from a group on Azure portal.
I can get the expected result when I access the deltaLink.
Update:
I just noticed that you deleted the user directly. That's why you can only get removed user on user delta. If you remove the user from the group directly, you will get the removed user.
I have created brand new AAD Group, added a couple of users to it, and removed users from it. I then tried the below request and it's returning a deltalink as expected:
https://graph.microsoft.com/beta/groups/delta/?$filter= id eq '900faee0-0115-44a9-876w-cd1644472792'&$deltaToken=latest
When trying to call the deltaLink I received using the above request, I'm getting an empty response without the expected members#delta showing recently added or deleted Users.
Note: I didn't try the delta function on the desired resource as I'm not interested in retrieving the full state of the resource but trying above $deltaToken=latest request as very first delta change query.
The reason you're not seeing membership changes is that you haven't expanded members in your query. Your current question will only return changes to the Group itself, not related entities.
To retrieve a delta for the Group & Members your query should be:
/v1.0/groups/delta/?$expand=members&$filter= id eq '900faee0-0115-44a9-876w-cd1644472792'&$deltaToken=latest
Also, note that you really shouldn't call the Graph Beta version unless your testing new Graph features. The Beta APIs can and will see breaking changes occur without warning. It is not safe for production code.
When using gmail API, history.list method we get "bare" message ids with no additional field from the fields in 'labelAdded', 'labelRemoved', 'messageAdded', 'messageRemoved'. Why is that? And is it possible that a new message has been added but when we use this method, the field messageAdded hasn't been used, so we receive it "bare" ?
According to the GMail history API, the list only contains the id and threadId fields.
It works this way because the objective of the history API is to provide you with the changes that happened in the mailbox, not its contents.
After you obtain the list from Users.history: list you need to call Users.messages: get or Users.messages: list to get the full messages.
If the messageAdded field is empty, it means that no new messages were added after the last historyId you examined. You might have skipped some. Make sure that every time you query the API you internally store the last historyId you processed so you can resume from that point in the future and not lose any changes.
We are making a gamification component for our forum, which is being developed in Django. We would like users to receive badges right away after achieving certain goals. However, we are concerned about the amount of database queries that would be made. For example, take a badge that is given if a post gets a certain amount of views. If the condition for the badge is checked every time the post is viewed, that would be a lot of queries. Is our only other option to check at certain intervals or another event, like the user viewing their profile? That would be less optimal from the user perspective, because of the delay.
There is a different approach that may suit you, using webserver logging and post-processing that log to generate stats. I have used it in Apache with some projects that required pageview hit counts. A similar configuration for other webservers would work the same.
I use django.contrib.contentypes to write down the Content Type ID and Object ID of the object accessed on this example, but you can, of course, log anything you want.
So, in your Apache virtualhost conf file, adding a LogFormat directive like this:
LogFormat "%{X-H-CID}o|%{X-H-OID}o" hitcounter
And then attaching it to a CustomLog:
CustomLog path/to/your/logfile.log hitcounter
This will enable Apache to write down to the logfile the following HTTP headers: X-H-CID and X-H-OID, which represent the ContentType ID and Object ID of the object being hit. From a view, you may add the headers to the HttpResponse:
ctxt = RequestContext(request)
rendered = render_to_string(template, ctxt)
http_res = HttpResponse(rendered)
http_res['X-H-CID'] = content_type_id
http_res['X-H-OID'] = object_id
Replace content_type_id and object_id with your real object props.
This example should write a line like:
16|4353
where 16 is the Content Type ID and 4353 the Object ID. Finally, you can schedule a django custom command to process that logfile and perform the needed actions.