I'm trying to fetch logs (using LogService API Java SDK 1.7.0) for multiple major version ids.
Example: fetch logs for app versions 1 and 2:
...
logquery.majorVersionIds(Arrays.asList("1","2"));
ls.fetch(logquery);
...
but it throws this exception:
com.google.appengine.api.log.InvalidRequestException: Exactly one major version id must be specified.
at com.google.appengine.api.log.LogServiceImpl$1.convertException(LogServiceImpl.java:108)
at com.google.appengine.api.utils.FutureWrapper.get(FutureWrapper.java:106)
at com.google.appengine.api.log.LogServiceImpl.fetch(LogServiceImpl.java:31)
at com.google.appengine.api.log.LogServiceImpl.fetch(LogServiceImpl.java:22)
Am I doing something wrong or this is not supported?
Java doc says:
public LogQuery majorVersionIds(java.util.List<java.lang.String> versionIds)
A setter that allows the user to specify the major app versions whose log data should be read.
This is a problem of the documentation. The error you are getting is telling you that only one version_id can be specified at the time. The python docs state that:
Currently, you can specify only one version_id per fetch call.
In the future you can create an issue in the external issue tracker.
ps: I filed an internal issue to fix this.
Related
This is sort of an extension of this question here. I have a policy that calls a REST API. The API returns an error message and this message needs to be localized.
One way is to of course get the API to return a localized message, but is there a way for the CustomPolicy itself to localize the error code? According to the CustomPolicy Docs, a REST API can send an error code along with the Conflict error code. Our thinking was to use this error code as a key and select a localized message (from the messageValue enum mentioned in the answer in the link).
However, we can't seem to capture/handle the error data returned by the API. The Policy seems to handle error codes by itself and we would like to know if it is possible to inject localized exception/error messages from the policy itself.
Thanks in advance!
Edit: A little more information about the setup. We have a TechnicalProfile that has a DisplayWidget and a ValidationTechnicalProfile. The DisplayWidget is used for entering & verifying the user's phone/email and the ValidationTechnicalProfile makes the final call to the RestAPI with all the user's information to register him/her. This RestAPI call output is what we want to localize.
The suggestion in the linked SO question, from what I understand, is that we integrate another DisplayClaim (that references an enum) in the DisplayWidget, and depending on the ErrorCode returned by the call, change it to display the appropriate code. However, as per my understanding, this would also require editing the API to return only 200 along with a code. This code would indicate the true nature of the result - success or a code for one of the enums to be displayed.
Our aim therefore is to check if there is a way to follow the Policy's flow (disrupt the SignUp/SignIn process) but at the same time localize the API's displayed response.
We managed to find a workaround to this, so I'm posting this here for anyone else who might be interested in this.
Our restriction for localizations was the fact that used Phrase to manage our translations and wanted the CustomPolicy specific translations all in one place. Our CD workflow was as follows:
PolicyCommit -> Build Variable Replacement through PS -> Release Variable Replacement and localized strings replacement through PS & Policy Uploads
Barring the policy from localizing the APIs response, we had the following options to achieve this:
Sending the language to the API and having the API return the appropriate error message
in the appropriate language. We were reluctant to follow this because of a multitude of reasons, but mostly because we would also have to handle different regions, etc. in the API - something the policy does by itself.
We actually had only one API that we called, and also only two error messages that were used. Hence we created an enum with the two error messages that would be localized. We then used a chain of InputClaimsTransformations that did the following:
Repeat Steps 1 through 3 for all the errors
1. CreateStringClaim (Create ClaimTypes for each of the error codes, holding the index of the error code in the enum)
2. GetMappedValueFromLocalizedCollection (Make the localized enum choose and hold the value of the required error code)
3. AddItemToStringCollection (Add the localized error from the enum to a StringCollection)
4. GenerateJson (Add the error codes StringCollection to the JSON payload to be sent to the API)
This way, the policy performed the localization for all the errors and we sent them along with the request to the API. The API, when an error occurred, picked one of the error messages from the policy and sent it back. This method was for us, because of our CD structure and Phrase integration, much easier than actually having the translations in a file hosted on the cloud to be accessed by the API.
Hope this helps someone; I can also add code in case someone needs it :)
Is there anyway that I can manage the appengine versions and instances through API calls?
What I mean by managing is to start/stop/delete versions deployed to the appengine through API calls.
Is that possible by using gcloud sdk commands from command line ?
Another question , does google provide APIs (or commands) to check the status of running instances ? check if the instance is idle or not and how long its being idle
There is a beta API for managing versions and services here:
https://cloud.google.com/appengine/docs/admin-api/
The API is still beta because it's under active development; there are still a few methods and fields which aren't implemented. Shortly after those are complete, the API will be marked "v1", though v1beta4 and v1beta5 will continue to be supported for several months in transition.
For example, the API doesn't yet include operations on instances, but I expect that List/Get/Delete will be available fairly soon. Since App Engine automatically creates instances for you, there is no create instance API.
I just noticed that the most recent documentation re-skin seems to have hidden the documentation for the REST interface, so I'll drop that link there so you that you can find the currently implemented methods. (Version.Update is also implemented for a few fields, so that documentation update should be coming out very soon.)
2020 UPDATE: You can do it using the apps.services.versions api. You can stop/start a version with the PATCH method, setting the mask to "servingStatus" and in the body set the "servingStatus" field to "STOPPED"/"SERVING".
Similarly, you can use the delete/create methods to launch and remove new versions
Reference:
https://cloud.google.com/appengine/docs/admin-api/reference/rest/v1/apps.services.versions/patch
I'm building some reporting tool. Ideally I want to avoid going through web server logs myself and use (some of) the power of Piwik.
The stuff I get from the visitor log would be a good start, this is at http://example.com/piwik/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday#/module=Live&action=getVisitorLog&idSite=1&period=day&date=yesterday
Unfortunately I can't find a getVisitorLog action in the HTTP API docs at
http://developer.piwik.org/api-reference/reporting-api#Actions (and it's also not an undocumented feature, method=Actions.getVisitorLog gives me
The method 'getVisitorLog' does not exist or is not available in the module '\Piwik\Plugins\Actions\API'.
Is there another way to get to this? Or should I write a plugin for Piwik?
Apparently it is possible through the Live plugin API:
http://developer.piwik.org/api-reference/reporting-api#Live
This works as desired:
http://example.com/piwik/index.php?module=API&method=Live.getLastVisitsDetails&format=JSON&idSite=1&period=day&date=2015-07-21&expanded=1&token_auth=XXXXX&filter_limit=100
How can we we send a query to the Log API such that it only retrieves logs from the front end and not the backends?
I don't know what runtime you're asking about, but looking at the Python source for SDK 1.8.8 you have the following arguments for the google.appengine.api.logservice.fetch function:
module_versions: A list of tuples of the form (module, version), that
indicate that the logs for the given module/version combination should be
fetched. Duplicate tuples will be ignored. This kwarg may not be used
in conjunction with the 'version_ids' kwarg.
(This isn't yet reflected in the Google Developers site)
This does not mean you can directly access front-end logs, but if you convert your app from using backends to using two named modules, one for front-end requests and another for backend work, you'll be able to fetch the logs of each independently.
I'm trying to download data from my Google App Engine app, using the official instructions
Remote API is set up & I call:
appcfg.py download_data --application=appname --url=http://app.address.com/_ah/remote_api --filename=alldata.csv
The connection is established, I'm being asked for my e-mail & password, and then a long trace appears ending up with this:
google.appengine.api.datastore_errors.BadRequestError: app s~appname cannot access app appname's data
Any ideas?
If using the high-replication datastore, change the value passed to --application from appname to s~appname.
Found the problem - as an URL I was giving my own app's domain name instead of the 1.appname.appspot.com.
I ran into this same issue, but when attempting to use the remote API from a custom script as opposed to appcfg.py's bulk downloader.
This issue may have been addressed in more recent GAE SDK releases, but for various reasons I'm still using the older 1.7 release. I found the answer in this bug report: https://code.google.com/p/googleappengine/issues/detail?id=4374
Basically, when calling ConfigureRemoteApi, don't specify the APP_ID argument (just pass None) and specify your app ID via the host argument, e.g. 'myapp-hrd.appspot.com'. ConfigureRemoteApi will figure out your app ID correctly and won't add the 's~' that causes this problem.